Комментарии 10
Очень плохая идея начать писать новые фичи, используя подходы, чуждые проекту, который вы поддерживаете.
Такое себе. Если у вас цель - только поддержка проекта, то ок. А если есть ещё и цель развивать вашу команду - то надо её приучать к хорошему и правильному.
На самом деле, я не вижу тут противоречий. В первую очередь правильным является единство подходов в проекте, чему и посвящена статья. В ней прямо говорится о том, что нужно внедрять правильные подходы, но делать это следует продуманно.
К сожалению, у разработчиков слишком часто совершенно разное мнение о том, что является правильным, а что — нет. На эту тему я привожу в пример лекцию Мартина Фаулера "Software Design in the 21st Century". В ней он довольно красочно описывает, как дядя Боб, будучи рецензентом, высказывал ему: «Так писать код нельзя!»
О чем это говорит? Сегодня вы — техлид, которому передали этот проект. Вам кажется, что что-то сделано неправильно, и вы пишет новые фичи на свой лад. Завтра вы уволились, или проект передали другой команде, где новый техлид считает ваши решения неудачными и снова пишет новые фичи по своему. В итоге каждый учит и развивает свою команду, не выходя за рамки собственных представлений о правильности, а проект тем временем обрастает тремя разными подходами, между которыми команде приходится метаться туда-сюда.
Чтобы этого не происходило, и написана статья. Лучшее — враг хорошего. Иногда важно думать о гармоничном развитии проекта и его консистентности в более широком смысле. Уча сходу свою команду «правильному» подходу в таком проекте без обязательного рефакторинга старого кода на этот подход, вы фактически закладываете мысль, что параллельное сосуществование разных реализаций одних и тех же вещей в коде — это норма.
В общем, мне кажется, что суть статьи никоим образом не отрицает необходимость обучения команды хорошим практикам.
Заключение: у каждого проекта должен быть тот, кто заботится о нём душой
Я ещё со времен своей комсомольской юности усвоил, что когда мне говорят "должен", я чисто на автомате задумываюсь: "кому должен" и "почему должен". И здесь, как раз - именно тот случай, чтобы задуматься.
Если руководство считает, то для бизнеса фирмы это нужно - пусть назначает ответственного и платит ему за это деньги, как за часть его трудовых обязанностей.
А так, поскольку результат труда разработчика - эта самая кодовая база - от разработчика отчуждается, то есть принадлежит фирме, то объективно разработчик в качестве этой самой кодовой базы не заинтересован. Разработчику все-таки платят фактически за потраченное им время, а не за достигнутый результат.
То есть, рядовой разработчик продавать фирме вместе со своей рабочей силой ещё и свою душу не подписывался.
PS Применимость самого по себе армейского принципа к процессу разработки - как это нарисовано в общеизвестном меме "Программирывай!" - у меня тоже вызывает сомнение: больно уж разное качество типового человеческого материала с которым имеет дело руководитель разработчиков и сержант или младший офицер в армии. Но об этом - как-нибудь потом.
Тут уже пошла какая‑то философия о том, как мы подходим к тому, что делаем, и что значит для человека быть профессионалом своего дела. Кто‑то делает любое дело на совесть, как раз "вкладывая в него душу", так как хочет быть профессионалом и гордится тем, что создаёт. И даже если это просто красивое инженерное решение где‑то в глубине бэкенда, о котором ни кто, кроме него не узнает, такой специалист всё равно получит внутреннее удовлетворение от того, что смог создать что‑то настолько элегантное и нетривиальное, что ему самому будет просто хорошо – как раз на самой этой душе.
Исповедовать подход «задачу сделал и плевать, как сделал, для бизнеса всё‑равно - не проверят, а я, может, через полгода ещё раз работу сменю» для кого‑то может быть и путь, но вряд ли это то, что можно современным языком назвать «путь джедая». Почему сразу о сменить работу через пол года речь? Просто потому, что если разработчик планирует работать на проекте долго, 5-10 лет или даже больше, то в первую очередь делать все качественно и вкладывать душу в его же интересах. Ему этот код и дорабатывать и поддерживать спустя годы. Да и как расти над собой, в том числе как инженер или разработчик, если конечная цель только одна – «плевать, как сделал, задачу формально закрыл и забыл».
Наверное, тут фундаментальная разница ещё в том, как человек относится к своей работе как таковой. Если разработчик работает от звонка до звонка и в гробу видел вообще всё это, поскорее бы рабочий день подошёл к концу, то, наверное, это даже как‑то грустно. Не испытывать вообще никакого огонька, никакого желания сделать классно, красиво и по‑инженерному правильно, при этом не для кого‑то, а в первую очередь для себя – это или терминальная стадия выгорания, или, может, изначально не та выбранная стезя в жизни.
На появившийся постскриптум могу только дать комментарий: вся статья как раз о том, почему этот принцип можно применять и каким образом. Соответственно, даже и добавить нечего.
Кто‑то делает любое дело на совесть, как раз "вкладывая в него душу", так как хочет быть профессионалом и гордится тем, что создаёт.
Как я уже написал, душа разработчика в предмет трудового договора не входит: хотя бы потому, что договоры, касающиеся души, подписываются своей кровью, а в современном делопроизводстве такая практика не принята.
Далее, профессионал - это всего лишь тот, кто получает за свою работу деньги, не более. Гордиться же тем, что у тебя по условиям договора всё равно заберут - это IMHO просто глупость.
Но менеджмент такое отношение наемных работников любит, да. Потому что от того, что можно часть оплаты работнику заменить его моральным стимулированием, менеджменту хорошо: бюджеты не превышаются, задачи выполняются, а то ещё и бонусы капают.
Просто потому, что если разработчик планирует работать на проекте долго, 5-10 лет или даже больше, то в первую очередь делать все качественно и вкладывать душу в его же интересах. Ему этот код и дорабатывать и поддерживать спустя годы.
Нет - не в его интересах. Потому что платят разработчику, так или иначе, за потраченное время. И если разработчику из-за качества кодовой базы пришлось ковыряться дольше, то это время ему будет оплачено, и он в деньгах не теряет ничего.
Да и как расти над собой...
А оно это точно надо, когда по найму работаеешь? Может, лучше расти над собой по модели F.I.R.E. - поднять по молодости побольше бабла, чтобы было на что жить, не работая на дядю, а уж потом - "расти над собой", "получать внутреннее удовлетворение от того, что смог создать что‑то настолько элегантное и нетривиальное, что ему самому будет просто хорошо" и заниматься прочими подобными вещами, а?
Наверное, тут фундаментальная разница ещё в том, как человек относится к своей работе как таковой.
Да, я описываю ситуацию с материалистической с точки зрения, с точки зрения "человека экономического". И считаю, что для нынешнего мира бездушного чистогана это наиболее адекватный подход.
Если разработчик работает от звонка до звонка и в гробу видел вообще всё это, поскорее бы рабочий день подошёл к концу, то, наверное, это даже как‑то грустно.
Почему вам грустно? Чувствуете в глубине души, что вас где-то обманули? Или, потому что вы - таки менеджер?
Не испытывать вообще никакого огонька, никакого желания сделать классно, красиво и по‑инженерному правильно, при этом не для кого‑то, а в первую очередь для себя
Если речь идет о наемном работнике, то "для себя" - это иллюзия, старательно наводимая на него менеджментом.
PS Кстати, вы заметили, что столь рекламируемый вами в статье армейский принцип "безобразно, зато единообразно" - он как-то плохо по жизни совместим с принципами профессиональной гордости и инженерной красоты, которые вы тут декларируете в ответе мне? Откуда у вас такое расхождение между декларируемой любви к красоте инженерных решений и грубому казарменному способу их, якобы, достижения, про которых вы написали статью?
PPS У С.В.Лукьяненко есть такая фантастический роман - "Геном". Главный герой там "человек-спец" - генетически модифицированный человек, который испытывает буквально физическое удовольствие именно от процесса своей работы (так уж его модифицировали). Так вот, по сюжету он получает там однажды доступ к сыворотке, которая временно блокирует этот эффект модификации - и у него на это время пропадает то волшебное ощущение, с которым он выполнял свою работу. То есть, получается, что тамошний главный герой - человек по своему ущербный (там в романе это ещё с нескольких старон раскрывается, но здесь рассказывать про это долго).
Может, и разработчики, получающие не просто удовольствие от своей работы, но и готовые ради этого удовольствия жертвовать в пользу посторонних им людей - нанимателей - заслуженными ими благами (или деньгами как универсальным эквивалентом любых благ) - они тоже такие же ущербные, а? Не задуматься ли?
Я не знаю, почему вы так зацепились за фразу «у каждого проекта должен быть тот, кто заботится о нём душой». Можем перефразировать её как «хорошо, когда у проекта есть тот, кто заботится о нём душой». Теперь без этого слова «должен», но суть не меняется. Просто хорошо и приятно работать в проектах, где разработчики пишут их с душой, заботятся о качестве кодовой базы.
Качество кодовой базы — это то, что в первую очередь нужно самим разработчикам. Бизнесу и работодателю это просто не понять: они не профильные спецы в этом деле. И вы это делаете — работаете над качеством именно в рабочее время. Общаетесь с вашим работодателем, бизнес-заказчиком, и объясняете, что нужно провести такие технические работы, устранить такой-то техдолг, провести рефакторинг. Если работодатель категорически против и вообще не даёт на это времени, так как пилим бизнес-фичи и только бизнес-фичи, то вы уже пишете, как есть возможность. Но это уже повод задуматься: как долго вы хотите работать там, где техдолгом вообще не занимаются?
Просто поймите: из ваших сообщений складывается впечатление, что ваше предложение — просто писать по факту, чтобы бизнес-фича была готова, а техдолг и рефакторинг — для обманутых кровавым энтерпрайзом прослойки разработчиков, которых душу заставили продать вместе с кодом. А единственная цель и удовлетворение — срубить побольше бабла как можно раньше и уйти в закат, чтобы этот код больше не попадался вам на глаза. Тем, кто любит писать код — и не просто код, а хороший, качественный и поддерживаемый код, менеджеры и работодатели просто вдолбили это в мозги своими манипуляциями и внушением.
- Вам это, на самом деле, не нравится, как и мне, и не может нравиться! Просто я понял, как устроен этот мир, а вы ещё нет. Если по книге Лукьяненко, то если вы получаете удовольствие от работы по написанию кода, вы почти что ущербный.
Последнее предложение, грубо, конечно, но по вашему тексту получается фактически так.
Принцип «безобразно, но единообразно» как раз полностью согласуется с инженерной красотой. Если вы не можете по каким-то причинам добиться в коде единого, хорошего и лучшего подхода, то пусть он будет таким, каким он может быть в данный момент, но везде единообразным. И это вполне себе инженерная красота — единообразно написанный проект, который потом намного проще улучшить централизованным рефакторингом.
В общем, намечается бесконечный спор. В конечном итоге каждый выбирает, как ему работать. Но очень и очень не хотелось бы прийти на проект, который писали по принципу «фича сделана и славно, техдогом и рефакторингом мы тут не занимаемся, а уж о качестве кодовой базы тем более думать не собираемся». Вы или получаете удовольствие от процесса, или не получаете. А от этого дальше уже идёт расхождение взглядов на вопрос.
Чтобы спор не был бесконечным, отвечу максимально кратко.
Качество кодовой базы — это то, что в первую очередь нужно самим разработчикам.
Уже писал выше, почему это не так. Да, низкое качество означает рост трудозатрат на разработку тех же самых функций. Но эти затраты труда разработчику оплачиваются (по крайней мере, должны), а потому интересы разработчика не пострадают. А ещё низкое качество ведет к росту требований к квалификации разработчика, его умению читать реальный код - и в этом тоже для квалифицированного разрабочика ничего плохого нет: его способности больше востребованы и потому за них дают больше денег.
Бизнесу и работодателю это просто не понять: они не профильные спецы в этом деле.
Бизнес, рано или поздно чувствует, что кодовая база плохая, по увеличению затрат на рзаработку и потому нанимает на менеджерскую по своей сути должность (ее обычно называюь техлид) профильного спеца, способного следить за качеством кода и устанавливать стандарты этого качества. А простые разработчики обязаны следовать этим самым стандартам - согласно трудовому договору. Так вот, ваша статья предназначена, по факту, для такого спеца. И не понравилось мне в статье то, что статья перевешивает обязанности техлида на рядовых разработчиков - и, скорее всего, без оплаты их труда за выполнение ими обязанностей техлида.
как долго вы хотите работать там, где техдолгом вообще не занимаются
А почему бы нет? Благо, умению читать чужой код самого разного качества (начная с "фортрановского") я за долгие годы научился. Так почему бы мне не использовать это умение на благо своего кошелька? Мне ведь за это будут не только деньги, но и почет, и слава незаменимого мастера. Что в этом плохого, а? Нет, специально код портить ради job security - это я считаю аморальным, но и напрягаться ради выполнения невысказанных интересов бизнеса, да ещё и без оплаты, нужным тоже не считаю. А считаю нужным писать так, как мне удобнее, но - в рамках требований работодателя.
Просто я понял, как устроен этот мир, а вы ещё нет.
Боюсь, что я просто понял это глубже - и не потому, что я такой умный, а чисто потому что видел много разного, начиная с середины 80-х, чисто из-за прошедшего времени.
Принцип «безобразно, но единообразно» как раз полностью согласуется с инженерной красотой.
Могу предположить по этим словам, что в армии вы не служили, на зарядку в "форме номер два" не бегали, в столовую строем не ходили, и к обеду по команде не приступали, траву в зеленый, а снег в белый цвет не красили, круглое не таскали, квадратное не катали, ПХД для вас - это просто три буквы и т.д. Потому что кто в армии служил - он, как говорят в народе, в цирке не смеется. То есть, вы так свободно предлагаете людям следовать армейским принципам, что сами с ними, скорее всего не сталкивались и не понимаете, что это на практике означает.
Удовольстве от написания программ (для меня, по крайне мере) - оно ведь, в основном, состоит в возможности творчества. Принцип же "безобразно, но единообразно" творчество убивает напрочь. Я понимаю, что для успеха дела, которое делает не один человек, соблюдать установленные стандарты необходимо, но это - вынужденная необходимость. Видеть в ее соблюдении какое-то там удовольствие - это мне странно.
Вы или получаете удовольствие от процесса, или не получаете. А от этого дальше уже идёт расхождение взглядов на вопрос.
Знаете, а я ведь тоже люблю писать код. Как я пишу для себя - это каждый, кому это вдруг стало интересным, может посмотреть (ссылки на GitHub есть в моих статьях). Но если писать код приходится не для себя, не для души, то я считаю нужным себя сдерживать - из классовой солидарности с теми, кто пришел просто работать работу ради денег.
В армии я не только служил, но и прошёл путь от рядового срочной службы до офицера. Но в контексте данной статьи это было бы, в целом, абсолютно не обязательно. Сам принцип, его понимание и его применение к разработке вообще не имеют к этому никакого отношения. Поэтому попытка в «не служил — не мужик» не прошла, извините. Служил и много.
Где вы увидели, что что-то перекладывается на кого-то? Я тоже не понимаю.
Простите, но у меня складывается впечатление, что вы сами создаёте тезисы и сами их опровергаете.
Да и в целом получается какая-то абсолютная нестыковка. Если разработчик обязан следовать стандартам, которые устанавливает техлид, который, по вашим рассуждениям, должен делать то, что в статье, то как он будет соблюдать эти требования и стандарты, установленные ему, не понимая того, о чём эта статья? Он будет городить новые реализации в каждом пулреквесте, делать всё по-своему, и каждый раз техлид должен это вычитывать снова и снова, указывая лично, как нужно? А разработчик не будет учиться следовать этим стандартам и продолжит писать, как ему хочется, уже на следующей таске? Очень странная картина получается.
Да и вообще, если писать код — это творчество, только если «дикое поле и ворочу, что хочу» — само по себе странно. Тогда все эти линтеры, кодстайлы, сотни книг о том, как стоит писать код — все убивают творчество, получается? Творчество и отсутствие рамок и ориентиров вообще не связаны между собой. Творчество — это процесс создания чего-то нового само по себе. Вы созидаете, творите, сооздаете что-то новое и можете увидеть результат своего труда. Это и есть творчество, от слова творить. В живописи, в архитектуре, да, в любой творческой профессии есть свои правила, гайдлайны и ограничения. Инженер-конструктор, который разрабатывает новую модель самолета - творец не меньше разработчика ПО. Но у него есть жесткие регламенты и рамки, как ему все делать, документировать и проектировать. За границы стандартов можно выходить, раздвигать их, но когда это делают хорошие творцы и полностью осознанно, понимая, для чего и почему они отказываются соблюдать их в интересах своего нового творения. А выход за любые границы на постоянной основе — просто потому, что я вот такая снежинка, и если мне хоть чуть-чуть укажут, что есть какие-то стандарты, я расстроюсь и перестану чувствовать творчество — немного абсурдно.
А по поводу того, что высокое качество кодовой базы не нужно разработчикам — опять противоречие. Низкое качество кодовой базы ведёт к росту трудозатрат, как вы сами пишете. То есть, чтобы сделать то, что можно было бы сделать просто и быстро, вам приходится делать это сложно, дорого и больно. И с каждым годом такого подхода становится всё больше и больше. Да, вам за это платят, но какой интерес в том, чтобы внедрять фичи всё сложнее и сложнее, какой интерес в том, чтобы усложнять себе самому работу? Нет, может, кому-то нравится, что спустя пять лет такого развития проекта внедрение банальной фичи занимает не пару дней, а пару недель, с постоянным головняком и кучей лишней ментальной работы над кодом, который начинает рассыпаться от каждого чиха, и приходится всё это латать, держать в голове кучу ненужного контекста и так далее. Качественная кодовая база нужна разработчикам, чтобы их работа была спокойной, интересной и приятной. Бизнесу качество кодовой базы становится интересно только тогда, когда всё начинает сыпаться от багов, и фичи внедряются месяцами.
Здесь был дубль.
Очень хорошая статья. Без воды, сжато, то что нужно для понимания "как" надо писать код, что бы он был для людей, а не для отдельных "гениев".
Хоть и безобразно, но единообразно