Код читают чаще, чем пишут

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

Позвольте мне выразить эту мысль более кратко:

мейнтейнер > автор

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

Код чаще используют, чем читают

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

пользователь > мейнтейнер > автор

Нас больше не волнуют роли разработчиков, так что можно сократить:

пользователь > разработчик

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

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

Код чаще запускают, чем читают

Когда я говорю «запускают», то имею в виду не только исполнение самой программы; я подразумеваю её эксплуатацию в продакшене, что включает в себя развёртывание, обновление, наблюдаемость, аудит, мониторинг, исправления, вывод из эксплуатации. Как сказал Дэн Маккинли:

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

Мы можем встроить эту мысль в нашу небольшую модель:

пользователь > ops > разработчик

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

Кроме того, есть ещё и бизнес

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

бизнес > пользователь > ops > разработчик

Самый очевидный пример — это бюджет: у нас нет бесконечных ресурсов для удовлетворения всех потребностей пользователя, так что нужно взвешивать затраты и выгоду. Существует маркетинг, существуют дедлайны. Есть стейкхолдеры и инвесторы. В деле участвуют личные интересы и политика. Решения, имеющие смысл для нашего ПО, нашей команды или наших пользователей, рассматриваются отдельно, но не когда мы рассматриваем организацию в целом. Иногда нам нужно работать над тем, что генерирует прибыль, а не приносит радость пользователю. Позже я к этому вернусь.

Оттенки запахов

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

Код, который невозможно поддерживать

автор > мейнтейнер

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

ПО, которое невозможно использовать

разработчик > пользователь

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

На моей машине работает

разработчик > ops

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

Мы всё сделали правильно

разработчик > бизнес

Код как самоцель. ПО, разработанное претенциозными художниками, музыкантами с «Титаника» и Lisp-хакерами.

Разработка ради красивой строчки в резюме

разработчик > *

ПО, создаваемое, когда на кону ничего не стоит и разработчики могут делать всё, что захотят.

Мнимое ПО

бизнес > пользователь > (-ops) > разработчик

ПО, которое создаётся, но редко (или никогда) не добирается до продакшена. Я называю его мнимым ПО. Черити Мейджорс называет это жизнью в иллюзиях.

biz > (-user) > ops > dev

Ещё один вид мнимого ПО — такой, у которого нет пользователей. (Зато есть масштабирование). Это ПО, которое не решает проблему или решает не ту проблему, возможно, ничью проблему. Разработчики берут громкую технологию и начинают забивать ею гвозди, пока не получат нечто, смутно напоминающее сценарий использования.

Поздний капитализм

(-biz) > пользователь > ops > разработчик

ПО, финансируемое венчурным капиталом, не имеющее бизнес-модели, или бизнес-модель которой сформулирована так: растём, пока не станем монополией, затем будем эксплуатировать пользователей.

Слон

Если вы всё ещё в гневе не закрыли вкладку браузера, то позвольте мне закончить, вернувшись к этой схеме:

бизнес > пользователь

У неё могут возникнуть проблемы, которые сложно решить.

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

Сейчас выпускают много ПО, которое не заботится о пользователях, или которое манипулирует ими, или превращает их в продукт. И это относится не только к соцсетям: пользователь не может забронировать номер в отеле, заказать еду или нажать на кнопку «Пуск» в Windows, не подвергшись нападению всплывающих окон; я даже не могу поискать ничего в Google, не получив в ответ кучу мусора.

Возник конфликт между тем, что мы считали хорошей работой, и тем, что считает прибыльным существенная часть индустрии; мне кажется, этим объясняется всё больший дискомфорт у многих профессионалов в разработке ПО. И хотя мы не можем вернуться назад и просто закрыть глаза, игнорируя экономические реалии нашей отрасли, возможно, нам стоит сильнее отстаивать этику защиты пользователей от вреда. Мы можем признавать, что пользователь не всегда превыше бизнеса, но и бизнес при этом не должен всегда быть главным:

пользователь > ops > разработчик
бизнес > ops > разработчик
бизнес ≹ пользователь