Design-Patterns

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

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

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

Представьте: вы смотрите на экран, в руке у вас кофе, и вы думаете, использовать ли ещё один фреймворк CLI или создать свой собственный. Налейте себе ещё чашку, потому что сегодня мы погрузимся в кроличью нору создания расширяемого фреймворка CLI на Go, за что ваше будущее «я» скажет вам спасибо (и, возможно, даже даст вам пять через экран). Создание CLI-приложений на Go похоже на сборку мебели IKEA — кажется простым, пока вы не поймёте, что вам нужен несуществующий фреймворк....

Представьте: вы только что создали «шедевр» гибкого кода. Вы хлопаете по пять свою резиновую утку, с уверенностью производите развёртывание и обещаете заинтересованным сторонам: «Это справится с ЛЮБЫМИ будущими изменениями!» Перемотаем на три месяца вперёд: продукту требуется «одна небольшая корректировка». Вдруг ваш «гибкий» код напоминает переваренные спагетти — сопротивляется изменениям и полон сюрпризов. Знакомо? Давайте разберёмся, почему адаптивность кода часто оказывается миражем. Миф о «защищённом от будущего» коде Мы все поддавались сиренному зову чрезмерного проектирования....