Обратная сторона методологий и «лучших практик» разработки

С появлением множества технологий и фреймворков, которые упрощают разработчику жизнь, может сложиться впечатление, что сегодня писать программы стало проще, чем вчера. В самом деле, зачем каждый раз использовать велосипед? Используй готовые библиотеки, живи — не тужи. Но радость была бы неполной, если бы вместе с технологиями для упрощения жизни разработчика не появились и новые методологии разработки ПО. Но стало ли легче?

В начале 2000-х привычную некогда парадигму Waterfall стали даже клеймить позором. Если у человека на проекте не было новомодного Agile, то ему, краснея, приходилось выдумывать отговорки в стиле «Мы сейчас как раз на него переходим». В это же время у всех на языках завертелись неслыханные доселе словечки вроде extreme programming, scrum-master, stand-up meeting, backlog, sprint и так далее. В программирование вдохнули новую жизнь! Появились доски из пробки, в которые можно было с удовольствием вдавливать кнопки с разноцветными бумажками и стоять с умным видом, рассуждая о великом. И наконец появился долгожданный блэк-джек в виде Scrum poker. Всё это удобрялось важными графиками, глядя на которые нельзя было не чувствовать себя титаном прогресса.

Тогда наш коуч идёт к вам

Стали появляться книги по разработке ПО, в которых упор делался уже не столько на самом языке, сколько на том, с какой ноги следует встать утром, чтобы вечером вышел удачный коммит. Одна за другой начали выходить статьи о лучших практиках (aka best practices), усвоив которые, разработчик смог бы писать код покрасивше. А где статьи и книги, там и коучи (гадкое словечко), которые с удовольствием обучат вашу команду тому, чего ещё не существовало несколько лет назад и без чего вы всё это время прекрасно жили и работали.

Пропаганда методологий разработки сработала настолько удачно, что зараженные вирусом программисты сами же стали разносить эту заразу по всему миру. Новые проекты все как один начинались на Agile; в резюме стали появляться гордые строчки с упоминанием Scrum, RUP и XP, а на просьбу рассказать о своём предыдущем проекте одурманенный разработчик с гордостью рассказывал про опыт работы с Agile или Kanban, как будто это имеет какое-либо отношение к написанию кода.

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

Пыль в глаза

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

Теперь обо всей этой Agile-XP-Kanban-Scrum-RUP-Waterfall феерии заставили думать ещё и разработчика, задача которого — вообще-то не по митингам шастать или пускать каждый раз скупую слезу при виде burndown chart, а работать.

Хитрое «ноухау» — рисовать график выполненных задач не вверх, а вниз, прим этом называя его пафосным «Burndown chart». Но один вопрос остается открытым — зачем разработчикам график с нисходящей линией прогресса, которая вызывает негативные ассоциации?

Нужны ли все эти графики заказчику или разработчику? Методом дробления процесса разработки ПО на мельчайшие частицы мы придём к атому — работающий код. Это единственное, что должно волновать разработчика и заказчика. Всё остальное — суета сует, тщета и ловля ветра.

RUP (Rational Unified Process) — чем сложнее для понимания, тем счастливее менеджеры и тем больше мусора в голове у разработчика.

Best practices (aka лучшие практики)

На этой теме сегодня кормятся многие IT-евангелисты (с намёком на религиозный уклон) — пишут книги, проводят семинары, поднимают капусту. Всегда ли нужно использовать эти лучшие практики?

Есть такие люди, которые верят во всё написанное. Например, в то, что TDD (Test-driven development) — это святое добро, или что каждый сайт должен обязательно проходить валидацию W3C. Если ты на глазах такого человека начнешь писать код, не написав перед этим тест, он на тебя посмотрит так, как будто ты не помолился перед едой. Забыл название какого-нибудь паттерна или фамилию автора известной книги по ООП? Гореть тебе в аду, антихрист. В пользу того, что некоторые популярные методологии больше смахивают на религии, сам за себя говорит Agile, в котором есть такие понятия как церемонии, артефакты, графики сжигания и духовный лидер (aka Scrum Master).

Один из многочисленных примеров умопомешательства на «лучших практиках» — это вопрос об идеальной длине метода:

In «Clean Code: A Handbook of Agile Software Craftsmanship», Robert Martin says:

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should not be 100 lines long. Functions should hardly ever be 20 lines long.

and he gives an example from Java code he sees from Kent Beck:

Every function in his program was just two, or three, or four lines long. Each was transparently obvious. Each told a story. And each led you to the next in a compelling order. That’s how short your functions should be!

This sounds great, but on the other hand, in «Code Complete», Steve McConnell says something very different:

The routine should be allowed to grow organically up to 100-200 lines, decades of evidence say that routines of such length no more error prone than shorter routines.

And he gives a reference to a study that says routines 65 lines or long are cheaper to develop.

So while there are diverging opinions about the matter, is there a functional best-practice towards determining the ideal length of a method for you?

Слабые места методологий

У всех этих методик и практик есть одна общая беда — они написаны теоретиками. Людьми, которые пытаются предугадать все риски. Возьмем, к примеру, тесты. Ладно ещё, когда они пишутся после или параллельно с кодом, но писать тест ещё до того, как появился функционал — это ли не излишняя перестраховка? Всё равно что пристегнуться ремнем безопасности ещё до того, как сел в автомобиль.

Другая уязвимость этих методик заключается в том, что они пытаются объять необъятное. Почему-то считается, что если на заводах Toyota успешно применяется Kanban или Lean, то их стоит использовать и в разработке ПО. При этом многие забывают, что между производством стандартного автомобиля, где на учёте каждый болт, и программой, которая почти всегда уникальна и неповторима, даже если это шаблонный интернет-магазин, — огромная разница. Вот если бы на разработку ПО переносили методологии производства custom-made автомобилей (а ещё лучше — мотоциклов), можно было бы о чем-то говорить.

Третья проблема — перфекционизм, который на этих «лучших практиках» растёт, как на дрожжах. Если на проекте не хватает чего-нибудь из XP или нет 100% покрытия тестами, у некоторых ребят начинают трястись поджилки. Будь сейчас рядом Цукерберг, он бы явно негодовал со своим «Done is better than perfect». Ведь кому нужно всё это «вылизывание» и бесконеный рефакторинг там, где это идет в убыток компании? Разве что разработчику, фанатично преданному «лучшим практикам».

Спор приверженца и отступника (реальный лог чата одной команды)

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

Приверженец: Если посмотреть вакансии, то в 99% случаев на проектах используют Agile.

Отступник: Да пусть используют что угодно. Ты либо делаешь проект, либо споришь как его делать. Будем честны — Agile немного усложняет разработку.
Приверженец: Спорить, как его делать — это неотъемлемая часть процесса делания проекта.

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

Приверженец: Если ты забьешь на архитектуру, тебе потом своё же болото придется разгребать, почему тогда сразу не делать нормально?
Отступник: Зачем тратить 1 год на то, в чем ты не уверен?

Приверженец: Мое дело — в первую очередь делать свою работу качественно, а не думать об opportunities и сроках.
Отступник: Ты сильно ошибаешься. Твоя главная задача — написать код, который будет работать и приносить деньги.
Приверженец: Это и так понятно.
Отступник: А будешь ты использовать при этом #крутойподход или нет — всем абсолютно плевать.

Есть ли выгода от методологий и лучших практик

Много споров идет о том, выгоднее ли Agile, чем Waterfall, можно ли сэкономить, используя парное программирование, окупится ли в долгосрочной перспективе рефакторинг или нет. И ни у кого нет ответа, так как здесь слишком много переменных, начиная от того, что значит «выгодно» и заканчивая тем, полностью ли соответствует разработка букве методологии.

Самое время вспомнить старую школьную задачку: Что тяжелее — килограмм пуха или килограмм свинца?

Вопрос о методологиях и «лучших практиках» как раз смахивает на эту задачку. Если у вас есть 7 разработчиков, которым вы платите зарплату, то в год вы потратите X долларов. Если вы используете Agile, то за год вы потратите те же X долларов. Waterfall? — Аналогично. Ваша команда будет с утра до ночи рефакторить и регулярно деливерить, применяя парное программирование, pomodoro и дебаггинг резиновой утки? Вы всё равно потратите X долларов. Да, может быть, они смогут написать программу, которую удобнее поддерживать. Но что, если вам не нужно настолько хорошее качество кода, а достаточно уровня «тяп-ляп — и в продакшен»? Или, допустим, команда закончит проект быстрее чем за год — но ведь скорость тоже далеко не всегда значит качество или соответствие требованиям заказчика.

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

С точки же зрения офисного трудяги всё куда проще: ему платят за часы в офисе. Поэтому ему абсолютно фиолетово, какой дури (18+) обкурились заказчик с менеджером и какую методологию решили внедрить. Лишь бы его поменьше трогали и позволили писать код. Грамотные менеджеры понимают это и становятся между заказчиком и разработчиком, принимая удар на себя. Ведь в конечном счете всё, что требуется от программиста — это programming, motherfucker.

Поэтому не важно, используете вы какую методологию, дебажите ли с помидором или с уткой и сколько раз в неделю у вас парное программирование. «Code wins arguments» — и этим всё сказано.

Что делать?

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

One Hacker Way — Erik Meijer from Reaktor on Vimeo.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU