Comments 4
очень симптоматично что автор на первое место ставит
написание кода;
а решение задач ставит даже не на второе и не на третье место, а куда-то ближе к концу.
Если нагородить кучу кода не понимая и не зная решения задач, которые этот код должен все таки решить, то только и остается сложностью этого кода управлять пока проект окончательно не загнется или пока кто-то знающий не придет и не продемонстрирует все таки решение задач и не объяснит, в чем заключается сложность, в данном конкретном случае.
сложность привнесена, так что от неё можно избавиться;
сложность неотъемлема, и мы должны сохранить её;
сложность неотъемлема, но мы можем устранить её, изменив определение спецификации задачи;
знание, позволяющее понять, неотъемлемо что-то или нет, утеряно, заказчик или владелец продукта не могут этого сообщить, или нет лица, имеющего полномочий принять решение.
Ещё вариант: сложность привнесена. Но переписать write only код (прочтение и понимание которого слишком трудно, неоправданно трудно, как правило, даже труднее, чем его написание автором кода, хотя в нормальных случаях должно быть наоборот)
малыми силами невозможно. Избавляться можно было лишь в момент написания. Теперь только сжечь и построить заново. Причём от старой системы ценным является лишь пользовательский опыт, привычка и ничего более.
Сложность — это всё то, что усложняет понимание и изменение системы.
А "усложняет" — это когда увеличивает сложность, видимо? :)
Это вот тот случай, когда ИТ мало того, что должно подумать за всю организацию, так ещё и переубедить поменять бизнес-процессы на свой страх и риск. Не знаю, есть ли такие организации вообще
О неотъемлемой сложности систем