_{вторая часть «четырех главных навыков разработчика»}

умение дробить целое на частные и реализовывать малые части большой системы в полной изоляции друг от друга

«Разделяй и властвуй» — проверенный временем слоган, отражающий стратегию управления большими проектами, типа империй. На английский он часто переводится как «divide and rule» и «divide and conquer». Можно видеть, что второй глагол довольно широко варьируется по времени применения, от «завоевывай», через «управляй» до «властвуй». Первый при этом незыблем, как влито́й: «разделяй». Кромсай. Отсекай лишнее от глыбы мрамора. Отгрызи себе ногу и спасись из капкана. Впрочем, я отвлекся.

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

Я никогда не знал, как расшифровывается «SOLID», потому что кроме SRP все остальные принципы оттуда — крайне противоречивы и в общем случае неприменимы из-за некорректности. Зато уж SRP — примени́м всегда, и в любом применении — облагораживает код, зачастую до неузнаваемости.

В любом курсе лекций, в любом выступлении на конференции, я всегда говорю: тщательно следите за тем, чтобы каждый кусок вашего кода выполнял ровно одну задачу, предоставлял внятный API и был оформлен библиотекой, а не втащен в основной проект. Потребовалась сплайн-интерполяция? — Библиотека, со своими тестами, с единственной экспортируемой функцией. Какая-нибудь особенная группировка? — Библиотека. Другая группировка? — Можно расширить экспортируемый API предыдущей библиотеки. Лог в приложении? — Библиотека, своя обертка над штатным логгером. И так далее. В самом приложении имеет право жить только голая сухая бизнес-логика.

Такой подход приносит за собой сразу несколько приятных побочных эффектов:

• если нашелся баг, его гораздо проще чинить в библиотеке, а не в гигантском проекте;
• если соседу потребовался логгинг, он воспользуется вашей реализацией и логи будут одинаковые;
• если вы захотите тестировать вызовы библиотеки, она может экспортировать удобные хелперы для этого;
• если библиотека нуждается в расширении возможностей, можно за пять минут закрыть новый API моками и продолжать разрабатывать приложение;
• если библиотека не завязана на бизнес-логику, ее всегда можно открыть в OSS и получить +5 к тестированию, +10 к новым фичам и +50 в карму.

Когда я слышу, что «эту фичу нельзя начать реализовывать до того, будет закрыт вон тот тикет», мне хочется ударить оратора клавиатурой. Как ты собираешься её тестировать, удод, если она у тебя завязана на сторонний код? Как ты можешь быть уверен, что она вообще работает, если без чужого кода — она даже не запускается? Зачем ты вообще, недотыкомка, пошел в программисты, когда вокруг есть столько замечательных профессий, вон хоть экскаваторщик, или поэт, или, там, тиктокер.

Если кто-то говорит, что код нельзя протестировать без другого кода, или что вот эта функция так задумана, что она обрабатывает данные, пишет в базу и варит кофе — это вредитель, его нужно гнать из команды.

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

Стремитесь к тому, чтобы каждая чашка в вашем сервизе могла быть использована по отдельности. Глупо доставать, пачкать, а потом мыть супницу и 24 блюдечка — после каждого выпитого кофе.