«Точка чрезмерной сложности» в английском языке обозначается как:
О, Боже мой, что это за хрень.
Проблема в том, что это может относиться к чему-то, что на самом деле просто, но реализовано так ужасно, что у вас такая же реакция.
Так что отличить что-то очень сложное от чего-то очень ужасного может быть сложно.
ОДНАКО: То, что на самом деле происходит со всем программным обеспечением, происходит примерно так:
Шаг 1: Иметь хорошую спецификацию, делать хороший дизайн, реализовывать хорошие вещи. Все счастливы.
В конце шага 1: разработчики поздравляют себя с удивительной элегантностью своего дизайна и уходят от счастья, думая: «У меня есть замечательное наследие, к которому другие могут добавить вещи в будущем, это будет чудесно, и мир станет лучшее место."
Шаг 2: Внесены некоторые изменения, добавлены вещи, включены новые функции. Архитектура и структура из шага 1 сделали этот процесс довольно безболезненным. [Но, к сожалению, «фактор погрешности» только увеличился.]
В конце шага 2: разработчики поздравляют себя с удивительной элегантностью их дизайна и уходят от счастья, думая: «Ну и дела, я так умен, что сделал все эти поправки на шаге 1. Это прошло так хорошо. У меня замечательное наследие здесь для других, чтобы добавить вещи в будущем, это будет чудесно, и мир станет лучше ».
Шаг 3: Сделано больше изменений, добавлено больше вещей, больше новых функций, изменено множество вещей, на самом деле выслушиваются отзывы пользователей.
В конце шага 3: разработчики поздравляют себя с удивительной элегантностью их дизайна и уходят от довольно счастливого размышления: «Ну и дела, эта архитектура довольно хороша, чтобы позволить такому количеству изменений просто вставлять легко. Но я немного несчастен о X, Y и Z. Теперь их можно немного почистить. Но !!! Ааааааааааааааааа .... Я так умен, что сделал все эти поправки в Шаге 1. Это прошло так хорошо. У меня есть замечательное наследие для другие будут добавлять вещи в будущем, это будет чудесно, и мир станет лучше ».
Шаг 4: так же, как шаг 3. За исключением:
В конце шага 4: разработчики думают: «Этот материал, который был настолько хорош, становится уродливым для обслуживания. Он действительно нуждается в серьезных изменениях. Мне не очень нравится работать над этим. Нужен рефакторинг. Интересно, что за начальник? скажет, когда я скажу ему, что ему нужно 6 недель, и пользователям будет нечего видеть в конце этого ... но я получу еще 5 лет вкусной будущей модификации, сделав это .... хммм .. . время идти в паб за пивом ".
Шаг 5: Нужно сделать кучу изменений.
И во время шага 5 разработчики говорят друг другу: «Этот код - отстой. Кто это написал? Они должны быть застрелены. Это ужасно. Мы должны переписать это».
Шаг 5 смертелен. Именно здесь фактор погрешности настолько плох, что в коде не может быть просто еще нескольких изменений, ему нужно внести БОЛЬШИЕ изменения.
Проблема на Шаге 5 - желание выбросить это и начать снова. Причина этого фатальна - «Фактор Netscape». Иди в Google. Компании умирают на этом этапе, потому что начинать заново означает, что вы начинаете с примерно 50% предположений вместо фактов, 150% энтузиазма вместо знаний, 200% высокомерия вместо смирения («Эти ребята были такими тупыми!»). И вы вводите целую кучу новых ошибок.
Лучше всего сделать рефакторинг. Изменитесь немного за один раз. Если архитектура немного устала, исправьте это. Добавить, расширить, улучшить. Постепенно. На каждом шаге пути тестируйте, тестируйте и тестируйте еще немного. Поэтапные изменения, подобные этому, означают, что через 10 лет текущий и оригинальный код похожи на топор дедушки («у него было 10 новых голов и 3 новые ручки, но он все еще топор дедушки»). Другими словами, общего мало что осталось. Но вы перешли от старого к новому постепенно и осторожно. Это снижает риск, а для клиентов - уменьшает раздражение.