Точка складності без повернення. Як ти це називаєш?

Як розробник програмного забезпечення, одне з моїх головних завдань - тримати складність під контролем.

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

Чи має цей конкретний момент назву в діалекті програмістів (щось подібне, ніж закон Годвіна для тролів)?

--edit--

Вибачте, якщо мені не зрозуміло. Я не думаю, що цей "момент" має офіційну назву, або це серйозна метрика. Я думав про щось у дусі "піку Балмера" у xkcd .

Це скоріше питання ремонтопридатності, ніж складності.

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

Це ви мали на увазі?

"Точка зайвої складності" в англійській мові називається:

О МОЙ БОГ, ЩО ЦЕ КРАП.

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

Тож сказати окремо щось дуже складне від чогось жахливого може бути важким.

ТАКОЖ: Те, що насправді має траплятися з усім програмним забезпеченням, це трохи так:

Крок 1: Майте приємну специфікацію, робіть гарний дизайн, втілюйте приємні речі. Усі щасливі.

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

Крок 2: Деякі зміни вносяться, додаються речі, включаються нові функції. Архітектура та структура з кроку 1 зробили це досить безболісним процесом. [На жаль, "чіткий фактор" трохи збільшився.]

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

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

На завершення кроку 3: розробники вітають себе з чудовою вишуканістю їх дизайну і відходять досить радісно, ​​думаючи: "Да, ця архітектура досить гарна, щоб дозволити стільки змін просто прорізатися легко. Але я трохи нещасний про X і Y та Z. Їх зараз можна було трохи прибрати. Але !!! Ааааааааааааааааааааааааааааааааауауразаціяіііх надбавок на Крок 1. Це пройшло так добре. інші, щоб додати речі в майбутньому, це буде чудово, і світ стане кращим місцем ".

Крок 4: як і крок 3. За винятком:

Наприкінці кроку 4: розробники думають: "Цей дуже гарний матеріал отримує UGLY для підтримання. Він дійсно потребує серйозних змін. Мені не дуже подобається працювати над цим. Він потребує рефакторингу. Цікаво, що це за начальник скаже, коли я скажу йому, що йому потрібно 6 тижнів, і користувачі нічого не побачать в кінці цього ... але я отримаю ще 5 років смачної майбутньої сфери модифікації, роблячи це .... хммм .. час піти в паб за пивом ".

Крок 5: Необхідно внести купу змін.

І на протязі 5-го кроку розробники кажуть один одному: "Цей код відстійний. Хто це написав? Їх слід зняти. Це жахливо. МИ МОЖЕМИ ЗНО ЗАПИСИТИ його".

Крок 5 є фатальним. Ось тут основний фактор настільки поганий, що код не може просто змінити ще кілька, він повинен мати великі зміни.

Біда на кроці 5 - це бажання відкинути його і почати заново. Причина цього фатальна - "Фактор Netscape". Перейдіть на Google. Компанії помирають на даний момент, тому що починати знову означає, що ви починаєте з приблизно 50% припущень замість фактів, 150% ентузіазму замість знань, 200% зарозумілості замість смирення ("Ці хлопці були такими дурними!"). І ти вводиш цілу купу нових помилок.

Найкраще зробити це рефактор. Поміняйте трохи за раз. Якщо архітектура трохи втомлюється, виправте це. Додавання, розширення, вдосконалення. Поступово. На кожному кроці по дорозі тестуйте, випробовуйте та перевіряйте ще кілька. Поступові зміни, подібні до цього, означають, що через 10 років діючий та оригінальний код схожий на дідусь сокиру («у нього було 10 нових голів та 3 нових ручок, але це все-таки діда сокира»). Іншими словами, спільного залишилося не так багато. Але ви переходили від старого до нового поступово і обережно. Це знижує ризик, а для клієнтів - зменшує роздратований коефіцієнт.

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

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

• Складність полягає в недокументальних вимогах
• Нові інструменти використовувати складніше, тоді пообіцяв веб-сайт Flash
• Нова команда не така "гаряча", як вони вважали

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

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

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

Але мені подобається, що ми могли б дати йому ім’я. "Господи", можна сказати, зводячи ваших колег-розробників навколо вас, "ми перетнули" Hellespont "щодо технічного обслуговування. Надішліть дружину своїй дружині та дайте їй знати, що ви її деякий час не бачите".

Я не знаю, чи є ім'я, але якщо немає, я б запропонував назвати його "точкою розпаду".

Це не дуже цікаве питання.

Дійсно, це банально.

Це настільки банально, що ми розробили численні способи впоратися.

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

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

Єдиний раз, коли хтось бореться зі «складністю», це через невідповідність методиці та належне управління своїм часом.

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

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

Складність повинна бути обмежена постановкою цілей.

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

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

Існують методи візуалізації та моніторингу ризику збільшення складності для (великих) проектів та коду. Коли вони застосовуються розумно, сподіваємось, нове ім'я для точки неповернення не потрібно. (На openHPI є пов'язаний MOOC: https://open.hpi.de/courses/softwareanalytics2015/ )

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

Деякі методи зменшення складності конструкції є http://www.buch.de/shop/home/suche/?fq=3540878890 :

• модуляція
• уникнення циклів зворотного зв'язку
• тріангуляція

Крім того, існує концепція аксіоматичного дизайну: https: \ en.wikipedia.org \ wiki \ Axiomatic_design \ З цією концепцією можна уникнути проблем надійності через несподівану складність.

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