Даже книжка такая есть.
И что мешает этим заняться?
1. Состояние кода непонятно внешнему наблюдателю (заказчику, кто выдает деньги на разработку). Это черный ящик. Внешний наблюдатель оценить рефакторинг не сможет. Он видит только внешнюю составляющую программы – фичу, эффект. Он видит только, что программа работает. Оценить чистоту кода может только другой программист, и на саму оценку надо потратить много времени. И оценка будет скорее субъективной, чем объективной. А деньги на все разработки как правило выделяет внешний наблюдатель, который качества кода не понимает.
Исходя из этого, заказчик не может оценить работу по рефакторингу, он не видит результатов, которые может обнаружить. Рефакторингом можно заниматься бесконечно, и для заказчика, который выделяет деньги, всё будет выглядеть так, как будто программист страдает какой-то хренью. Тратит время без всякого результата, не выпускает никаких релизов.
То есть, рефакторинг – это насыщение внутренней энергии системы. Эффективный менеджер быстро пишет код, чтобы он только работал. Он идет по головам, он хардкодит. Он выглядит круто – очень быстро выпускает релизы. Очень эффективная и эффектная работа. Неэффективный менеджер рефакторит, насыщает внутреннюю энергию системы, чтобы следующим программистам было проще. Всё это повышает затраты на разработку.
2. Незаменимость программиста, написавшего непонятный код.
Это делает уход программиста крайне нежелательным для компании. Поэтому у IT-шников такие высокие зарплаты. Во-первых, их стараются удержать. Во-вторых, возникает огромные требования к квалификации IT-шников, т.к. они должны всё-таки как-то разобраться в предыдущих нагромождениях. Значит, нам тут нужен обязательно только СУПЕР-АЙТИШНИК, только такой не повязнет насмерть в этом болоте и покажет результат. А суперский хочет много денег. Вот и дергают их с одной работы на другую. В результате этой войны за кадры IT-шники еще и постоянно мечутся туда-сюда между компаниями, усугубляя эту ситуацию. Системы только больше и больше уродуются. А вот с программистом, написавшим чистый код, можно попрощаться легче, ведь его проще заменить.
Эта ситуация создала постоянную незаменимость и крайнюю востребованность IT-шников сильнее джуниоров. Джуниоры как раз особо никому не нужны, потому что они могут только написать свой код, но не могут понять чужой. А ценится как раз второе.
И что с этим всем делать?
1. Первому лицу понять, что нужно нанимать программистов не только квалифицированных, но при этом и идейно правильных. Хотя бы самого главного.
2. Первому лицу работать над собственной квалификацией в IT. Не имеется в виду программирования, а понимание самого понятия технического долга.
3. Первому лицу выделять ресурсы на рефакторинг, на написание User stories, детальных блок-схем, на написание инструкций не только по пользованию системой, но и по ее программированию.
4.
