О блоге
Софт развивается быстро, и большая часть материалов о нём либо тонет в хайпе, либо уходит настолько глубоко в детали реализации, что перестаёт быть полезной кому-либо, кроме уже состоявшегося эксперта именно в этой узкой нише. Это попытка найти середину: обоснованные разборы инструментов, архитектуры и практик, которые реально формируют то, как сегодня создаётся софт.
Каждая статья начинается с реального вопроса, на который приходится отвечать разработчику или тимлиду: стоит ли новый фреймворк затрат на миграцию, как паттерн на самом деле ведёт себя под нагрузкой, что инструмент делает правильно, а что нет, если пользоваться им дольше первого дня. Мы стараемся писать тот материал, который сами хотели бы прочитать перед тем, как принять это решение.
Мы не гонимся за каждым анонсом. Здесь в приоритете то, что имеет запас прочности — паттерны, инструменты и идеи, которые, скорее всего, останутся актуальными и через год, а не только то, что в тренде на этой неделе. Если что-то реально не проверено временем или вопрос ещё открыт — мы так и пишем.
Новые материалы собраны в разделе «Статьи» и охватывают практики разработки, инфраструктуру и повседневные решения, которые определяют, как команды реально создают софт.
Об авторе
Я почти десять лет проработал бэкенд- и инфраструктурным инженером, прежде чем начал писать об этом на постоянной основе, и этот опыт определяет почти всё, что я публикую. Я выкатывал миграции, которые в RFC выглядели просто, а заняли втрое больше времени, чем планировалось, и бывал по другую сторону разбора инцидента, пытаясь объяснить, почему паттерн, который работал на одном масштабе, незаметно переставал работать на другом.
Меня зовут Chris Bowen. Я работал и в маленьких стартапах, и в более крупных инженерных организациях — в основном с бэкенд-системами, инструментами разработчика и инфраструктурой, которая всё это держит вместе. Такой разброс не случаен — практика, которая имеет смысл для команды из пяти человек, может быть откровенно неверной для команды из пятидесяти, и я стараюсь явно обозначать, для какого контекста пишу, а не делать вид, что есть один универсальный ответ.
Я пишу, чтобы избавить других инженеров от той версии ошибки, которую уже совершил сам. Каждый материал здесь основан на том, что я реально строил, отлаживал или переносил, а не просто читал об этом. Если я сам не использовал инструмент в проде — я так и пишу, и стараюсь отдельно помечать хайп от подтверждённых фактов.
Помимо написания статей, я по-прежнему провожу значительную часть времени в реальных кодовых базах, консультируя по архитектурным и инфраструктурным решениям — именно это удерживает сайт привязанным к тому, как софт создаётся на практике, а не в теории.