Коли слід усунути складність?

Передчасне впровадження складності шляхом впровадження моделей дизайну до того, як вони знадобляться, не є хорошою практикою.

Але якщо ви будете дотримуватися всіх (або навіть більшості) принципів SOLID та використовувати загальні шаблони дизайну, ви внесете певну складність, оскільки функції та вимоги додаються чи змінюються, щоб ваш дизайн був таким, як необхідний та гнучкий.

Однак як тільки ця складність буде введена і працює як чемпіон, коли ти її зняв?

Приклад. У мене заявка написана для клієнта. Первісно створені там, де декілька способів давати підвищення заробітчанам. Я використовував схему стратегії та фабрику, щоб підтримувати весь процес красивим та чистим. З часом певні методи підвищення, коли власник програми додає або видаляє.

Минає час, і новий власник бере на себе. Цей новий власник з твердим носом, все просто і має лише один спосіб підняти.

Складність, необхідна для структури стратегії, більше не потрібна. Якби я куди це кодував із тих вимог, якими вони є зараз, я б не вніс цієї додаткової складності (але переконайтесь, що я міг би ввести це з малою чи відсутністю роботи, якщо виникне потреба).

Тож чи я зараз знімаю реалізацію стратегії? Я не думаю, що цей новий власник ніколи не змінить способи отримання підвищення. Але сама програма продемонструвала, що це може статися.

Звичайно, це лише один приклад програми, коли новий власник бере на себе і спростив багато процесів. Я міг би видалити десятки класів, інтерфейсів і фабрик і зробити всю програму набагато простішою. Зауважте, що поточна реалізація працює чудово, і власник задоволений цим (і здивований і ще щасливіший, що мені вдалося так швидко здійснити її зміни через обговорювану складність).

Я визнаю, що невелика частина цього сумніву полягає в тому, що велика ймовірність, що новий власник більше не збирається використовувати мене. Мені дуже не байдуже, що хтось інший візьме це на себе, оскільки він не був великим генератором доходу.

Але я дбаю про 2 (пов'язані) речі

1. Мене трохи хвилює, що новому обслуговуючому апарату доведеться думати трохи складніше, намагаючись зрозуміти код. Складність - це складність, і я не хочу гнівати психоманіяка, що йде за мною.

2. Але ще більше я переживаю за те, щоб конкурент бачив цю складність і думав, що я просто впроваджую дизайнерські зразки, щоб прокласти свої години на робочих місцях. Потім поширюю цю чутку, щоб нашкодити іншому моєму бізнесу. (Я чув це згадане.)

Так...

Взагалі, чи слід раніше знімати необхідну складність, хоча вона працює і історично продемонстрована потреба в складності, але ви не маєте жодних ознак, що вона буде потрібна в майбутньому?

Навіть якщо на вищезазначене питання, як правило, відповідає "ні", чи розумно зняти цю "непотрібну" складність, якщо передавати проект конкурентові (або незнайомцю)?

У чомусь, я думаю, що це багато в чому ділове рішення, а не обов’язково базується на самому коді. Деякі речі, які слід врахувати:

• Вам платять за внесення змін?
• Чи працює код на даний момент, як очікувалося?
• Чи є проблеми з безпекою чи працездатністю щодо коду, як це є?
• Чи перевищує розмір технічної заборгованості вартість її виправлення?
• Що реально може статися, якщо залишити код таким, який є?
• Які майбутні проблеми можуть виникнути з рефакторингом або без нього?
• Скільки відповідальності становить код перед вами та вашим бізнесом?

Ви зможете відповісти на ці питання. Однак, виходячи з вашого опису, я не знаю, чи би я заважав рефакторингу та спрощенню речей, оскільки це не здається, що це буде вартим вашого часу. Якщо він наразі працює, клієнт задоволений, і вам не подобається платити за оновлення всього, тоді нехай це буде і працюйте над активністю, що приносить прибуток.

Коротше кажучи, зробіть аналіз витрат та вигод та оцінку ризику обох шляхів та вживайте найбезпечніший, найефективніший та найвигідніший спосіб дій.

Чи не вилучаєте цей код і не замінюєте його чимось простим для майбутнього простоти кодування функції, яку клієнт повинен розглянути та оплатити?

Можливо, у вас є щось корисне, чому інший розробник міг би навчитися, але шанси знайти додаток іншого клієнта, щоб підключити його, малоймовірно.

Плітки про код конкурента - це не те, що ви можете запобігти. Вони будуть виглядати нерозумно, намагаючись негативно набрати клієнтів.

Поширена приказка: "Якщо вона не зламалася, не виправляйте".

За цим правилом є кілька раціоналістів. Деякі з них можуть полягати в тому, що "спрощення" загрожує введенням нових, різних і, можливо, більших помилок, може зайняти все більше часу розвитку від інших більш цінних починань, і може бути абсолютно неправильною зміною для якоїсь несподіваної майбутньої можливості для бізнесу, що виникає.

Якщо для цього коду є достатня цінність для портативної та більш доступної рентабельності, то вирішіть, чи дійсно цього значення достатньо, щоб вважати поточний код "зламаним". Цілком може бути, якщо планується велике розширення бізнесу, або ви підозрюєте, що прихована помилка прихована в складності, яка може звести бізнес.

Перш за все, якщо додаток вже один раз перейняв новий власник, це може повторитися. І наступний власник може знову почати використовувати ту складність, якою не користується на даний момент.

Крім цього, нетривіальні зміни робочого коду завжди тягнуть за собою ризик, таким чином (як зазначали інші) клієнт повинен погодитися з ними (і оплатити їх). Якщо поточна "зайва" складність не викликає помітних, мірних недоліків (таких, як проблеми з продуктивністю), немає жодних вагомих причин її усунути.

(Потенційні) клієнти, які (не) наймають вас, базуючись лише на чутках конкурентів, IMHO все одно не варто мати, якщо ви не потребуєте доходу. У вас є вагомі та логічні причини, чому ви реалізували додаток так, як ви це зробили, і будь-який серйозний клієнт, ймовірно, це зрозуміє. Хтось, хто не хоче, або навіть не намагається запитати вас про це, - швидше за все, вам заподіє більше проблем, ніж вартість роботи в будь-якому випадку.

Взагалі, чи слід раніше знімати необхідну складність, хоча вона працює і історично продемонстрована потреба в складності, але ви не маєте жодних ознак, що вона буде потрібна в майбутньому?

Ні.

Навіть якщо на вищезазначене питання, як правило, відповідає "ні", чи розумно усунути цю "непотрібну" складність, якщо передавати проект конкурентові (або незнайомцю)

Ні. Навіщо витрачати свій час на виправлення подібних робіт з низьким пріоритетом? Немає шкоди для перебування коду.

Що стосується вашого питання: Коли складність слід усунути?

Моя думка, якщо вона не зламалася, не виправляйте .

Щоб мати змогу зняти складність, має бути істинним:

1. Вилучений фрагмент повинен бути незалежним від програми. Якщо є якісь залежності від навколишньої програми до коду, про який йде мова, просто видалити складність не вийде
2. На жаль, якщо це виглядає як складність, то велика ймовірність, що шматки не є незалежними, а залежності зірвуть вашу програму, коли ви виймете фрагмент
3. Усунення всіх залежних ситуацій потребує часу, так що час потрібно враховувати, коли ви оцінюєте, чи варта операція.
4. Більшість часу це не варте зусиль, але ви просто вирішите не використовувати якийсь новий код, використовуючи старий

Я думаю, тут є щось більше на роботі ... Масштабованість

Те, про що ви говорите, називається масштабованість . Не важливо, чи є кодування складним, важливо, чи може додаток розвиватися на основі нових правил бізнесу або змінених правил бізнесу. Що станеться, якщо наступний власник захоче щось зовсім інше.

Отже, я кажу, збережіть код і документуйте його. Це особливість способу використання програми.

Взагалі, чи слід раніше знімати необхідну складність, хоча вона працює і історично продемонстрована потреба в складності, але ви не маєте жодних ознак, що вона буде потрібна в майбутньому?

Існують зусилля та ризик усунути складність. Якщо це перевищує додаткові зусилля та ризик збереження надмірно складного коду, то ви його зберігаєте. В іншому випадку ви видалите його. Однак важко оцінити ці ризики.

Я хотів би додати, що ви можете зменшити ризик більш складного технічного обслуговування, задокументувавши, чому ви використовували вперше в коді стратегію дизайну. Я особисто вважаю, що будь-яка модель дизайну повинна бути простежена до явної вимоги (функціональної чи нефункціональної).

Навіть якщо на вищезазначене питання, як правило, відповідає "ні", чи розумно зняти цю "непотрібну" складність, якщо передавати проект конкурентові (або незнайомцю)?

Ваш сценарій відхилення від змагань за прокладку годин - це саме причина, чому ви повинні документувати складність. Якщо ви документуєте та обґрунтовуєте (з конкретною вимогою клієнта) використання будь-якого шаблону, тоді ви охоплені. Якщо ви не можете обґрунтувати схему з вимогами замовника, це виглядає як переоформлення або шаблоніт.

Якщо вимоги змінюються, ви можете виправдати залишення його через ризик, що ви можете зламати код (або обсяг роботи для хірургічного видалення шаблону).

Я думаю, що добре розрізняти випадкову складність та істотну складність , оскільки закономірності часто включають і те, і інше.

Тобто, ваша вимога підтримувати різні алгоритми для вирішення підвищення, є суттєвою складністю (частина проблеми, яку потрібно вирішити). Обслуговування Вашого коду стало простіше по візерунку стратегії, але жорстко , якщо / то альтернатива стратегії буде продовжувати працювати. Я робив вправи на своїх магістерських курсах, де студенти знаходять можливості застосувати Стратегію у проектах з відкритим кодом. Складність не обов'язково краща / гірша при застосуванні Стратегії (адже це суттєва складність). Іноді стратегію може бути навіть складніше, тому що код розділений на кілька класів з поліморфізмом, а не один великий блок if / then / else.

В ідеалі модель працює, коли переваги, які вона надає, переважають вартість її недоліків. Знову оцінити ці речі важко. Часто візерунок робить розробника щасливим (не тільки тому, що це полегшує додавання нової стратегії підвищення, але дає розробнику теплі нечіткі відомості про те, що шаблон застосовано). Важко показати клієнтам, як це їм вигідно.

Замовник не цікавиться або навіть не розуміє деталі. У випадку, коли новий власник застосовує KISS у своїх процесах, це зменшує його суттєву складність, що має вплинути і на програмне рішення.