Суть всей IT-разработки глазами бережливца и почему IT-шники получают так много

denis_demakhin — 28.01.2022 Я попал в IT-сферу всего лишь неделю назад. Зато я не последний бережливец и самый настоящий инженер.

Вот, что мне удалось понять за неделю.

Суть IT-разработки

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



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

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

1. ОНО РАБОТАЕТ, ОНО КАК-ТО ХОДИТ.
   
2. Этот ходячий замок невидим и неосязаем всем посторонним людям. Они видят лишь эффект, производимый им, но не то, как он устроен изнутри. Программисты тоже не могут видеть его, но зато они хотя бы могут его ощупывать. Все остальные не могут даже этого. Поэтому никто не знает, насколько он уродливый, но программисты примерно догадываются.
   

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

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

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

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



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

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

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



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

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

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

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

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

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

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

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

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

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

В чем разница между инженером и IT-шником?

Все инженеры работают по ГОСТ ЕСКД (Единая система конструкторской документации), технологи по ЕСТД, электрики по ПУЭ. Всех нас в институте обязательно учили делать чертежи одинаково, по государственным стандартам. А на предприятиях есть отдел нормоконтроля, который не даст выпустить КД с нарушением стандарта оформления.

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

В результате инженеры работают по ЕСКД, а программисты - кто во что горазд. Поэтому инженеров проще заменить друг на друга.

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

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

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

Первому лицу работать над собственной квалификацией в IT.

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

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

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


Подписывайся, этот бережливец теперь в IT!

Работаю - тут (гиперссылка).

Оставить комментарий

Популярные посты:

• Архив