У этой конструкции самых важных аспектов два:

1. ОНО РАБОТАЕТ, ОНО КАК-ТО ХОДИТ.

2. Этот ходячий замок невидим и неосязаем всем посторонним людям. Они видят лишь эффект, производимый им, но не то, как он устроен изнутри. Программисты тоже не могут видеть его, но зато они хотя бы могут его ощупывать. Все остальные не могут даже этого. Поэтому никто не знает, насколько он уродливый, но программисты примерно догадываются.

Да. Оно работает. Но вот как оно работает и почему – это вопросы очень серьезные.

Увольняется очередной IT-шник, и приходит новый. И у него 90% работы заключается в том, чтобы понять тот клубок из кусков, написанных разными людьми, с которым тут работают. Старые люди уходят, новые ничего про систему не знают. Знания передаются плохо. В результате в системах образуются целые слои и пласты неизвестной информации и всякие бермудские треугольники.

И с каждым разом прикрутить к этому всему еще что-то новое и всё при этом не сломать становится всё сложнее и сложнее, и с какого-то момента становится почти невозможно. Невозможно становится искать ошибки. Это называется «говнокод» или «грязный код». Это такой код, которые не могут понять другие программисты. Когда такой код накапливается, это называют «техническим долгом».

Аналог в физическом воплощении это наверное подземные коммуникации. В теории должна быть какая-то единая карта пролегания всех подземных коммуникаций всех служб, но в жизни этого почему-то не оказывается. И когда нужно заменить какой-то подземный кабель, то его не достают из земли, а просто бросают поверх него еще один, новый.

Как противостоять этой эрозии?

Для этого делают рефакторинг кода. Это когда уже работающий код улучшают и оптимизируют, разбивают на блоки и снабжают комментариями, чтобы привести его к состоянию, при котором другие программисты могли бы в нем разобраться. Это называется «чистый код». Даже книжка такая есть.

И что мешает этим заняться?

1. Состояние кода непонятно внешнему наблюдателю (заказчику, кто выдает деньги на разработку). Это черный ящик. Внешний наблюдатель оценить рефакторинг не сможет. Он видит только внешнюю составляющую программы – фичу, эффект. Он видит только, что программа работает. Оценить чистоту кода может только другой программист, и на саму оценку надо потратить много времени. И оценка будет скорее субъективной, чем объективной. А деньги на все разработки как правило выделяет внешний наблюдатель, который качества кода не понимает.

Исходя из этого, заказчик не может оценить работу по рефакторингу, он не видит результатов, которые может обнаружить. Рефакторингом можно заниматься бесконечно, и для заказчика, который выделяет деньги, всё будет выглядеть так, как будто программист страдает какой-то хренью. Тратит время без всякого результата, не выпускает никаких релизов.

То есть, рефакторинг – это насыщение внутренней энергии системы. Эффективный менеджер быстро пишет код, чтобы он только работал. Он идет по головам, он хардкодит. Он выглядит круто – очень быстро выпускает релизы. Очень эффективная и эффектная работа. Неэффективный менеджер рефакторит, насыщает внутреннюю энергию системы, чтобы следующим программистам было проще. Всё это повышает затраты на разработку.

2. Незаменимость программиста, написавшего непонятный код.

Это делает уход программиста крайне нежелательным для компании. Поэтому у IT-шников такие высокие зарплаты. Во-первых, их стараются удержать. Во-вторых, возникает огромные требования к квалификации IT-шников, т.к. они должны всё-таки как-то разобраться в предыдущих нагромождениях. Значит, нам тут нужен обязательно только СУПЕР-АЙТИШНИК, только такой не повязнет насмерть в этом болоте и покажет результат. А суперский хочет много денег. Вот и дергают их с одной работы на другую. В результате этой войны за кадры IT-шники еще и постоянно мечутся туда-сюда между компаниями, усугубляя эту ситуацию. Системы только больше и больше уродуются. А вот с программистом, написавшим чистый код, можно попрощаться легче, ведь его проще заменить.