Architecture

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

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

Представьте: вы находитесь в кофейне, потягиваете переплатить за латте, и вдруг слышите, как два разработчика спорят о том, стоит ли создавать своё новое блестящее приложение с помощью React Native или же выбрать нативное развитие. Один разработчик драматично размахивает руками, крича: «Переиспользование кода!», а другой возражает: «Производительность и пользовательский опыт!». Знакомо? Что ж, возьмите ещё кофе, потому что мы собираемся глубоко погрузиться в вопрос о том, когда вам следует безоговорочно выбрать нативное развитие вместо кроссплатформенных решений....

Представьте: вы находитесь на технологической конференции, и каждый третий спикер восхваляет бессерверные вычисления, как будто это святой грааль современной разработки. «Нет необходимости управлять серверами!» — кричат они. «Бесконечное масштабирование!» — обещают они. «Платите только за то, что используете!» — скандируют они в унисон. Но вот в чём дело — и я говорю это как человек, который развернул множество функций Lambda и Azure Functions в продакшене — бессерверные вычисления не всегда являются решением, и рассматривать их как универсальную панацею — это путь к архитектурным проблемам....

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