Здравствуйте! Сегодня мне хотелось бы обсудить с вами один армейский принцип, который может оказаться невероятно полезным при написании и поддержке вашей кодовой базы.
Почему единообразие — это не про красоту, а про выживание
Давайте начнём с осмысления принципа, отражённого в заголовке статьи. Представьте себе 100 человек в вашем подчинении. У половины из них надеты уставные сапоги или фуражки, у другой половины — нет. В итоге для вас, как для командира, предпочтительнее, чтобы все были одеты единообразно, пусть даже не по уставу, чем чтобы половина была уставной, а половина — нет. И это касается не только формы, но и любого аспекта воинского устава: от распорядка дня до способа связи или подачи доклада. Если где‑то наблюдается отклонение, то пусть оно будет единообразным для всех до тех пор, пока не удастся вернуть всё к уставному стандарту.
Почему так? Единообразие снижает энтропию, упрощает управление личным составом (даже если не все стандарты строго уставные) и повышает дисциплину и сплочённость. Оно помогает командирам поддерживать порядок и быстро выявлять несоответствия. Точно так же в кодовой базе единообразие облегчает контроль, понимание и восприятие всего проекта.
Легаси как место столкновения стилей
Допустим, вам достался легаси‑проект, который теперь нужно развивать и поддерживать. Худшее, что вы можете сделать, — запрыгнуть со своим уставом в чужой монастырь и начать внедрять свои порядки хаотичным и фрагментированным образом.
Начнём с нескольких простых примеров:
Наименования. Вы видите какое‑то название, которое вас не устраивает. Например, в коде везде написано
usDt, а вы точно знаете, что это плохое сокращение, и его определённо нужно писать какuserData. И вы сразу же начинаете в новом коде именовать переменные правильным для вас образом, не переделав старый код. Это сразу же создаёт вам проблемы: по сути, одни и те же вещи именуются по‑разному, что затрудняет чтение и поддержку кода. Кроме того, поиск нужного элемента во всём коде становится сложнее, ведь приходится искать сразу несколько вариантов одного и того же названия. Чтение кода тоже усложняется. Поскольку ваш мозг имеет свойство распознавать паттерны и, работая с ними длительное время, быстрее воспринимать привычные обозначения, вам придётся постоянно перестраиваться, переключаясь между разными частями кодовой базы.-
Называние сущностей. В проекте что‑то названо не так, как должно быть на уровне бизнес логики приложения. Допустим, сущность
developerна самом деле должна называтьсяadminв соответствии с её функциональностью. Возможно, изначально в проекте админами были только разработчики, но потом появилась возможность выдавать расширенные права и другим пользователям. И вам очень хочется сразу использовать новые, правильные термины в новом коде, не отрефакторив старый код.В результате кодовая база превращается в хаос: в одних местах сущность всё ещё называется
developer, в других ужеadmin, и теперь вам приходится постоянно держать в голове, что это одно и то же. Поиск по коду снова усложняется, потому что вам приходится искать сразу оба варианта. Опять же, чтение и поддержка кода становятся менее удобными, так как мозг ожидает единообразия, а вместо этого сталкивается с непоследовательностью, заставляя вас тратить лишнее время на переключение контекста. Структура HTTP endpoint‑ов API. Некоторые HTTP‑ручки вашего API имеют структуру, которую вы считаете неверной. Допустим, в проекте повсеместно используется подход, при котором все параметры передаются в строке запроса —
/api/users?user_id=123, а вы уверены, что правильнее передавать идентификаторы через путь к ресурсу —/api/users/123. И вам очень хочется сразу писать новые endpoint‑ы по правильному, на ваш взгляд, стандарту, не трогая старые. В результате API становится неунифицированным: одни ручки используют один стиль, другие — другой. Это создаёт путаницу как для вас, так и для внешних потребителей API, которым теперь приходится разбираться с разными схемами работы. Интеграции усложняются, документация становится менее понятной, а поиск и сопровождение API требуют больше времени, так как больше нельзя просто полагаться на единообразие структуры endpoint‑ов.-
Фронтенд. Вы работаете над фронтендом приложения и понимаете, что вам не нравится, как выглядят отдельные части формы: например, поля для ввода текста. И вы решаете, что прямо здесь и сейчас замените их на новый компонент с другим API и внешним видом.
Но без чёткого плана и рефакторинга может легко случиться так, что из‑за более приоритетных задач остальные страницы так и останутся со старыми полями. В результате интерфейс вашего приложения теряет визуальное единство: в одних местах используются старые компоненты, в других — новые, и пользователь постоянно сталкивается с разными вариантами оформления одного и того же элемента. Это вызывает фрустрацию, снижает удобство работы с интерфейсом и делает продукт менее цельным и продуманным.
Очень плохая идея начать писать новые фичи, используя подходы, чуждые проекту, который вы поддерживаете. Пара итераций передачи проекта из команды в команду или смена разработчиков могут привести к тому, что в кодовой базе окажется три варианта названия одних и тех же сущностей, четыре разных способа реализации одних и тех же задач. Либо в приложении появятся страницы и формы с хаотично различающимся внешним видом, что может длиться годами.
И даже если некоторые из этих решений окажутся лучше других, в целом это значительно усложнит поддержку и понимание кодовой базы. Время, необходимое для введения новых разработчиков в проект, существенно увеличится, поскольку им придётся постоянно переключаться между разными подходами, зачастую даже не понимая, какой из них правильный. Со временем возрастёт количество багов, возникающих из‑за разрастающегося хаоса, а также значительно увеличится время на внедрение новых фич. Но как же поступать, если старые, неправильные подходы однозначно нужно устранять?
Как обуздать хаос
Если вы пишете новый проект, ситуация несколько проще: изначально следите за тем, о чём идёт речь в этой статье, и не допускайте появления хаоса. Если же вы работаете с легаси-кодом или в какой-то момент упустили что-то из виду в новом, придётся это исправлять. Когда вы сталкиваетесь с частью проекта или решением, которое, по вашему мнению, однозначно стоит переделать, действуйте согласно заранее составленному плану.
Первое правило: если вы решаетесь изменить подход в проекте (например, изменить правила наименования каких-либо сущностей), составьте чёткий план того, как и в какие сроки приведёте проект к единообразному виду. Главное — в итоге иметь максимально чёткое представление о том, когда код снова будет использовать единый подход в определённом аспекте.
Если сроки определить крайне сложно по каким-либо причинам, обозначьте план регулярных работ по устранению несоответствий в рамках технического долга. Например, вы можете решить, что в рамках вашей техквоты вся команда постепенно перерабатывает код по выбранному новому подходу, и в каждой итерации работ по техническому долгу обязательно берёт участок кода, использующий старый подход, и рефакторит его. Либо можно встроить изменения в любой другой процесс рефакторинга, применяемый для закрытия технического долга в команде. Главное, чтобы этот процесс не был заброшен, а шаг за шагом продвигался к намеченной цели — единообразию кода.
Возможно, вы придёте к выводу, что подход, который вам не нравится, используется только в части проекта, помеченной как устаревшая, и добавление новых фич в неё не планируется. В этом случае можно изолировать старый подход в определённых границах и не допускать его проникновения в новые части проекта до тех пор, пока устаревшая часть не будет полностью выведена из эксплуатации и удалена из кодовой базы.
Второе правило: изучайте тот проект, с которым вам приходится работать. Пытайтесь понять логику и стиль, которым руководствовались предыдущие разработчики. Не всегда это бывает просто и очевидно, но навык распознавания таких подробностей поможет вам не только лучше понять проект, но и осознать собственные подходы к написанию кода. Здесь стоит упомянуть pull request‑ы и code review. При их изучении вы должны искать отклонения от принятого стиля написания кода, обращать внимание на несоответствия используемым подходам и практикам, а также указывать, где можно взять готовое решение, чтобы не плодить лишние реализации одной и той же функциональности.
Кстати, об этом стоит поговорить отдельно. Исследование от GitClear за 2024 год (на основе анализа 211 миллионов строк опенсорсного кода) показывает чёткую тенденцию увеличения количества кода вида «копировать/вставить» и стремительное сокращение перемещённого/отрефакторенного кода. Это очень плохой тренд, вызванный повсеместным использованием ассистентов по написанию кода в IDE. Часто IDE выдают в качестве подсказки готовое решение, которое можно вставить одним нажатием клавиши Tab. Но такое же решение в готовом виде может уже присутствовать в кодовой базе, а порой и в нескольких экземплярах. Именно это способствует стремительному наращиванию энтропии в коде. Результат становится всё более очевидным и болезненным с течением времени, когда всё больше багов появляется из‑за того, что, изменяя одну часть кода и его логику, вы оставляете идентичные фрагменты с устаревшей логикой в других местах проекта.
Третье правило (принцип «разработка через болтологию»): больше общайтесь в команде. Обсуждайте, как и что вы делаете, какие подходы используете, как лучше реализовать те или иные задачи, вызывающие сомнения. Это не только приводит к более чёткому пониманию всей командой того, как пишется код, но и помогает вырабатывать лучшие решения для проекта благодаря плодотворной дискуссии. В конечном итоге ваша цель — кодовая база, которая выглядит и читается так, как будто её писал один человек, с единым стилем и понятными подходами.
Четвёртое правило: используйте линтеры и автоформатирование при сохранении. Да, может быть, в 2025 году это звучит для многих странно, но всё ещё есть команды и разработчики, которые решительно отвергают возможности автоформатирования кода, предпочитая вручную передвигать скобочки и отступы. Однако если вы действительно хотите добиться хорошо читаемого и единообразного проекта, то автоформатирование — одна из лучших вещей, которую можно внедрить в команде. Лично я предпочитаю максимально детерминированные решения, где почти нет места для обсуждения настроек форматирования и линтинга.
На одном конце спектра можно привести пример JavaScript и тот зоопарк подходов, применяемых в разных командах, как должен выглядеть и писаться код: разрозненные файлы с настройками линтера, которые ещё кому‑то нужно дополнительно настроить. А на другом конце — язык Go с его фактически принятым на уровне стандарта инструментом gofmt. Мне особенно нравится сформулированный в Go принцип:
gofmt's style is nobody's favorite, yet gofmt is everybody's favorite. — Стиль gofmt никому не нравится, но gofmt нравится всем.
Также замечательный тезис к этому принципу прозвучал на Gopherfest 2015 года:
То, как gofmt форматирует код, — это даже не то, как Роберту Гризмеру нравится, как выглядит код, а ведь он написал эту программу.
Пятое правило: каталогизируйте, по возможности, все разночтения в подходах, которые вы находите в разных частях кодовой базы. Если некоторые вещи сделаны до вас в разных местах программы совершенно разным образом, то ваша первоочередная задача — постараться определить такие расхождения. А после нужно решить:
Выбрать какой‑то из подходов, который уже используется, и последовательно при возникновении возможности приводить всё к этому единому варианту, начиная все новые фрагменты с использованием этого подхода. Даже если он вам не очень нравится, лучше придерживаться именно его, так как уже есть значительный объём кода, сделанный именно таким образом.
А если ни один из наблюдаемых вами в коде подходов не подходит для гармоничного развития кодовой базы, то нужно выработать новый подход самостоятельно и вернуться к предыдущему правилу. Одновременно с внедрением вашего нового подхода у вас уже должен быть сформирован план, каким образом и примерно в какие сроки вы будете устранять все разночтения.
Заключение: у каждого проекта должен быть тот, кто заботится о нём душой
Главный принцип во всём, что вы делаете, — знать меру и искать золотую середину. Иногда, волей‑неволей, приходится принимать решения, противоречащие этим принципам. Возможно, кодовая база настолько огромна и плохо написана, что вы решите полностью переписать проект. В таком случае новые фичи реализовывать следует исключительно в новой, специально созданной кодовой базе, куда итерационно будет переноситься старая функциональность, а в старую добавлять только исправления в рамках технической поддержки. Однако при каждом таком шаге необходимо чётко понимать, почему вы отступаете от первоначальных принципов и к каким последствиям для развития кодовой базы это может привести. Худшее, что может случиться с проектом, — превратиться в «проект‑сироту», о котором никто не заботится и никто не думает в долгосрочной перспективе. Поэтому старайтесь находить инженерное удовлетворение даже в работе с легаси‑кодом, если он был передан вам во владение. Со временем, с каждой итерацией рефакторинга вам будет всё приятнее осознавать, насколько сильно проект преображается благодаря вашим усилиям.
Комментарии (10)
mvv-rus
18.02.2025 13:27Заключение: у каждого проекта должен быть тот, кто заботится о нём душой
Я ещё со времен своей комсомольской юности усвоил, что когда мне говорят "должен", я чисто на автомате задумываюсь: "кому должен" и "почему должен". И здесь, как раз - именно тот случай, чтобы задуматься.
Если руководство считает, то для бизнеса фирмы это нужно - пусть назначает ответственного и платит ему за это деньги, как за часть его трудовых обязанностей.
А так, поскольку результат труда разработчика - эта самая кодовая база - от разработчика отчуждается, то есть принадлежит фирме, то объективно разработчик в качестве этой самой кодовой базы не заинтересован. Разработчику все-таки платят фактически за потраченное им время, а не за достигнутый результат.
То есть, рядовой разработчик продавать фирме вместе со своей рабочей силой ещё и свою душу не подписывался.PS Применимость самого по себе армейского принципа к процессу разработки - как это нарисовано в общеизвестном меме "Программирывай!" - у меня тоже вызывает сомнение: больно уж разное качество типового человеческого материала с которым имеет дело руководитель разработчиков и сержант или младший офицер в армии. Но об этом - как-нибудь потом.
CodeShaman Автор
18.02.2025 13:27Тут уже пошла какая‑то философия о том, как мы подходим к тому, что делаем, и что значит для человека быть профессионалом своего дела. Кто‑то делает любое дело на совесть, как раз "вкладывая в него душу", так как хочет быть профессионалом и гордится тем, что создаёт. И даже если это просто красивое инженерное решение где‑то в глубине бэкенда, о котором ни кто, кроме него не узнает, такой специалист всё равно получит внутреннее удовлетворение от того, что смог создать что‑то настолько элегантное и нетривиальное, что ему самому будет просто хорошо – как раз на самой этой душе.
Исповедовать подход «задачу сделал и плевать, как сделал, для бизнеса всё‑равно - не проверят, а я, может, через полгода ещё раз работу сменю» для кого‑то может быть и путь, но вряд ли это то, что можно современным языком назвать «путь джедая». Почему сразу о сменить работу через пол года речь? Просто потому, что если разработчик планирует работать на проекте долго, 5-10 лет или даже больше, то в первую очередь делать все качественно и вкладывать душу в его же интересах. Ему этот код и дорабатывать и поддерживать спустя годы. Да и как расти над собой, в том числе как инженер или разработчик, если конечная цель только одна – «плевать, как сделал, задачу формально закрыл и забыл».
Наверное, тут фундаментальная разница ещё в том, как человек относится к своей работе как таковой. Если разработчик работает от звонка до звонка и в гробу видел вообще всё это, поскорее бы рабочий день подошёл к концу, то, наверное, это даже как‑то грустно. Не испытывать вообще никакого огонька, никакого желания сделать классно, красиво и по‑инженерному правильно, при этом не для кого‑то, а в первую очередь для себя – это или терминальная стадия выгорания, или, может, изначально не та выбранная стезя в жизни.
На появившийся постскриптум могу только дать комментарий: вся статья как раз о том, почему этот принцип можно применять и каким образом. Соответственно, даже и добавить нечего.
mvv-rus
18.02.2025 13:27Кто‑то делает любое дело на совесть, как раз "вкладывая в него душу", так как хочет быть профессионалом и гордится тем, что создаёт.
Как я уже написал, душа разработчика в предмет трудового договора не входит: хотя бы потому, что договоры, касающиеся души, подписываются своей кровью, а в современном делопроизводстве такая практика не принята.
Далее, профессионал - это всего лишь тот, кто получает за свою работу деньги, не более. Гордиться же тем, что у тебя по условиям договора всё равно заберут - это IMHO просто глупость.
Но менеджмент такое отношение наемных работников любит, да. Потому что от того, что можно часть оплаты работнику заменить его моральным стимулированием, менеджменту хорошо: бюджеты не превышаются, задачи выполняются, а то ещё и бонусы капают.Просто потому, что если разработчик планирует работать на проекте долго, 5-10 лет или даже больше, то в первую очередь делать все качественно и вкладывать душу в его же интересах. Ему этот код и дорабатывать и поддерживать спустя годы.
Нет - не в его интересах. Потому что платят разработчику, так или иначе, за потраченное время. И если разработчику из-за качества кодовой базы пришлось ковыряться дольше, то это время ему будет оплачено, и он в деньгах не теряет ничего.
Да и как расти над собой...
А оно это точно надо, когда по найму работаеешь? Может, лучше расти над собой по модели F.I.R.E. - поднять по молодости побольше бабла, чтобы было на что жить, не работая на дядю, а уж потом - "расти над собой", "получать внутреннее удовлетворение от того, что смог создать что‑то настолько элегантное и нетривиальное, что ему самому будет просто хорошо" и заниматься прочими подобными вещами, а?
Наверное, тут фундаментальная разница ещё в том, как человек относится к своей работе как таковой.
Да, я описываю ситуацию с материалистической с точки зрения, с точки зрения "человека экономического". И считаю, что для нынешнего мира бездушного чистогана это наиболее адекватный подход.
Если разработчик работает от звонка до звонка и в гробу видел вообще всё это, поскорее бы рабочий день подошёл к концу, то, наверное, это даже как‑то грустно.
Почему вам грустно? Чувствуете в глубине души, что вас где-то обманули? Или, потому что вы - таки менеджер?
Не испытывать вообще никакого огонька, никакого желания сделать классно, красиво и по‑инженерному правильно, при этом не для кого‑то, а в первую очередь для себя
Если речь идет о наемном работнике, то "для себя" - это иллюзия, старательно наводимая на него менеджментом.
PS Кстати, вы заметили, что столь рекламируемый вами в статье армейский принцип "безобразно, зато единообразно" - он как-то плохо по жизни совместим с принципами профессиональной гордости и инженерной красоты, которые вы тут декларируете в ответе мне? Откуда у вас такое расхождение между декларируемой любви к красоте инженерных решений и грубому казарменному способу их, якобы, достижения, про которых вы написали статью?
PPS У С.В.Лукьяненко есть такая фантастический роман - "Геном". Главный герой там "человек-спец" - генетически модифицированный человек, который испытывает буквально физическое удовольствие именно от процесса своей работы (так уж его модифицировали). Так вот, по сюжету он получает там однажды доступ к сыворотке, которая временно блокирует этот эффект модификации - и у него на это время пропадает то волшебное ощущение, с которым он выполнял свою работу. То есть, получается, что тамошний главный герой - человек по своему ущербный (там в романе это ещё с нескольких старон раскрывается, но здесь рассказывать про это долго).
Может, и разработчики, получающие не просто удовольствие от своей работы, но и готовые ради этого удовольствия жертвовать в пользу посторонних им людей - нанимателей - заслуженными ими благами (или деньгами как универсальным эквивалентом любых благ) - они тоже такие же ущербные, а? Не задуматься ли?CodeShaman Автор
18.02.2025 13:27Я не знаю, почему вы так зацепились за фразу «у каждого проекта должен быть тот, кто заботится о нём душой». Можем перефразировать её как «хорошо, когда у проекта есть тот, кто заботится о нём душой». Теперь без этого слова «должен», но суть не меняется. Просто хорошо и приятно работать в проектах, где разработчики пишут их с душой, заботятся о качестве кодовой базы.
Качество кодовой базы — это то, что в первую очередь нужно самим разработчикам. Бизнесу и работодателю это просто не понять: они не профильные спецы в этом деле. И вы это делаете — работаете над качеством именно в рабочее время. Общаетесь с вашим работодателем, бизнес-заказчиком, и объясняете, что нужно провести такие технические работы, устранить такой-то техдолг, провести рефакторинг. Если работодатель категорически против и вообще не даёт на это времени, так как пилим бизнес-фичи и только бизнес-фичи, то вы уже пишете, как есть возможность. Но это уже повод задуматься: как долго вы хотите работать там, где техдолгом вообще не занимаются?
Просто поймите: из ваших сообщений складывается впечатление, что ваше предложение — просто писать по факту, чтобы бизнес-фича была готова, а техдолг и рефакторинг — для обманутых кровавым энтерпрайзом прослойки разработчиков, которых душу заставили продать вместе с кодом. А единственная цель и удовлетворение — срубить побольше бабла как можно раньше и уйти в закат, чтобы этот код больше не попадался вам на глаза. Тем, кто любит писать код — и не просто код, а хороший, качественный и поддерживаемый код, менеджеры и работодатели просто вдолбили это в мозги своими манипуляциями и внушением.
- Вам это, на самом деле, не нравится, как и мне, и не может нравиться! Просто я понял, как устроен этот мир, а вы ещё нет. Если по книге Лукьяненко, то если вы получаете удовольствие от работы по написанию кода, вы почти что ущербный.
Последнее предложение, грубо, конечно, но по вашему тексту получается фактически так.
Принцип «безобразно, но единообразно» как раз полностью согласуется с инженерной красотой. Если вы не можете по каким-то причинам добиться в коде единого, хорошего и лучшего подхода, то пусть он будет таким, каким он может быть в данный момент, но везде единообразным. И это вполне себе инженерная красота — единообразно написанный проект, который потом намного проще улучшить централизованным рефакторингом.
В общем, намечается бесконечный спор. В конечном итоге каждый выбирает, как ему работать. Но очень и очень не хотелось бы прийти на проект, который писали по принципу «фича сделана и славно, техдогом и рефакторингом мы тут не занимаемся, а уж о качестве кодовой базы тем более думать не собираемся». Вы или получаете удовольствие от процесса, или не получаете. А от этого дальше уже идёт расхождение взглядов на вопрос.
mvv-rus
18.02.2025 13:27Чтобы спор не был бесконечным, отвечу максимально кратко.
Качество кодовой базы — это то, что в первую очередь нужно самим разработчикам.
Уже писал выше, почему это не так. Да, низкое качество означает рост трудозатрат на разработку тех же самых функций. Но эти затраты труда разработчику оплачиваются (по крайней мере, должны), а потому интересы разработчика не пострадают. А ещё низкое качество ведет к росту требований к квалификации разработчика, его умению читать реальный код - и в этом тоже для квалифицированного разрабочика ничего плохого нет: его способности больше востребованы и потому за них дают больше денег.
Бизнесу и работодателю это просто не понять: они не профильные спецы в этом деле.
Бизнес, рано или поздно чувствует, что кодовая база плохая, по увеличению затрат на рзаработку и потому нанимает на менеджерскую по своей сути должность (ее обычно называюь техлид) профильного спеца, способного следить за качеством кода и устанавливать стандарты этого качества. А простые разработчики обязаны следовать этим самым стандартам - согласно трудовому договору. Так вот, ваша статья предназначена, по факту, для такого спеца. И не понравилось мне в статье то, что статья перевешивает обязанности техлида на рядовых разработчиков - и, скорее всего, без оплаты их труда за выполнение ими обязанностей техлида.
как долго вы хотите работать там, где техдолгом вообще не занимаются
А почему бы нет? Благо, умению читать чужой код самого разного качества (начная с "фортрановского") я за долгие годы научился. Так почему бы мне не использовать это умение на благо своего кошелька? Мне ведь за это будут не только деньги, но и почет, и слава незаменимого мастера. Что в этом плохого, а? Нет, специально код портить ради job security - это я считаю аморальным, но и напрягаться ради выполнения невысказанных интересов бизнеса, да ещё и без оплаты, нужным тоже не считаю. А считаю нужным писать так, как мне удобнее, но - в рамках требований работодателя.
Просто я понял, как устроен этот мир, а вы ещё нет.
Боюсь, что я просто понял это глубже - и не потому, что я такой умный, а чисто потому что видел много разного, начиная с середины 80-х, чисто из-за прошедшего времени.
Принцип «безобразно, но единообразно» как раз полностью согласуется с инженерной красотой.
Могу предположить по этим словам, что в армии вы не служили, на зарядку в "форме номер два" не бегали, в столовую строем не ходили, и к обеду по команде не приступали, траву в зеленый, а снег в белый цвет не красили, круглое не таскали, квадратное не катали, ПХД для вас - это просто три буквы и т.д. Потому что кто в армии служил - он, как говорят в народе, в цирке не смеется. То есть, вы так свободно предлагаете людям следовать армейским принципам, что сами с ними, скорее всего не сталкивались и не понимаете, что это на практике означает.
Удовольстве от написания программ (для меня, по крайне мере) - оно ведь, в основном, состоит в возможности творчества. Принцип же "безобразно, но единообразно" творчество убивает напрочь. Я понимаю, что для успеха дела, которое делает не один человек, соблюдать установленные стандарты необходимо, но это - вынужденная необходимость. Видеть в ее соблюдении какое-то там удовольствие - это мне странно.
Вы или получаете удовольствие от процесса, или не получаете. А от этого дальше уже идёт расхождение взглядов на вопрос.
Знаете, а я ведь тоже люблю писать код. Как я пишу для себя - это каждый, кому это вдруг стало интересным, может посмотреть (ссылки на GitHub есть в моих статьях). Но если писать код приходится не для себя, не для души, то я считаю нужным себя сдерживать - из классовой солидарности с теми, кто пришел просто работать работу ради денег.
CodeShaman Автор
18.02.2025 13:27В армии я не только служил, но и прошёл путь от рядового срочной службы до офицера. Но в контексте данной статьи это было бы, в целом, абсолютно не обязательно. Сам принцип, его понимание и его применение к разработке вообще не имеют к этому никакого отношения. Поэтому попытка в «не служил — не мужик» не прошла, извините. Служил и много.
Где вы увидели, что что-то перекладывается на кого-то? Я тоже не понимаю.
Простите, но у меня складывается впечатление, что вы сами создаёте тезисы и сами их опровергаете.
Да и в целом получается какая-то абсолютная нестыковка. Если разработчик обязан следовать стандартам, которые устанавливает техлид, который, по вашим рассуждениям, должен делать то, что в статье, то как он будет соблюдать эти требования и стандарты, установленные ему, не понимая того, о чём эта статья? Он будет городить новые реализации в каждом пулреквесте, делать всё по-своему, и каждый раз техлид должен это вычитывать снова и снова, указывая лично, как нужно? А разработчик не будет учиться следовать этим стандартам и продолжит писать, как ему хочется, уже на следующей таске? Очень странная картина получается.
Да и вообще, если писать код — это творчество, только если «дикое поле и ворочу, что хочу» — само по себе странно. Тогда все эти линтеры, кодстайлы, сотни книг о том, как стоит писать код — все убивают творчество, получается? Творчество и отсутствие рамок и ориентиров вообще не связаны между собой. Творчество — это процесс создания чего-то нового само по себе. Вы созидаете, творите, сооздаете что-то новое и можете увидеть результат своего труда. Это и есть творчество, от слова творить. В живописи, в архитектуре, да, в любой творческой профессии есть свои правила, гайдлайны и ограничения. Инженер-конструктор, который разрабатывает новую модель самолета - творец не меньше разработчика ПО. Но у него есть жесткие регламенты и рамки, как ему все делать, документировать и проектировать. За границы стандартов можно выходить, раздвигать их, но когда это делают хорошие творцы и полностью осознанно, понимая, для чего и почему они отказываются соблюдать их в интересах своего нового творения. А выход за любые границы на постоянной основе — просто потому, что я вот такая снежинка, и если мне хоть чуть-чуть укажут, что есть какие-то стандарты, я расстроюсь и перестану чувствовать творчество — немного абсурдно.
А по поводу того, что высокое качество кодовой базы не нужно разработчикам — опять противоречие. Низкое качество кодовой базы ведёт к росту трудозатрат, как вы сами пишете. То есть, чтобы сделать то, что можно было бы сделать просто и быстро, вам приходится делать это сложно, дорого и больно. И с каждым годом такого подхода становится всё больше и больше. Да, вам за это платят, но какой интерес в том, чтобы внедрять фичи всё сложнее и сложнее, какой интерес в том, чтобы усложнять себе самому работу? Нет, может, кому-то нравится, что спустя пять лет такого развития проекта внедрение банальной фичи занимает не пару дней, а пару недель, с постоянным головняком и кучей лишней ментальной работы над кодом, который начинает рассыпаться от каждого чиха, и приходится всё это латать, держать в голове кучу ненужного контекста и так далее. Качественная кодовая база нужна разработчикам, чтобы их работа была спокойной, интересной и приятной. Бизнесу качество кодовой базы становится интересно только тогда, когда всё начинает сыпаться от багов, и фичи внедряются месяцами.
Vlad_68
18.02.2025 13:27Очень хорошая статья. Без воды, сжато, то что нужно для понимания "как" надо писать код, что бы он был для людей, а не для отдельных "гениев".
Femistoklov
Такое себе. Если у вас цель - только поддержка проекта, то ок. А если есть ещё и цель развивать вашу команду - то надо её приучать к хорошему и правильному.
CodeShaman Автор
На самом деле, я не вижу тут противоречий. В первую очередь правильным является единство подходов в проекте, чему и посвящена статья. В ней прямо говорится о том, что нужно внедрять правильные подходы, но делать это следует продуманно.
К сожалению, у разработчиков слишком часто совершенно разное мнение о том, что является правильным, а что — нет. На эту тему я привожу в пример лекцию Мартина Фаулера "Software Design in the 21st Century". В ней он довольно красочно описывает, как дядя Боб, будучи рецензентом, высказывал ему: «Так писать код нельзя!»
О чем это говорит? Сегодня вы — техлид, которому передали этот проект. Вам кажется, что что-то сделано неправильно, и вы пишет новые фичи на свой лад. Завтра вы уволились, или проект передали другой команде, где новый техлид считает ваши решения неудачными и снова пишет новые фичи по своему. В итоге каждый учит и развивает свою команду, не выходя за рамки собственных представлений о правильности, а проект тем временем обрастает тремя разными подходами, между которыми команде приходится метаться туда-сюда.
Чтобы этого не происходило, и написана статья. Лучшее — враг хорошего. Иногда важно думать о гармоничном развитии проекта и его консистентности в более широком смысле. Уча сходу свою команду «правильному» подходу в таком проекте без обязательного рефакторинга старого кода на этот подход, вы фактически закладываете мысль, что параллельное сосуществование разных реализаций одних и тех же вещей в коде — это норма.
В общем, мне кажется, что суть статьи никоим образом не отрицает необходимость обучения команды хорошим практикам.