Наконец-то передал в издательство перевод книги Full Stack JavaScript Strategies: The Hidden Parts Every Mid-Level Developer Needs to Know / «Фулстек JavaScript: Секреты, которые должен знать каждый миддл» — автор Милесия МакГрегор (см. рис. 1), и хотел бы немного рассказать о том, что в ней на мой взгляд полезного.

Пардон, если получится несколько сумбурно, описываю книгу в таком формате впервые. И поскольку я не разработчик, а ИТ-переводчик, я старался писать свои соображения подкреплять цитатами из книги.

1. Переход от middle к senior уровню

Эта книга не столько о коде, сколько о целостном подходе к взаимодействию с продуктологами и подотчетными разработчиками. 

Она о том, как происходит смена мышления у middle-разработчика в сторону senior-разработчика (см. рис. 2). Автор в частности поясняет, что «цель этой книги — дать вам справочник для работы с новыми и legacy-проектами во фронтенде и бэкенде, а также для их развертывания». 

Автор приводит приемы senior-разработчиков, чтобы «работать скорее на уровне системы, чем отдельных строк кода» и находить оптимальные/компромиссные решения. Примеры таких решений на уровне архитектуры приводятся через проектирование e-commerce платформы с интеграцией нескольких систем. В частности, вместо реализации отдельных эндпоинтов вы будете «продумывать их взаимодействие с базой данных, событиями, соглашениями об именовании и схемами данных».

2. Практичность примеров кода

Несмотря на то, что книга не о коде, в ней приводится много примеров кода, которые доступны по адресам https://github.com/flippedcoder/dashboard-web и https://github.com/flippedcoder/dashboard-server —  можно брать и изучать в комплексе, а  не через изолированные сниппеты. 

По ходу объяснений автор периодически предлагает поупражняться в реальных продакшен-сценариях (см. рис. 3), типа «добавить обработку ошибок, логирование и валидацию к оставшимся конечным точкам в контроллере заказов». 

3. Работа с legacy-проектами

Автор предлагает системный подход к работе с legacy-проектами (она сразу предупреждает, что такие проекты будут у сеньора в большинстве случаев). Подходить к таким проектам она предлагает с реверс-инжиниринга функциональности через изучение кодовой базы. Цитата: «Когда начинаете изучать код, двигайтесь в обратном направлении от элементов, которые видите в пользовательском интерфейсе. Такой подход проведёт вас через весь стек — от фронтенда до базы данных и других частей инфраструктуры. Попробуйте реверс-инжиниринг некоторых фич, чтобы понять используемые командой подходы и паттерны реализации».

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

4. Архитектурные решения для бэкенда

Основные архитектурные решения в книге автор рассматривает через NestJS как основной (но не единственный) фреймворк: «По сути, это готовая бэкенд-архитектура “из коробки”. Сразу после инициализации приложения вы получаете доступ к валидации, аутентификации, маршрутизации, контроллерам, схеме данных и множеству других функций».

5. Взаимодействие с командами

Автор рекомендует: «Устанавливать строгие соглашения по коду для API как можно раньше; создавать начальные эндпоинты для старта работы фронтенд-разработчиков». 

Милесия также поясняет, как лучше всего понять логику решений смежных команд (см. также рис. 2): «Главное — поддерживайте постоянную коммуникацию между вашей командой, продуктовой командой и командой дизайнеров, чтобы минимизировать риски недоразумений».

6. Про фронтенд-разработку

Автор предупреждает: «специфика новых сложностей заставит вас иначе подходить к деталям реализации по сравнению с бэкендом», и если вы легкомысленно отнесетесь к предварительному проектированию архитектуры, изменения начнут «расползаться» и проявляться в разных непредсказуемых местах.

Для управления состояниями и производительностью автор предлагает создавать диаграммы архитектуры, из которых будет видно, «как состояние (state) должно передаваться между компонентами». При этом Милесия рекомендует показывать черновой вариант архитектуры команде и собирать обратную связь, а также предлагает middle-разработчикам взять на себя проработку контейнеров, добавив детали, такие как состояния, вызовы API и условный рендеринг.

Автор также настоятельно рекомендует рассматривать помимо React и другие фреймворки (также см. рис. 4): «Svelte и Solid.js предлагают отличный DX и в некоторых случаях даже превосходят React», пробуйте по возможности внедрять эти решения, поскольку «наша профессия развивается только тогда, когда кто-то предлагает изменения, а другие видят преимущества этих изменений».

Отзывчивость интерфейсов автор предлагает обеспечивать через выбор инструментов сборки, таких как Vite, Rollup, esbuild и Webpack, поскольку «выбранный инструмент … влияет на размер бандла, совместимость с другими инструментами, производительность приложения и скорость его развертывания». Автор также подчёркивает важность оптимизации бандла в CI/CD-пайплайне: «убедитесь, что код минимизирован, а ресурсы сжаты».

7. Про развертывание и DevOps

Автор подробно останавливается на разборе процесса деплоя приложения в продакшен с точки зрения взаимодействия с различными командами: «обычно вы будете сотрудничать как минимум с одной дополнительной командой для создания всей инфраструктуры в облаке», чаще всего с командами инфраструктуры, DevOps и SRE.

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

В книге интеграция фронтенда, бэкенда и вспомогательных систем описывается через настройку CI/CD-пайплайна: «… процесс включает настройку сред для развертывания фронтенда и бэкенда, а также определение места хранения секретов и учётных данных». Автор подчёркивает, что разработчикам нужно «перепроверить, какие именно эндпоинты вызываются, чтобы убедиться в правильном подключении сред на фронтенде и бэкенде, а также выполнить проверки данных для подтверждения их происхождения из нужной среды».

8. Про soft-skills

Я уже касался этой темы в начале обзора, но не грех повторить и «углубить». Книга учит задавать правильные технические и продуктовые вопросы через практику взаимодействия с командами: «Задавайте любые возникающие вопросы по мере изучения дизайна с точки зрения пользователя. Вы удивитесь, сколько граничных случаев можно выявить, просто задавая вопросы».

А вот мнение автора про общение со смежными командами: «Постоянная и частая коммуникация с продуктовой командой и стейкхолдерами поможет избежать неожиданностей для всех. Сообщайте о возникающих проблемах, даже если они, на первый взгляд, не повлияют на сроки».

Автор также учит «выявлять источники бизнес-логики для любого приложения», чтобы предугадывать, в какую сторону будут эволюционировать требования и как выбрать между различными архитектурами и сторонними сервисами с учётом долгосрочных перспектив развития продукта.

На этом вроде всё, надеюсь, моя информация помогла составить некоторое представление об этой книге.

Остальное, безусловно более правильное описание, думаю, даст уже само издательство, когда книга будет опубликована.