Here be Dragons
Я искренне верю, что все люди по-умолчанию разумны, по крайней мере вокруг меня, откровенные идиоты мне встречались крайне редко, а про вредителей я только слышал рассказы. Возможно, это некое проявление эффекта Даннинга-Крюгера.Когда я вижу какой-то вотзефак в коде, дикое решение, выбор технологии, вотэва - я уверен, что человек выбрал лучшее решение на тот момент. Даже если в итоге получился дичайший монстр, который, как памятник, служит предостережением будущим поколениям. Этому может быть три причины.
Первая, наиболее редкая - нехватка квалификации. Человек изобретал свой велосипед, не зная про простое стандартное решение в одну строку.
Вторая, наиболее распространенная - скрытая проблема. Человек пытался обойти какую-то проблему, усердно возводя костыли и подпорки. Если при этом нет пояснения или предупреждения, то очень плохо - какой-то комментарий должен быть. В идеале, тут же должна быть описана проблема, рассмотренные варианты, обоснование выбранного решения, ссылка на тикет в багтрекере проблемного компонента.
Во втором случае либо патчить, либо ждать, пока компонент будет починен, выпилен, проблема рассосется, хотя не стоит на это рассчитывать. В первом и третьем случае если можно быстро переписать, руководствуясь правилом бойскаутов - оставлять код после себя чище, чем был - то стоит это сделать. Если же объем работы большой, то нужно воткнуть значок "Заминировано". Хотя, если до сих пор это никто не заметил, то скорее всего (иногда бывает) это не вызывает проблем, за исключением, конечно, ситуации поиска проблемы.
Baby duck syndrome
Споры "почему технология X а не Y" редко бывают конструктивны. Когда есть несколько альтернатив, выбор сделан и выбор удачен (достаточно хорошо решает задачи), автоматически появляется синдром утёнка, определяющий выбор технологии на годы вперёд. Позле этого предложение переехать на новую технологию воспринимаются без энтузиазма либо вообще никак не воспринимаются - зачем трогать работающий инструмент? - это чревато переработками.
Здесь кроется проблема, потому что иногда переезд может дать мощнейший буст проекту. В любом случае, мы считаем людей вокруг здравомыслящими, от очевидного профита никто отказываться не будет. А если профит не очевиден, то зачем менять шило на мыло.
Достаточно хорошо
Правило Парето никто не отменял: если выбранное решение достаточно хорошо, то скорее всего мы достигли 80%, тратить еще 80% времени на выигрыш 20% редко обосновано. Мы делаем допущение и пишем коммент: здесь объем настолько мал, что мы не паримся и решаем задачу в лоб. Когда-нибудь, возможно, объем данных вырастет и придется тратить время на оптимизацию, а коммент позволит быстро найти потенциально узкое место. Конечно, понятие достаточности у всех разное, но тут, опять же, хватит второй пары глаз.
Похожий вопрос возникает когда спрашивают: "А почему вы это не сделали? Это же по Фэн-Шую, хорошая практика и все так делают". Ну да, мы, в приципе, не дураки, тоже про Фэн-Шуй знаем, но посчитали, что отношение затраты/выигрыш недостаточны, чтобы это делать, когда-нибудь потом, а сейчас есть дела важнее.
Похожий вопрос возникает когда спрашивают: "А почему вы это не сделали? Это же по Фэн-Шую, хорошая практика и все так делают". Ну да, мы, в приципе, не дураки, тоже про Фэн-Шуй знаем, но посчитали, что отношение затраты/выигрыш недостаточны, чтобы это делать, когда-нибудь потом, а сейчас есть дела важнее.
One step at a time
Когда вокруг всё плохо, то выбрасывать всё и переписывать с нуля никто не даст. Нужны расчистить эпсилон-окрестность и сделать зоны кристаллизации, вокруг которых будет появляться нормальный код. Даже в крупном проекте реально незаметно изменить ядро, аккуратно расчистив завалы. Главное не исповедовать идеологию "мне насрать на то, что я пишу".
Наблюдение за крупными платформами типа Java, Python, Django прививает идею обратной совместимости, постепенного развития и жизненного цикла фич: запрос на реализацию, обсуждение, реализация, пометка нежелательным к применению, удаление. В книге Effective Java описано много таких фич, которые оказались не очень удачными.
