Простота — это великое благо, но для её достижения необходим усердный труд, а для понимания — хорошее образование. Чего не скажешь про сложность, которая продаётся намного легче». — Эдсгер Дейкстра
На мой взгляд, во многих командах разработки есть одна проблема. Будь то на собеседованиях, в заявках на повышение или в ходе дизайн-ревью, наиболее убедительно выглядит тот, кто создал нечто крайне сложное. Если же ты разработал какое-то простейшее рабочее решение, его вряд ли оценят.
Естественно, это происходит ненамеренно. Никто не строит коварных планов в духе «А давай сделаем так, чтобы повышение получали только те, кто всё усложняет». Но такое нередко происходит, когда в компании неверно оценивают проделанную сотрудниками работу.
Давайте представим двух разработчиков из одной команды — девушку и парня. Девушке поручили реализовать некую функциональность. Она проанализировала несколько возможных решений и выбрала самое простое — всего в 50 строк кода. Это решение легко читать и тестировать, и его смогут без проблем понять другие разработчики в будущем. В течение двух дней девушка реализует эту фичу, проверяет, отправляет в продакшен и переключается на другие задачи.
Парню досталась похожая задача. Он тоже её оценил, но увидел «более надёжный» вариант реализации. Он вносит дополнительный уровень абстракции, создаёт для взаимодействия между компонентами систему «издатель-подписчик» и добавляет структуру конфигурации, чтобы в будущем функциональность можно было «расширить». На всё про всё уходит три недели и несколько пул-реквестов, а когда он делится в чате команды документом с описанием всего процесса, коллеги реагируют восторженными эмодзи.
Проходит какое-то время и наступает момент повышения. Работа, проделанная парнем, уже звучит очень весомо: «Спроектировал и реализовал масштабируемую событийно-ориентированную архитектуру, добавил переиспользуемый уровень абстракции, который начали применять несколько команд, и создал структуру конфигурации для будущего расширения функций». Всё так и говорит об уровне старшего специалиста.
А вот про реализацию девушки сказать особо нечего. «Реализовала фичу X». Всего три слова. Хотя её работа была лучше. Но в свете минимализма и простоты заметить это сложно. Нельзя убедительно расписать то, что ты не создавал. Поэтому никого не повышают за то, что он избежал лишней сложности.
Возьмём, к примеру, собеседования. Представьте, что находитесь на этапе проектирования системы и предлагаете простое решение. Одна база данных, простой API и, быть может, дополнительный уровень кэширования. Рекрутёр задаёт вопрос: «А как же масштабируемость? Что, если у вас будет десять миллионов пользователей?» Тогда вы начинаете рисовать на доске больше блоков, добавляя сервисы, очереди и реализуя шардинг БД. Вот теперь рекрутёр доволен.
Всё это лишь говорит нам, что сложность впечатляет людей. Ваш простой ответ не был ошибочным. Просто он был недостаточно интересным. И вы можете впредь начать опираться на этот вывод в своей карьере. По правде говоря, у рекрутёров порой есть веские причины делать акцент на масштабе. Они хотят видеть, как вы рассуждаете в условиях стресса и понимаете ли механизм распределённых систем. Но когда соискатель делает вывод, что «простого оказалось недостаточно», это уже проблема.
Аналогичную картину мы наблюдаем и на дизайн-ревью. Разработчик предлагает чистый и простой подход, на что слышит: «Разве не надо предусмотреть задел на будущее?» В итоге он начинает добавлять слои, которые пока не нужны, и абстракции для задач, которые могут никогда не возникнуть, и гибкость для требований, которые никто не заявлял. И причина не в изначальных условиях задачи, а в ожиданиях ревьюеров.
Я видел, как разработчики создают абстракции, просто чтобы не повторять несколько строк кода, в итоге сильно усложняя его понимание. Да я и сам так делал. Всякий раз кажется, что это правильный ход. Код смотрится более «профессиональным», более продуманным. Но от этого пользователи не получают нужную функцию быстрее, а следующий разработчик, который встретится с этим кодом, полдня будет разбираться в абстракции, прежде чем сможет внести какие-то изменения.
Не спорю, иногда сложные решения оправданы. Если вы обрабатываете миллионы транзакций, то вам действительно могут потребоваться распределённые системы. Если у вас над продуктом работает 10 команд, то наверняка придётся установить границы сервисов. Когда сама задача является комплексной, её решение тоже порой должно быть таковым.
Так что проблема не в самой сложности, а в её неоправданности. Есть разница между «Мы упираемся в предел базы данных — нужно её шардировать» и «Мы можем упереться в предел базы данных через три года, так что давайте шардируем её сейчас».
Некоторые разработчики это понимают. И когда ты видишь их код (и архитектуру), то думаешь «Ну да, конечно». В нём нет никакой магии, заумств и чего-то, что вызывало бы ощущение собственной глупости от того, что ты не можешь всего этого понять. В этом и заключается смысл.
Чтобы стать поистине старшим разработчиком, нужно не просто освоить какие-то дополнительные инструменты или паттерны, но и понимать, когда они неуместны. Наворотить сложности может любой. А вот для её избежания уже требуется опыт и уверенность.
Но что мы реально предпринимаем по этому поводу? Одно дело сказать «не усложняй», и совсем другое — изменить систему мотивации.
Если вы разработчик
Запомните — простота должна быть заметной. Работа не говорит сама за себя. И дело не в том, что она недостаточно хороша, а в том, что большинство систем поощрения не способны её «услышать».
Начните с подачи. «Реализовал фичу X» мало что говорит. А вот «Проанализировал три решения, включая событийно-ориентированную архитектуру и собственный уровень абстракции. Решил, что простая реализация отвечает всем текущим и прогнозируемым требованиям. В итоге за два дня реализовал решение, в котором за шесть месяцев не возникло ни одной проблемы». Это описание всё той же простой работы, но уже с выражением стоящих за ней рассуждений. Решение не создавать что-либо — это тоже решение, причём важное! Так что описывайте его должным образом.
Когда на дизайн-ревью вас вдруг спросят: «Разве не нужно подумать о будущем?», не стоит сразу сдаваться и начинать добавлять слои. Разверните ход мысли: «Вот что потребуется для добавления этого позже при необходимости. А вот во что нам встанет добавление этого сейчас. Думаю, стоит подождать». В этом случае вы не идёте в отказ, а лишь показываете, что всё продумали. Вы учли всю сложность и решили не идти на неё.
И обязательно проговорите эти моменты со своим менеджером. Что-то в духе: «Хочу, чтобы описание моей работы отражало не только сам код, но и принимаемые мной решения. Давайте решим, как это лучше оформить для моего следующего ревью». Большинство руководителей оценят такой подход, так как вы упрощаете им работу, предлагая использовать формулировки, которые помогут им аргументировать ваши решения.
Хорошо, представим, что вы делаете всё именно так, но в вашей команде всё равно повышают того, кто создаёт самые мудрёные системы. Из этого тоже можно сделать полезные выводы о месте, где вы работаете. В некоторых корпоративных культурах действительно ценят простоту. В некоторых же об этом только заявляют, а на деле награждают за обратное. Если вы оказались в среде второго типа, то можете либо играть по её правилам, либо искать место, где признают и ценят здравые рассуждения. Но вы уже хотя бы будете понимать, где находитесь.
Если вы руководитель
В этом случае на вас лежит больше ответственности. Именно вы определяете основы для системы поощрения, будь то осознанно или нет. И проблема в том, что большинство критериев оценки ориентированы на награду за сложность, даже если это не закладывалось в них изначально. Ценность определяется размером и охватом реализованной фичи. Но эти показатели зачастую не играют существенной роли. И здесь также важно учитывать, чего автор в своей реализации избежал.
Поэтому старайтесь изменить постановку вопроса, и на дизайн-ревью вместо «А мы учли возможность масштабирования?» спросите: «Как будет выглядеть простейший вариант фичи, и какие сигналы укажут на необходимость чего-то более сложного?» Один только этот вопрос уже изменит правила игры, поставив во главу угла простоту и потребовав обоснования сложного решения — а не наоборот.
При обсуждении повышения выражайте сомнение в заявках, где просто перечисляется создание красиво звучащих систем. Спросите: «А было ли это всё необходимо? Действительно ли здесь нам требовалась система «издатель-подписчик», или же она выглядит удачным решением только на бумаге?» И когда разработчик из вашей команды реализует что-то простое и понятное, помогите ему описать свою работу в стиле «Оценил несколько подходов и выбрал простейший, который полноценно решал задачу». И подобное описание будет звучать убедительно в контексте повышения, но только если вы действительно считаете его таковым.
И ещё одно — обращайте внимание на то, что заявляете в открытых диалогах. Если в чате вашей команды то и дело будет упоминаться большой и сложный проект, под него все и будут подстраиваться. Начните одобрительно высказываться в отношении тех, кто удалил лишний код. Тех, кто сказал «нам это пока не нужно» и оказался прав.
В конечном итоге, если мы продолжим поощрять сложность и игнорировать простоту, то можно будет не удивляться, что сложность мы и получим. Но исправить это нетрудно. О чём, собственно, и речь.
Комментарии (55)
rpc1
13.03.2026 14:09В статье правильный посыл: нужно уметь показывать различные опции и обосновывать свой выбор, в противном случае может сложиться впечатление, что разработчик может только в просты решения.
NickDoom
13.03.2026 14:09…и яду побольше, чтобы было сразу понятно, где эти «решения взрослых дядек» уже сидят :-D
Kano
13.03.2026 14:09Обоснования не всегда работают. Чаще покивают головами, но в итоге продавят своё решение потому что оно им ближе и "понятнее"
Chernysov
13.03.2026 14:09Очень точное наблюдение. На практике проблема ещё глубже : сложность легче демонстрировать, чем простоту. Сложную архитектуру можно показать диаграммами, новыми сервисами, очередями, слоями абстракций. Она создаёт видимый объём работы. Простое решение часто выглядит так, будто «ничего особенного не произошло».
Но в зрелой инженерии ценность обычно определяется не тем, что было добавлено, а тем, какой сложности удалось избежать.
Хороший инженер способен построить сложную систему.
Опытный инженер способен понять, почему она пока не нужна.
Самая дорогая часть любой архитектуры — это не её создание, а её долгосрочная стоимость: поддержка, когнитивная нагрузка, время онбординга новых разработчиков, риск скрытых взаимодействий между компонентами. Поэтому каждый дополнительный уровень абстракции должен платить «арендную плату» — приносить реальную ценность уже сейчас, а не гипотетически в будущем.
Интересно, что во многих сильных инженерных культурах архитектурная зрелость измеряется не количеством паттернов, а наоборот — способностью удерживать систему простой настолько долго, насколько это возможно.
Потому что сложность всегда можно добавить позже. А вот удалить её из живой системы значительно труднее. Именно поэтому один из самых недооценённых инженерных навыков — это способность сказать:
«Мы понимаем, как это можно усложнить. Но сейчас это не нужно».
Как то так. ИХМО
LeoKudrik
13.03.2026 14:09Золотые слова! У нас в России, вот уже лет 15 по моим наблюдениям, кол-во архитектурной астронавтики выросло в разы и удержать архитекторов/лидов от внесения необоснованой сложности - дорогого стоит. Проблема в том, что последствия этой сложности проявляются спустя годы разработки и цена таких ошибок очень велика.
Kano
13.03.2026 14:09Я побывал с двух сторон крайностей и могу сказать что выбор всегда идёт к тому что понятно и привычно решающей стороне. Все остальные доводы не имеют значения, только заработав репутацию и кредит доверия можно внедрять свои решения
dayman092
13.03.2026 14:09Да, так в любом деле, никакой логикой и аргументами не объяснишь, большинство смотрит только на авторитет, но хорошо, что в моем ИТ мире такое не часто встречается и гениальные люди чаще находят себя, чем например на заводах и политеке.
Вспоминается фильм Идеократия, где после попыток логически объеснить, герой сказал, что он умеет разговаривать с растениями и они сказали, что хотят воды.
appet1te
13.03.2026 14:09У кого оценка у того и власть. И если держатель оценки не понимает, то он оценивает как низкую ценность. Не важно, что он не понял. По своей или не по своей компетентности, или некомпетентности
grvelvet
13.03.2026 14:09Сложную архитектуру можно показать диаграммами, новыми сервисами, очередями, слоями абстракций. Она создаёт видимый объём работы. Простое решение часто выглядит так, будто «ничего особенного не произошло»
Показать простую архитектуру, а графиками и диаграммами показать, сколько проблем и затрат избежит босс
develmax
13.03.2026 14:09Всегда в своей работа предлагаю все возможные варианты решения от простых до сложных и стараюсь по возможности использовать более простые решения. Везде есть свои плюсы и минусы, но в простых решениях есть существенный плюс - оно более надежное само по себе, так как, как правило, в нем будет меньше составных частей, поэтому его легко и дешевле поддерживать, оно очевидно как работает и дорабатывать его проще. Но не всем и не всегда подходит простое решение.
Stan91
13.03.2026 14:09Хз, как я заметил повышают не за технические решения, а за то что ты решаешь бизнесовые проблемы быстро и чётко (по крайней мере начиная с мидловой позиции) - как именно не особо интересно никому. Это не есть плохо, просто в принципе пофигу что ты там нарешал, главное чтобы успел по сроку, выполнил требования и уложился в ограничения. Хоть доску положи, хоть лифт построй, хоть тушкой, хоть чучелком )
GentleFly
13.03.2026 14:09Так о том то и речь. Выше, в комментариях , уже упомянули тех кто быстрых решений бизнесу дал и свалил в туман, с авансом. А в итоге все убрали. Ценность простых решений очень хорошо проявляется на длинной дистанции. И для бизнеса и для психологического здоровья все команды. А здоровье команды хорошо сказывается на бизнесе :) Да и простые решения не всегда быстые, как требуют проработки путей. А если результат 10 строк, а потрачена неделя ... То вероятность возникновения вопросов, к эффективности исполнителя, резко возрастает.
Dmitrii_Zz
13.03.2026 14:09Очень странно измерять эффективность в количествах строк кода, а не в комплексе всех нюансов и сложности самой задачи. Тогда допустим какая разница сколько кода будет написано, если условный срок по задаче 1 неделя и разработчик в этот срок уложился...
themen2
13.03.2026 14:09А как потом разгребать этот говнокод через 2 года? Или вы там уже не будете работать?
winkyBrain
13.03.2026 14:09А вот про реализацию девушки сказать особо нечего. «Реализовала фичу X». Всего три слова. Хотя её работа была лучше
потому что так нужно было для истории?) я не увидел никаких критериев оценки задачи персонажей, чтобы можно было сделать вывод, чья работа лучше. быстрее, проще - да, это прямым текстом написано. лучше? кто сказал, кто оценил?
vlsnake
13.03.2026 14:09Простота всегда в почете только для того, чьи цели она преследует. Все различие будет в мотивации, если мотивация "повышение", то "простота" теряет свои плюсы. "Адекватность" в подавляющем большинстве компаний не является мотивацией.
lamerok
13.03.2026 14:09Не знаю, может так где то и есть, но обычно повышают, за то, что твоё решение денег конторе приноси , а какое оно менеджеру грубо говоря наплевать, ну и ещё расходы на поддержку минимальны.
По моему опыту, делал долго но качественно, никто не вспомнит, что долго делала. Сделал быстро и с багами, все будут помнить только про баги.
А про способ решения вообще никто не спрашивает из тех кто принимает решения по повышению. Смотрят только на результат в деньгах.
akakoychenko
13.03.2026 14:09но обычно повышают, за то, что твоё решение денег конторе приноси
Нет. Это может работать в шарашках на 5 человек, где фаундер знает каждую задачу.
Человек от 100 уже никто не знает, какое решение принесло сколько денег, и, принесло ли, или отняло. И, об этом и статья, что сложное решение создаёт видимость, что принесло ценность
eungenue
13.03.2026 14:09А потом простое решение просто работает и его никто не замечает. А потом что-то сложное ломается в проде, от чего подгорает у всей конторы, общими усилиями сутки напролёт что-то усиленно «чинят, фиксят», в том числе эта девушка тоже помогает. В итоге сильный программист наконец находит слабое место в своей «сильной» архитектуре (кому как не ему, знать, где там и чего искать), торжественно фиксит его на радость руководства, что наконец избавил всех от проблем, за что еще и лычек и ништяков получает. А девушка - нет.
y_u_h
13.03.2026 14:09Сложное решение можно распространить (ровно так оно и происходит) наверх в очень больших масштабах, записать в заслуги по координации и внедрению многим начальникам в свои достижения с последующими плющками (финансирование, расширение штата. А чем больше штат подчинённых, тем зачастую выше аппаратный вес начальника). Плюс за рацуху давно не премируют, ибо лучше промолчать, пусть буржуй и дальше прыгает со своей сложной системой/производством, а я, за свои условные 45 тыщ, посиду на стуле ровно.
//Выше ИМХО, не более..
yamifa_1234
13.03.2026 14:09А вот «Проанализировал три решения, включая событийно-ориентированную архитектуру и собственный уровень абстракции. Решил, что простая реализация отвечает всем текущим и прогнозируемым требованиям. В итоге за два дня реализовал решение, в котором за шесть месяцев не возникло ни одной проблемы». Это описание всё той же простой работы, но уже с выражением стоящих за ней рассуждений.
А если в силу опыта, рассуждения как такового не было. И разработчик интуитивно понимает что надо сделать просто, потому что так проще и быстрее. И в целом простой код потом не сложно доработать.
И теперь выходит, прежде чем писать отчёт сначала нужно найти более сложные пути?)
Я когда-то так диплом писал. Я сразу знал что на ПЛИС арктанген считается через CORDIC, но для объема диплома я нашёл ещё пару методов которые ни в какие ворота на Плис не укладывались, перечислил и описал их, а потом "только один метод нам подходит, это кордик")))
myswordishatred
13.03.2026 14:09Я сразу знал что на ПЛИС арктанген считается через CORDIC, но для объема диплома я нашёл ещё пару методов которые ни в какие ворота на Плис не укладывались, перечислил и описал их, а потом "только один метод нам подходит, это кордик")))
Ну в целом-то так и надо. Как иначе формально показать, что вы не с потолка взяли метод расчёта, а проанализировали разные способы?
yamifa_1234
13.03.2026 14:09ну как как?) если в случае с дипломом то образование я еще не получил, только оценки в зачетке. но если рассматривать вариант с работой, то наличие образование уже должно говорить о том, что я имею какие то знания, которые помогут мне идти по короткому пути.
Greyson
13.03.2026 14:09Давно сам хотел написать статью на эту тему, но Вы меня определили. Спасибо за отличный материал, который стоит положить к себе в заметки как руководителям, так и разработчикам.
Сам на текущем проекте постоянно сталкиваюсь с наследием прошлых команд, которые любили оборачивать всё в сложные, многослойные системы везде, где могли дотянуться. Что мы получили в итоге при поддержке старых фичей - чтобы понять, что происходит при нажатии на кнопку, нужно пробраться через несколько уровней абстракции, порой через несколько модулей, в итоге увидеть примитивный запрос на бек или поход в базу в одну строчку. Зато со стороны такое решение кажется максимально гибким и масштабируем. По факту же, порой трудозатраты на добавление функционала, почти равны написанию с нуля. А "идеальная" архитектура прошлой команды, в прямом смысле превратилась в техдолг нынешней.
akakoychenko
13.03.2026 14:09Более того. На уровне выше это работает ещё лучше. Серьёзный менеджер имеет большой хедкаунт и большие бюджеты. Не может лох с 3мя подчиненными так же зарабатывать и ездить на такой же машине, как серьёзный победитель по жизни с 3000, даже, если он смог силами 3х все автоматизировать и делать тот же объем ценности. Соответственно, усложняторы-инженеры часто образуют симбиоз с усложняторами менеджерами.
HardlinePeak936
13.03.2026 14:09Давайте, я кое-какую фразу приведу: «Ребят! Очнитесь! Нам платят не за это! Нам сейчас нужно реализовать X, а не сделать задел на будущее. Если нам в будущем понадобится расширить, то мы расширим, за что нам ещё заплатят. Не берите лишнюю работу! Пишите чистый и хороший код, чтобы потом, в этом самом будущем, не пришлось копаться в дерьме!»
StasTukalo
13.03.2026 14:09да временами складывается ощущение, что эти "ребята" сами себя уважать не будут, если дважды два без десяти уровней абстракции посчитают.. и даже если ты их авторитетом сподвигаешь (или административно заставляешь) делать проще - эти "ребята" грустнеют, считают тебя ретроградом, старпёром и всяческим врагом прогресса, в отличии от них ))
и это беда, с которой я в принципе не понимаю как быть((
vvbob
13.03.2026 14:09Идеал это самое простое для текущей задачи и требований решение. Пытаться поиграть в Кассандру и предсказать что там потом понадобится, практически всегда это предсказание будет мимо, зато переусложненный код будет годами висеть в кодовой базе и отжирать время жизни и нервы у твоих коллег и тебя самого. Хуже всего что и выкинуть его потом может оказаться слишком сложным.
Как по мне - простое и понятное решение всегда можно переписать и усложнить, когда это реально потребуется, а вот наоборот работает крайне редко, переусложненный лабиринт абстракций и нагромождение паттернов добавленных по принципу "что-бы было", не так то просто упростить, потому что истинный функционал часто маскируется всей этой сложностью.
StasTukalo
13.03.2026 14:09практически всегда это предсказание будет мимо, зато переусложненный код будет годами висеть
золотые слова. как бы только вбить их в буйные головушки))
atues
Хуже того - еще и начнут искать способ избавиться от такого разработчика. Не везде и не всегда, но случается. Со мной, к примеру, такое было. Даже обозвали "саботажником" ))). Расстался с легким сердцем
Yura_PST
Аналогичный опыт, даже с "саботажником".
NickDoom
…когда меня завкафедрой порекомендовал на производство, я начал с того, что повыкидывал всё лишнее, после чего моя зарплата удвоилась. Те, кто пропихнули это лишнее в своё время, как я потом узнал, получили аванс и растворились в воздухе, так что моя критика очень ко двору пришлась — типа «о, а этот вчерашний студент тоже понимает, что те два осла были два осла» :) Как я ещё более потом узнал — они тупо скопипастили пример из ПДФки, в котором было, естественно, максимальное количество всего на все случаи жизни, а в разработку не умели :) Типа той недавней статьи про «передавал мои запросы в чатгопоту» %)
Всякое бывает.
Qweritos
NickDoom
Да-да, два дохтура :-D
Vitrehnut
Вы хоть думали над чем работали или вам дали задачку написать?