[Перевод] Код чаще запускают, чем читают
Код читают чаще, чем пишут
Эта фраза, ставшая общеизвестным знанием программистов — напоминание о том, что человек, впервые пишущий фрагмент кода, не должен покупать своё удобство ценой неудобства людей, которые должны будут читать и изменять этот код в будущем. В более общем смысле эта фраза означает, что обычно стоит обеспечивать поддерживаемость кода, сохраняя его простоту, создавая тесты и документацию и так далее. Здесь вопрос касается точки зрения на цикл разработки ПО.
Позвольте мне выразить эту мысль более кратко:
мейнтейнер > автор
Я считаю, что такое мышление можно вывести за рамки написания кода и использовать как эмпирическое правило при выявлении проблем и принятии решений.
Код чаще используют, чем читают
Код — это средство для достижения цели. У ПО должно быть предназначение, оно обязано предоставлять услугу какому-то пользователю. Неважно, насколько хорошо написан и удобен в поддержке код, или насколько совершенна применённая в нём технология, если он не выполняет своего предназначения и неудобен для пользователя:
пользователь > мейнтейнер > автор
Нас больше не волнуют роли разработчиков, так что можно сократить:
пользователь > разработчик
Именно поэтому вместо того, чтобы угадывать или спрашивать, чего они хотят, лучше как можно раньше и чаще передавать программу пользователям, чтобы менять её в соответствии с их отзывами.
Это надёжная модель мышления — чтобы многого добиться, достаточно помнить о пользователях в процессе разработки. Примерно так я и осваивал свою работу и понимал её в течение первой половины своей карьеры.
Код чаще запускают, чем читают
Когда я говорю «запускают», то имею в виду не только исполнение самой программы; я подразумеваю её эксплуатацию в продакшене, что включает в себя развёртывание, обновление, наблюдаемость, аудит, мониторинг, исправления, вывод из эксплуатации. Как сказал Дэн Маккинли:
Практически всегда долговременные затраты на поддержание надёжной работы системы существенно превосходят все неудобства, с которыми вы сталкиваетесь при её создании.
Мы можем встроить эту мысль в нашу небольшую модель:
пользователь > ops > разработчик
Чтобы полностью осознать это, мне понадобилось время, потому что по моему опыту большая часть создаваемого ПО никогда не добирается до продакшена, по крайней мере, не в больших масштабах. Большинство ПО создаётся из допущений, которые никогда не проверялись. Когда запускаешь код в продакшене, принцип KISS обретает новое измерение. Теперь дело не в самом коде, а в снижении количества подвижных частей и в понимании их состояний отказа. В выпуске продукта и в обеспечении его работы, даже когда возникает отказ.
Кроме того, есть ещё и бизнес
Как я сказал, если вы будете помнить о пользователях в процессе разработки, до многого добьётесь. Этот принцип работает при допущении, что ПО полезно и хорошо работает, ПО ценно для пользователей и ценно для организации. Это удобная абстракция для разработчиков: мы выпускаем хорошее, работающее ПО, а уже бизнес превращает его в деньги. И этот принцип по большей мере работает, особенно для потребительского и корпоративного ПО. Однако в конечном итоге эта абстракция оказывается слишком сильным упрощением, и все мы можем выиграть от того, что встроим в свой рабочий процесс точку зрения бизнеса:
бизнес > пользователь > ops > разработчик
Самый очевидный пример — это бюджет: у нас нет бесконечных ресурсов для удовлетворения всех потребностей пользователя, так что нужно взвешивать затраты и выгоду. Существует маркетинг, существуют дедлайны. Есть стейкхолдеры и инвесторы. В деле участвуют личные интересы и политика. Решения, имеющие смысл для нашего ПО, нашей команды или наших пользователей, рассматриваются отдельно, но не когда мы рассматриваем организацию в целом. Иногда нам нужно работать над тем, что генерирует прибыль, а не приносит радость пользователю. Позже я к этому вернусь.
Оттенки запахов
Мы получили небольшую модель, выражающую относительную важность различных факторов в разработке ПО; возможно, она поможет нам увидеть общую картину и сосредоточиться на том, что важнее всего. Теперь я хочу рассмотреть некоторые из распространённых проблем в разработке ПО и показать, как они соотносятся с моделью.
Код, который невозможно поддерживать
автор > мейнтейнер
С этого мы начали. Хитрый и ленивый код превращается в спагетти и джунгли, в преждевременные оптимизации, в этот-модуль-можно-трогать-только-васе и так далее.
ПО, которое невозможно использовать
разработчик > пользователь
ПО, разработанное командами, которые не учатся у своих пользователей или ставят на первое место технологии. Оверинжиниринг, «модернизации», которые снижают удобство пользования, веб-приложения, ломающие функции браузеров, и так далее.
На моей машине работает
разработчик > ops
ПО, которое разрабатывалось без размышлений о его эксплуатации. Это чрезмерно переусложнённое ПО со множеством подвижных частей, крутые базы данных для малых нагрузок данных, экосистемы микросервисов, управляемые одной небольшой командой. ПО, преждевременно спроектированное с расчётом на масштабирование. ПО, спроектированное не теми, кого будят ночью, когда оно ломается.
Мы всё сделали правильно
разработчик > бизнес
Код как самоцель. ПО, разработанное претенциозными художниками, музыкантами с «Титаника» и Lisp-хакерами.
Разработка ради красивой строчки в резюме
разработчик > *
ПО, создаваемое, когда на кону ничего не стоит и разработчики могут делать всё, что захотят.
Мнимое ПО
бизнес > пользователь > (-ops) > разработчик
ПО, которое создаётся, но редко (или никогда) не добирается до продакшена. Я называю его мнимым ПО. Черити Мейджорс называет это жизнью в иллюзиях.
biz > (-user) > ops > dev
Ещё один вид мнимого ПО — такой, у которого нет пользователей. (Зато есть масштабирование). Это ПО, которое не решает проблему или решает не ту проблему, возможно, ничью проблему. Разработчики берут громкую технологию и начинают забивать ею гвозди, пока не получат нечто, смутно напоминающее сценарий использования.
Поздний капитализм
(-biz) > пользователь > ops > разработчик
ПО, финансируемое венчурным капиталом, не имеющее бизнес-модели, или бизнес-модель которой сформулирована так: растём, пока не станем монополией, затем будем эксплуатировать пользователей.
Слон
Если вы всё ещё в гневе не закрыли вкладку браузера, то позвольте мне закончить, вернувшись к этой схеме:
бизнес > пользователь
У неё могут возникнуть проблемы, которые сложно решить.
Как говорилось выше, я осваивал своё ремесло, считая, что ПО позволяет решать проблемы конечных пользователей. Это изложено в одном из последних советов книги «Программист-прагматик»: наша цель — приносить радость пользователю, а не просто выпускать код. Но с того времени, как я начал работать программистом, это допущение соблюдать становится всё сложнее.
Сейчас выпускают много ПО, которое не заботится о пользователях, или которое манипулирует ими, или превращает их в продукт. И это относится не только к соцсетям: пользователь не может забронировать номер в отеле, заказать еду или нажать на кнопку «Пуск» в Windows, не подвергшись нападению всплывающих окон; я даже не могу поискать ничего в Google, не получив в ответ кучу мусора.
Возник конфликт между тем, что мы считали хорошей работой, и тем, что считает прибыльным существенная часть индустрии; мне кажется, этим объясняется всё больший дискомфорт у многих профессионалов в разработке ПО. И хотя мы не можем вернуться назад и просто закрыть глаза, игнорируя экономические реалии нашей отрасли, возможно, нам стоит сильнее отстаивать этику защиты пользователей от вреда. Мы можем признавать, что пользователь не всегда превыше бизнеса, но и бизнес при этом не должен всегда быть главным:
пользователь > ops > разработчикбизнес > ops > разработчикбизнес ≹ пользователь
