Друг-CTO описал дилемму разработки через две тропы в гору. Левая — прорубиться мачете побыстрее, чтобы разведать местность. Правая — проложить широкую мощёную дорогу для всех. Первая приносит деньги сейчас, вторая — устойчивый продукт. Обе стороны считают «другой путь» ошибкой.
Автор предлагает третий путь — Best Simple System for Now (BSSN). Это самая простая система, которая решает задачу прямо сейчас и написана на должном уровне качества. Разберём элементы.
for Now. Система не должна предвосхищать будущее. Программисты склонны переусложнять: «это же очевидно, пригодится». Но наши прогнозы почти всегда «близки, но неверны». На деле код завален интерфейсами, которые никогда не использовали, алгоритмами на 20 000 пользователей при реальных двенадцати, и багами от этой сложности.
Simple. Простота — функция текущего момента. Нужно искать наименьшую сложность под текущие требования. Идеал не в том, чтобы нечего было добавить, а чтобы нечего было убрать. Галл сформулировал закон: работающая сложная система всегда вырастает из работавшей простой. Спроектированная с нуля сложная система не работает.
Best. Простота — не про халтуру. Код для ядра бизнеса должен быть качественнее экспериментального наброска. Хороший «набросок» — не хак, а облегчённая версия решения. Хороший код CUPID: компонуемый, следует философии Unix (делает одну вещь), предсказуемый, идиоматичный, предметно-ориентированный. Писать такой код можно быстрее, чем «прагматичный» мусор, с помощью хороших привычек, а не TDD или парного программирования любой ценой.
Против BSSN. Аргументы: «прототип выбросим» — но успешные прототипы идут в продакшен и обрастают костылями. WhatsApp с 13 инженерами на Erlang обслуживал полмиллиарда пользователей, SQLite с командой из трёх человек — один из самых распространённых продуктов. «Неполнота» — частичный функционал раньше лучше полноты никогда. iPhone первого поколения был 2G в мире 3G, без копипаста — и всё равно выиграл. Ричард Гэбриел назвал это «worse is better». «Неэффективно» — переделывать дорого. Но деньги сегодня стоят больше, чем завтра. Большие проекты с одним релизом накапливают Value at Risk (VAR). Ранние частые поставки снижают риск и приносят деньги раньше. Дональд Райнертсен показал, что Cost of Delay и Opportunity Cost важнее зарплат и лицензий.
Почему мы так не делаем? Мешает mindset дефицита: «либо качество, либо скорость». Нужен mindset изобилия: win-win. Кент Бек советует «сначала сделай изменение лёгким, потом сделай лёгкое изменение». Для этого нужны хорошие привычки, смелость («доверься один раз» — мы всегда откатимся по git) и смирение (быть как вода).
Примеры. В одном Java-проекте спорили о JSON-библиотеке. Выяснили: нужно передавать всего девять типов объектов. Вместо библиотеки написали простой интерфейс Jsonable<T> и реализовали его в девяти классах с однострочными методами. Ноль зависимостей, максимальная производительность. Во втором примере начала 2000-х вместо XML-фреймворков на Java написали свой простой стример.