Эффективный менеджмент в IT и его последствия
Предисловие
Речь пойдёт об одной из самых наболевших для меня (и, уверен, не только меня) тем в компьютерной области. О том, почему та область, которой я посвятил чуть ли не всю жизнь, начиная лет с 6-7, теперь уже вряд ли когда-то будет для меня основным источником дохода. В этом тексте я не преследую скрытых целей — поумничать, возвыситься над кем-то, оклеветать кого-то и т. п. Единственная его цель — в исчерпывающей и максимально доходчивой форме передать суть проблемы, с которой я лично столкнулся и в которой я вижу угрозу для себя. Голословные утверждения в духе «ты не прав» или «ты ничего не понимаешь» в качестве контраргументов не годятся, отрицание проблемы никак не поможет её решить.DESCRIPTION
«Наша главная задача —
Молотьба и хлебосдача.
Хочешь быть передовым —
Сей квадратно-гнездовым!»
Коротко о хорошо забытых старых "универсальных" методах
Современные подходы в IT построены на вере в возможность существования некоторого набора шаблонных, но при этом универсальных методик, с помощью которых можно одинаково быстро и качественно решать любые задачи, независимо от нюансов задач и субъективного удобства методик для конкретного разработчика. То есть, методы решения задач фиксируются, вместо того, чтобы подгоняться под обстоятельства. Однажды мне дали на доработку сайт-одностраничник, сделанный «на Bitrix», который фактически состоял из index.html, одного JS-файла и таблицы стилей, а Bitrix, видимо, стоял для успокоения заказчика, который захотел «сайт на Bitrix», потому, что слышал, что это круто. Когда я смотрю на модные фреймворки, методики и прочие best practices, и то, с каким фанатизмом эффективные менеджеры пытаются в них впихнуть невпихуемое — всю разработку со всей её нешаблонностью, будучи уверенными, что лучше специалиста знают, как надо, превращая это в обязаловку фактически под угрозой для специалиста остаться без работы в случае его несогласия, у меня возникает ассоциация с фразой «прокрустово ложе».
Прокрустово ложе — ограничения или узкие рамки, под которые насильственно подгоняют не вписывающиеся в них явления, в ущерб чему-то существенному (по имени легендарного древнегреческого разбойника Прокруста, который укладывал захваченных им жертв на свое ложе и обрубал ноги тем, кто оказывался длиннее ложа, а тем, кто короче, вытягивал их).
Конечная цель всего этого — низвести разработчика до уровня мелкого винтика в производственной системе ради стабильности бизнеса, сделав его легко и быстро заменяемым. Даже если это даётся ценой качества конечного результата. Вот реальная причина популярности большинства популярных фреймворков и методик, а не их техническое совершенство или какие-то заложенные в них гениальные идеи. «Лучшими» эти практики являются лишь для бизнеса, для разработчика же лучше использовать свои наработки и иметь дело с тем, что он знает досконально, чем вызубрить кучу фреймворков, не вызывающих доверия в плане безопасности ввиду огромных объёмов их кода и малореальности его изучения для одного человека (а без этого можно допустить уязвимость из-за незнания, какие механизмы безопасности реализованы во фреймворке и как). Так какой мне интерес их изучать, если я могу те же задачи за то же самое время (если не быстрее) решить без них, с использованием своих наработок, библиотек, фреймворков и т. д., при этом быть уверенным в качестве результата? Или мои интересы никого не интересуют, ведь «проблемы индейцев вождя не волнуют»? Ни одного вразумительного ответа на этот вопрос мне до сих пор никто не дал.
Я не против готовых решений и фреймворков как таковых. Я против бюрократизации разработки (когда «шашечки» становятся важнее, чем ехать), навязывания разработчику методов и инструментов выполнения его работы, использования фреймворков как «чёрных ящиков» (без понимания, что внутри них), бесконечного изучения новых модных фреймворков и языков, которые всё равно через несколько лет потеряют актуальность, вместо того, чтобы вкладывать свои время и усилия в то, что никуда со временем не денется. Но больше всего я против отрицания понятия «квалифицированный труд», отношения к разработчику как к бездушному, легко заменяемому трудовому ресурсу, а не квалифицированному специалисту, а к его труду как к чисто механическому. Есть люди, чей мозг лучше заточен под эффективное применение готовых решений, а есть те, у кого мозг заточен под создание чего-то нового в нетипичных ситуациях, когда подходящих готовых решений нет. И те, и другие одинаково нуждаются в стабильном доходе, но при этом вторые почему-то едва ли востребованы и вообще будто стали считаться лишними.
Свои библиотеки и микрофреймворки, которые я писал для себя, выполнены в соответствии с принципом KISS, то есть максимально простым и надёжным способом, с минимумом зависимостей от чего бы то ни было: дополнительного софта, каких-то пакетных менеджеров, Docker — в общем, всего того, что не обязано быть в системе из коробки и в чём конечный пользователь не обязан разбираться. Языки программирования я предпочитаю такие же. Это значительно снижает вероятность багов, повышает общую надёжность системы и облегчает отладку (без поисковиков и StackOverflow). А главное — экономит время, позволяет в процессе разработки освободить ресурсы своего мозга и направить их полностью на задачу, так как не требуется учитывать множество нюансов языка и фреймворка, соблюдать тщательно вызубренные сотни правил и формальностей (вплоть до требований к количеству комментариев в коде), боясь что-нибудь не учесть и чувствуя себя как на минном поле. Число Миллера, примерно соответствующее объёму кратковременной памяти нашего мозга, не такое уж и большое и в среднем равно 7 ± 2 элементам. Вместо того, чтобы думать обо всех этих формальностях, куда полезнее думать о более важном — что нужно учесть, чтобы не допустить багов, какие фрагменты кода в каких ситуациях как себя могут повести и могут ли привести к уязвимостям. А ещё я всегда исхожу из того, что, решая проблему, надо при этом не создавать другие. Если решая проблему ты создал другую (которую потом тоже придётся решать, тебе или кому-то), то суммарно ты ничего не улучшил. Эх, если бы в IT все этим руководствовались…
Отдельно стоит отметить явную избыточность слоёв абстракции в современном софте, к которой привела чрезмерная увлечённость фреймворками и готовыми решениями (которые в свою очередь тоже используют готовые решения, и так далее по рекурсии). Когда программа делает то же самое, что её аналог 15-летней давности, но при этом жрёт в десятки раз больше. Наглядный пример: мой Atom с плагинами занимает 431 МБ памяти, тогда как Geany (тоже с плагинами) — 7 МБ. Всё, чего мне не хватает в Geany — это несколько курсоров и сниппеты, как в Atom, в остальном же эти редакторы не сильно отличаются по функциональности. Или какой-нибудь современный интернет-магазин, у которого одна страница прогружается несколько секунд (около 750 запросов), требует процессор минимум уровня Core i3 для более-менее приемлемой производительности и хотя бы гигабайт свободной памяти. Тогда как раньше того же самого хватало для запуска нескольких экземпляров какой-нибудь 3D-игры. Если сравнивать, как было и как стало, то это можно назвать разве что усложнением, но не прогрессом.
Итак, что мы видим в итоге? Во сколько раз современные фреймворки и методики упростили разработку, во столько же раз и усложнили её, вынуждая бороться с их ограничениями и сложностью. Во сколько раз увеличились объёмы памяти, производительность современного железа и скорости передачи данных, во столько же раз уменьшился и КПД современного программного обеспечения, компенсировав улучшения в железе. А по итогу мы решаем те же задачи и за то же время, что и 20 лет назад, только другими путями. Похоже на «Тришкин кафтан», о котором Крылов писал более 200 лет назад, не так ли? Но мало кто это замечает, все привыкли и уже мало кому это кажется чем-то ненормальным. Сюжет антиутопической комедии «Идиократия» уже не кажется таким смешным и всё более становится похожим на пророчество…
Сам со статьёй согласен, особенно вот с этим:
И вот с этим:
Но на мой взгляд, сколько бы таких статей не писалось, они мало на что повлияют. Потому что проблема тут в другом: в том, что закончился, выражаясь языком соционики, «альфийский период» в IT, когда разработчик был также и лицом, принимающим решение. Сейчас же решения зачастую принимаются лицами, которые не умеют программировать вообще, зато хотят перестраховаться от возможных рисков. Поэтому и получается такое. Тогда как в идеале должно быть так: разработчик (или даже инженер в широком смысле) решает ту или иную задачу, как считает нужным и эффективным, а уже потом продажники ищут способы продать то, что получилось. Но увы, непонятно, как переделать мир в эту сторону…