Программист

IT-шников не часто зовут писать что-то новое. Чаще всего их зовут разбираться в старом чужом говне в виде кривой и косой связки нескольких IT-систем. Визуально это можно изобразить приблизительно вот так:

Каждый из элементов этой конструкции писали разные люди, причем иногда не одновременно друг с другом. Всё это накладывалось слоями одно на другое в несколько поколений принимаемых и увольняемых сотрудников.

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

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

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

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

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

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

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

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

Рефакторинг визуально выглядит так:

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

1. Состояние кода непонятно внешнему наблюдателю (заказчику, кто выдает деньги на разработку). Это черный ящик.

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

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

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

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

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

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

А вот с программистом, написавшим чистый код, можно попрощаться легче, ведь его проще заменить.

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

И что с этим всем делать?

Первому лицу понять, что нужно нанимать программистов не только квалифицированных, но при этом и идейно правильных. Хотя бы самого главного.

Первому лицу работать над собственной квалификацией в IT. Не имеется в виду программирования, а понимание самого понятия технического долга.

Первому лицу выделять ресурсы на рефакторинг, на написание User stories, детальных блок-схем, на написание инструкций не только по пользованию системой, но и по ее программированию.

Главному айтишнику выбивать ресурсы на улучшение качества кода.

Остальным айтишникам заботиться о судьбе систем и коллегах по цеху, чтобы им было проще. Будет лишний повод для гордости.

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

Главное, разработку кода невозможно стандартизировать, так как код напоминает живой организм, который постоянно меняется и развивается, эволюционирует. Это не совсем как механизм в реальном мире, который один раз спроектировал и он работает, это скорее больше именно живой организм, который программист эволюционирует и адаптирует постоянно к постоянно изменяющейся окружающей среде. И чем дальше, тем больше программист должен знать. Например 20 лет назад чтобы войти в Java разработку надо было просто знать Java и базовые алгоритмы. Сейчас надо знать множество подходов, фреймворков, библиотек, архитектур. А это требует времени на обучение, причём постоянно.