Как программисты дурят бизнес?

Здравствуйте, меня зовут Дмитрий Карловский, и я.. хочу рассказать вам о том, как мы, программисты, осознано или нет обманываем бизнес, вынуждая его тратить много денег ради мизерного выхлопа. Можете глянуть видео запись, а можете почитать далее несколько расширенную текстовую расшифровку..

А можете почитать несколько расширенную текстовую расшифровку с более выверенными формулировками..

Я почти 30 лет в программировании, из них 20 занимаюсь этим профессионально. Вот наиболее известные компании, где я работал..

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

Работал я профессионально как с различными noname велосипедами, так и с довольно известными технологиями..

Это конечно далеко не всё, с чем я знаком, это лишь то, за работу с чем мне платили деньги.

Кто не узнал себя в этом списке? Значит мы крутимся в разных экосистемах, и нам с вами будет о чём поговорить.

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

Есть ли тут джуны? Надеюсь, мой рассказ не отпугнёт вас от желания пройти весь этот путь.

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

А есть ли синьоры? Очень приятно, что меня пришли послушать и серьёзные ребята.

Конечно же писать свои велосипеды!

Все самые крутые разработки когда-то были просто наколеночными велосипедами талантливых людей, которые они не бросили, а улучшали, попутно повышая и свою экспертизу.

Конечно же наших самописных велосипедов!

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

Давайте обсудим эти чаянья, но сперва разберёмся с уровнями абстракций..

Я выделяю 4 уровня решений помимо языкового..

Чтобы проиллюстрировать ключевую разницу между уровнями, позвольте рассказать вам одну историю из жизни..

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

Неудовлетворённый таким положением дел, я взял свой любимый конструктор $mol и сделал аналогичное приложение за 2 часа (я засекал). И оно мало того, что было готово к продакшену, так ещё и обладало большей функциональностью. До сих пор использую его для своих личных нужд практически в первозданном виде..

Но и это ещё не конец! Тут мой коллега берёт платформу 1С и делает аналог вообще за пол часа. Казалось бы, чем выше уровень, тем быстрее разработка. Однако, необходимо признать, что получившееся приложение выглядело так себе, было не удобным, но самое страшное - не хватало некоторых фич, которые платформа не поддерживала вообще. Добавление оных, если и было возможно, то потребовало бы куда больше времени, чем мы сэкономили на использовании более высокоуровневого решения.

Ключевой вывод из этой истории: чем выше уровень решения, тем быстрее вы выполняете типовые задачи, но кастомизации зачастую даются с большим трудом. Зачастую, но не всегда. И $mol тут редкостное исключение, ведь проектировался он мной под простоту кастомизации без компромиссов со скоростью разработки.

На одном уровне абстракции слишком много решений. Какое же выбрать? Конечно же мы отдаём предпочтение крупным корпорациям с кучей бабла. Мы ожидаем, что большая компания потратила кучу времени и денег, чтобы проверить все варианты архитектур, выбрала наилучший из них, отполировала и представила общественности.

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

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

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

По хорошему, его надо было бы осовременить, и тогда получилось бы что-то типа $mol. Фактически кроме BEM и $mol сейчас нет ни одного решения, которое бы действительно решало проблемы большого энтерпрайза, а не просто выглядело как энтерпрайз (привет, Angular).

Но, под давлением ситуации на рынке труда, где любой войтивайти, выучивший за месяц, как писать шаблоны на JSX, пишет у себя в резюме Senior React Developer, Яндекс отказался от своего решения в пользу React. Вы только гляньте, как разработчики буквально резали свою архитектуру по живому, чтобы хоть как-то приспособить React под свои нужды:

Получается абсурдная ситуация: технологически маленькая экстремистская компания FaceBook диктует огромному православному Яндексу как писать код. И ладно бы диктовала что-то хорошее. Но нет, код только деградирует. А ведь именно такие крупные компании как Яндекс имеют все возможности разрабатывать и внедрять лучшие технологические решения, двигающие индустрию вперёд. Но вместо этого.. компании поменьше ориентируются на выбор крупных компаний, и всё катится во всем известное место.

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

Одним из таких проектов в своё время стал, например, AngularJS. Многие компании тогда делали свои стартапы именно на нём. И сколько же счастья было в их глазах, когда Google такой вышел и сказал, мол весь ваш только что написанный код теперь легаси, и предложил полностью переписать его на совершенно другом фреймворке с похожим названием - Angular. Что ж, спи спокойно AngularJS, ты прожил почти 6 лет.

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

Так, например, случилось с моей интеграцией Angular + MobX + SuspenseAPI, позволяющей капитально снизить сложность и, как следствие, стоимость разработки на Angular.

Или с более амбициозным проектом - легковесным WYSIWYG редактором, который и для комментариев было бы не дорого затянуть, и документы на сотни страниц можно было бы редактировать с pixel-perfect выводом на печать.

Ну ладно, будем верить в долгую поддержку..

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

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

Если взять хорошее техническое решение, то оно обычно настолько просто в использовании, что зачастую достаточно краткого описания, несколько примеров, и можно идти в бой.

В переусложнённых же решениях так просто уже не разберёшься. Так что толмуды текстов, кукбуков, видеоуроков становятся жизненно необходимыми. Иначе вообще ничего сделать не получится.

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

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

Ага, держи карман шире! Случаев обратного на моём веку было много, но наиболее ярким был связанный с Angular Router, который не обновлял адрес ссылки, когда менялось значение поля, от которого он зависел.

Казалось бы, обеспечение инвариантов - это основа любой реактивной системы. Оно должно работать как часы, иначе разработка превращается в ад отладки. То есть этой проблемы не должно было быть в принципе - она не должна допускаться уже на уровне архитектуры..

Но её не просто выпустили в прод, но и чинили несколько лет, исправив лишь в 10 версии. А до тех пор пользователи плакали, а прикладные разработчики тратили кучу времени на придумывание воркэраундов, чтобы хоть как-то с этим жить, добавляя ко всем ссылкам такого рода костыли..

Они писали статьи и записывали видео о проблеме, которой не должно было быть вообще. И это лишь одна из многих, ведь Angular вышел в свет крайне сырым. Обилие проблем и сложность их решения - следствие переусложнённости решения. Даже самая божественная поддержка здесь бы не справилась, а тут она вообще бесплатная.

Есть у меня история и про коммерческую поддержку коммерческого коробочного продукта SAPUI5 от компании SAP. Делали мы как-то на нём бэкофис для маркетологов Ленты. И вот, сделали мы интерактивную табличку на 30 строк, а она так сильно тормозит, что пользоваться этим невозможно.

Пишем в поддержку, мол "что за дела? как ускорить?". На что нам был дан потрясающей лаконичности ответ: "а вы не выводите в таблицу больше 20 строк". Прекрасно, следующий месяц мы потратили на рефакторинг с прикручиванием к табличке пагинации.

Вообще, мы здорово налетались с этим коробочным решением: пролетели по срокам, влетели на бабки, а потом ещё и разработчики все разлетелись. Показать эту табличку я вам, конечно, не могу, но могу показать вам кое-что по интереснее. Вот смотрите, табличка на 10 тысяч строк, реализованная за 10 минут предельно наивным кодом..

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

Ну ладно, ничто не совершенно под луной. Но у популярного решения будет и большое комьюнити, и вместе мы решим все проблемы.. Ага, как бы не так..

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

Ладно, наивно было бы ожидать бесплатную помощь..

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

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

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

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

Но это долго, сложно и порой безрезультатно. Так, например, однажды меня хантили в стартап на роль техдира, чтобы я возглавил их разработку, построил архитектуру, собрал команду и вот это всё. Но наше партнёрство сорвалось с буквально такими словами: "ты просто самый звёздный кандидат, идеально нам подходишь, но мы решили делать проект на Реакт". То есть человек был готов доверить мне технический успех проекта, но не был готов доверить выбор.. шаблонизатора? Серьёзно?

Программисты - люди умные и ленивые, так что они быстро смекнули лайфхак..

На другом проекте как раз пилили свой MVC конструктор интерфейсов "на Реакт", где последний отвечал за отображение, которое через MobX реагировало на модель.

Так я и не понял, зачем там, собственно, нужен был Реакт, ведь через тот же MobX легко делать точечный рендеринг безо всякого Virtual DOM. Не говоря уж о том, что ещё проще, быстрее и дешевле было бы взять, высокоуровневый $mol, и за пару месяцев допилить его под свои нужды, а не решать несколько лет детские болезни в своём велосипеде.

Но, как мне не раз заявляли, "использовать не распиаренные технологии - большой финансовый и продуктовый риск".

Вот и получается, что бизнес теряет время и деньги, пока программисты развлекаются велосипедостроением, тычась как слепые котята из стороны в сторону: вчера были классовые компоненты, сегодня - функциональные; вчера всё заворачивали в HOC-и, сегодня - внедряют Hook-и; вчера хранили состояние в MobX, сегодня - в Redux. И это всё ещё "на React".

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

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

Так, например, недавно я столкнулся с Самокатом. Это food-tech стартап такой. За кучу денег наняли толпу программистов. Они взяли всё самое модное: React в качестве "кроссплатформеннго фреймворка"; ReactNative, чтобы летало на мобилках; GraphQL для эффективного общения с сервером; MobX для хранения состояния. Не знаю как последний сюда затесался. Думаю скоро на Effector перепишут, а то MobX уже выходит из моды.

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

У меня, конечно, не последний айфон на Apple M1 Max, но реально, этот результат 4 лет разработки, чтобы показать каталог на пару десятков товаров, - никуда не годится. То чувство, когда накосячили другие, а стыдно мне. Ведь я тоже из этих, из фронтендеров. Но как пользователь я плачу всё больше и больше, ибо кейс Самоката не единичный, а тенденция.

Мы, программисты, уже настолько заврались, что обманываем не только бизнес, но и своих коллег, и даже самих себя. Вы только гляньте пресс-релизы от больших компаний, где они хвастаются, как хорошо оптимизировали свои приложения..

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

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

Однажды я работал в Райке, где мы пилили проект на JavaScript + ExtJS + собственные велосипеды. Только-только отвязали его от JSP. И тут приходит к нам новый разработчик, который очень хочет попробовать язык Dart от Google в деле. Долго ходил он обедать с техдиром, пока таки не убедил его прыгнуть в этот омут с головой.

Причём главный аргумент был, вы только не смейтесь, что в JavaScript (и как следствие в TypeScript) много разных библиотек разного качества, и приходится выбирать, а для Dart есть лишь прекрасная стандартная библиотека от Гугла, и выбирать больше не из чего.

Эта авантюра обернулась в превращение проекта в лоскутное одеяло с бандлами на десятки мегабайт. За 8 лет они вложили кучу средств в продвижение Dart, найм кучи программистов и их переобучение, перепробовали сырой Dart, PolymerDart, AngularDart, Dart + OverReact, и, наконец, пришли к TypeScript + React. На моей практике это выдался самый дорогой эксперимент, выбросивший миллионы долларов в трубу с получением в итоге тонн легаси кода, которые неизбежно придётся снова переписывать.

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

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

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

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

Можно назвать это "разработкой через анализ", по аналогии с модной сейчас "разработкой через тестирование". Раньше на предложение написать тесты менеджер отвечал нам, что "сроки горят, давай потом". А потом так и не наступало, код без тестов было сложно поддерживать, а тот же менеджер приходил с претензией "почему на перекрасить кнопочку нужно 2 месяца?!?" и слушать не хотел о том, что это последствия его недальновидного решения.

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

Как говорил один мой коллега: ты начальник - я дурак; я начальник - ты дурак.

Но позвольте напомнить вам, что вы не рабы, а интеллектуальная элита современности. Вы создаёте новые информационные миры и только вы имеете квалификацию и талант определять, как они будут работать.

Так что поднимите голову. Расправьте плечи. Честно и прямо объясните бизнесу, что это не он покупает вас как программеров лёгкого поведения, а это вы даёте ему возможность вложить в вас свои средства, чтобы заработать гораздо больше.

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