От автора: в этой статье я расскажу о: почему большим компаниям сложно правильно работать; почему Angular – отличный вариант для крупных компаний; как это сделать. В конце статьи после обсуждения некоторых движущих факторов и проблем я дам список из 12 советов, как архитекторы в крупных организациях могут увеличить продуктивность команд.
Сложности крупных организаций
Большие и маленькие организации заботит одно и то же:
Их волнует однообразие. Если все команды используют свои техники написания ПО, код сложнее повторно использовать и интегрировать. Однообразие помогает разработчикам сосредоточиться на бизнес проблемах и не заниматься решением общих проблем снова и снова.
Им нужно писать надежный, проверенный код: обработка ошибок, условия гонки и т.д.
Им нужно писать обслуживаемый, самодокументированный код.
Они хотят иметь возможность вносить изменения без лишних сомнений. Если разработчики могут быстро понять, что изменения можно безопасно мёржить, они больше расположены на поддержание здорового кода.
Чем отличаются большие организации – у них сотни инженеров по Angular, занятых в десятках приложений. У них много кода, и это меняет все.
10 разработчиков могут быстро прийти к общему мнению о лучших практиках за обедом, что не могут сделать 500 разработчиков. Вам нужно установить лучшие практики, стандарты команды, а также использовать инструменты для их продвижения.
Концепции владения кодом становятся важнее с ростом его размера и сложности. В трех проектах, например, разработчики всегда знают, кому лучше отдать ревью PR, в 30 проектах они уже не знают. Нужно явно задавать и автоматизировать модель владения.
В 3 проектах, например, разработчики будут знать, что нужно протестировать повторно после внесения изменений, в 30 проектах это уже далеко не такой простой процесс. Неформальные правила в команде по управлению изменениями не работают в больших командах и между большими командами.. Тут нужно полагаться на автоматизированный CI процесс.
…
Другими словами, маленькие организации могут работать в неформальном процессе, чего не могут крупные компании. Специальный процесс также усложняет набор новых разработчиков.
Angular – хороший фреймворк для крупных организаций
Как один из главных соучастников Angular (2 и выше), неудивительно что я считаю, что Angular отлично подходит для компаний любого размера, больших и малых. Но позвольте мне рассказать о том, почему большим компаниям этот фреймворк особенно подходит.
Нет фрагментации
Сообщество Angular не фрагментировано. Почти все приложения построены на Angular CLI, Angular роутере, и многие используют NgRx (или думают о его применении) для управления состояниями и побочными эффектами. Это приводит к единообразию. Когда к команде присоединяется новый разработчик, за пару дней команда может выйти на высокую продуктивность. Команда также может перемещаться внутри организации, оставаясь продуктивной.
Семантическое версионирование
Каждые 6 месяцев выходит новая версия Angular. Если анонсированы критические изменения, у вас будет год на обновление приложений. Это усложняет мне жизнь, как соучастнику в фреймворк (например, я не могу фиксить ошибки в дизайне роутера), но также я помогаю компаниям добиваться успеха намного проще вместе с Angular.
Angular любит TypeScript
TypeScript – одна из лучших вещей, которые произошли с JS. В нем добавили предупреждения и ошибки. Также он артикулирует намерение и удаляет двусмысленность (более подробно). Angular – не единственный фреймворк, хорошо работающий с TypeScript – это умеет большинство современных фреймворков. Но это единственный фреймворк, в котором вся экосистема отлично работает с TypeScript: все инструменты и библиотеки. Как результат, типовые данные никогда не устаревают, отличный и эргономичный API при работе с типами, инструментами для манипуляций с исходным кодом используют API компилятора TypeScript. «TypeScript как единый язык сильно отличается.»
Автоматизация
Большие организации полагаются на инструменты и автоматизацию. Зачастую это значит, что исходный код должен быть статически анализируемым. Angular построен с учетом этого. Он четко отделяет статические и динамические части приложения, что позволяет писать надежные инструменты, манипулируя исходным кодом Angular. Кроме того, инструменты могут создавать, тестировать, запускать и запаковывать приложения Angular без разработчиков.
Как это сделать
4 главных области, которые больше всего влияют на вашу организацию:
Управление исходным кодом
Управление зависимостями
Продвижение лучших практик и
Автоматизация
Разберем их подробно.
Управление исходным кодом/зависимостями
Как я уже сказал выше, у больших организаций много исходного кода и много людей, которые его меняют, пакуют, развертывают и т.д. Поэтому сначала вам нужно ответить на вопросы – как хранить код, как эффективно вносить изменения, как настроить зависимости между разными проектами, как создать и выпустить проект. Как только вы начнете изучать эти вопросы, вы поймете, что не все проекты/модули похожи.
В типичной установке есть 4 категории проектов/модулей:
Приложения. Это ваши продукты, что вы даете пользователю.
Специальные библиотеки для приложения. Это разделы приложения, которые можно разработать и протестировать независимо.
Повторно используемые библиотеки. Это компоненты, сервисы, утилиты, используемые в разных приложениях.
Сторонние библиотеки и инструменты.
Эффективный разработчик должен уметь:
Создавать специальные библиотеки для приложения
Экспортировать повторно используемые библиотеки
Проверять, что изменения в коде повторно используемых библиотек не поломают приложения и зависящие библиотеки
Рефакторить несколько приложений и библиотек за раз
Определять, кто ответственный за определенного приложение или библиотеку
Как разработчики справляются с этими пунктами сильно влияет на скорость команды и качество кода в проектах.
Если на создание повторно используемой библиотеки нужен день (создать репозиторий, настроить CI, опубликовать в локальном npm репозитории), то немногие смогут это сделать. В таком случае разработчики будут дублировать код или вставлять его туда, где он не нужен. Когда повторно используемую библиотеку можно легко подстроить за несколько минут (а не дней), разработчики начнут вкладывать усилия и создавать и поддерживать повторно используемые библиотеки.
Если несколько приложений зависят от нескольких библиотек, регрессионное тестирование может усложниться при изменении библиотек. Если невозможно автоматически проверить, что изменения в общие библиотеки не поломают приложения, разработчики будут бояться вносить изменения и будут писать оборонительный хрупкий код.
«Если разработчики не могут рефакторить одновременно несколько приложений и библиотек, они не будут развивать API.»
Когда разработчики не могут создавать и тестировать разделы приложения независимо, они будут создавать монолитные приложения с тесно связанными модулями. Когда у них будет такая возможность (при использовании специальных библиотек для приложения), они будут писать более обслуживаемый код и улучшать архитектуру приложения.
Это связано главным образом с тем, что они должны четко определять, от какой функции зависит приложения, а также что она экспортирует. Результат похож на гексогональную архитектуру, которая снижает связь между проектами.
Nrwl Extensions для Angular (Nrwl/Nx)
Nrwl Nx — open source набор инструментов для корпоративных приложений Angular, построенных на Angular CLI. Инструмент решает многие связанные с Angular CLI проблемы. Он использует подход монорепозитория, в котором много приложений и библиотек хранятся в одном репозитории исходного кода (подробнее).
С Nrwl/Nx разработчики могут:
За минуты создавать библиотеки для приложений
Извлекать общие библиотеки за пару минут
Проверять, что изменения в коде общих библиотек не поломают другие приложения и библиотеки (В Nx есть команды для повторной сборки и тестирования только тех приложений, которые затронуты PR)
Рефакторить несколько приложений и библиотек за раз
Nx также принуждает вас использовать одну версию всех сторонних библиотек (при необходимость можно это обойти). Это важно. Если ваши приложения и библиотеки зависят от разных версий, скажем, TypeScript, то их, возможно, нельзя повторно использовать. Использование комбинаций из разных библиотек может привести к тяжело отлавливаемым багам. Даже если вы не используете Nx, рекомендую создать пакет third-party, перечислить главные сторонние зависимости в нем, и связать их с приложениями.
Nx не заботится о владении кодом, так как его интересует способ хранения исходного кода. Если вы используете GitHub, можете воспользоваться файлом CODEOWNERS.
Будете вы использовать Nx или нет, явно объявите рабочий процесс для пять описанных выше операций, задокументируйте их и измеряйте, сколько времени у разработчиков уходит на выполнение.
Продвижение лучших практик и автоматизация
Зачастую нечто очень простое может оказывать сильное влияние.
Например, создание небольших общих библиотек. Даже если в общей библиотеке будет всего 30 строк, вы можете повысить продуктивность команды и сэкономить много недель работы.
Например, в каждом приложении команды Nrwl много условий гонки. Некоторые из них очевидны, а некоторые очень тонкие, и их происхождение трудно отследить. Даже самые опытные старшие разработчики Angular могут не заметить тонких условий гонки.
Помогая многим клиентам решить эти проблемы, мы были вынуждены спросить себя: «можем ли мы создать небольшой инструмент, устраняющий условия гонки в коде?».
В итоге мы написали сервис из 50 строк, интегрированный с NgRx Effects и устраняющий множество условий гонки из Web applications. Эта критическая функция такая маленькая, что вы можете прочитать ее и понять принцип работы за пару минут. Мы включили ее в Nx. Приучите своих разработчиков делать то же самое. Можете начать с трех областей, которые, как правило, вызывают больше всего проблем: тестирование, управление состояниями и роутинг.
Создание схемы генерации кода
Angular CLI использует библиотеку схем для генерации кода. Nrwl/Nx построен поверх Angular CLI и передает пользовательскую коллекцию схем, адаптирующую интерфейс CLI для нескольких приложений/библиотек. Корпоративные команды должны пойти еще дальше и создать коллекцию схем, используемых в компании. Например, если используются макетные данные в интеграционных тестах, создайте схему для генерации прибора.
Измерьте, сколько времени требуется разработчику на реализацию простого генератора исходного кода. Люди будут что-то делать, когда на это будут уходить минуты.
Создание кастомного линтера
TSLint хорошо справляется с двумя вещами: проверяет, что разработчики не допустили тяжелых ошибок, и делает исходный код более единообразным. TSLint можно запускать на CI, а также интегрировать со всеми основными редакторами и IDE.
Воспользуйтесь этим инструментом. Настройте его и задокументируйте процесс создания новой проверки TS lint, чтобы разработчики могли делать это за минуты.
Автоматизируйте все (используйте форматтеры)
Удивительно, что мало компаний настраивают такие вещи, как форматирование кода. В основном люди думают, что это не самое главное, чему следует уделить внимание. И я соглашусь, если настройка форматирования отнимет недели. Но на деле это занимает 30 минут, а эффект довольно большой: исходный код более последовательный, устраняются целые классы проблем.
Самое главное преимущество форматирования – комиты и ревью кода. Показываются только реальные изменения в коде, а не сотни изменений в форматировании, которые могут запутать вас при критических изменениях в коде.
«В Nrwl Nx есть команды для настройки автоматического форматирования кода локально и на CI.»
Чеклист архитектора
Список советов, к которым архитектор в большой компании может прибегнуть для улучшения продуктивности.
Определите набор используемых инструментов для создания Angular приложений (CLI, Nx, NgRx). Разработчики любят писать кастомные инструменты, но почти всегда лучше использовать стандартные решения, как минимум, в долгосрочной перспективе. Создайте образец репозитория через эти инструменты.
Определите процесс создания/извлечения новых библиотек. Замерьте время.
Определите процесс ревью изменений кода общих библиотек так, чтобы это не ломало приложения и другие библиотеки. Разделяйте среду разработки и CI. Измерьте время.
Определите процесс рефакторинга нескольких приложений и библиотек.
Определите процесс назначения и проверки владения. Без хорошей модели владения будет хаос.
Определите стратегию управления исходниками: trunk-based разработка или разработка на основе функций. Попробуйте что-то одно для всех приложений и библиотек.
Определите четкую политику управления сторонними зависимостями.
Определите лучшие практики управления состояниями и побочными эффектами. Максимально автоматизируйте.
Определите лучшие практики по тестированию. Максимально автоматизируйте.
Создайте для организации пакет tslint. Отличный способ продвижения лучших практик.
Создайте для организации пакет схем. Отличный способ продвижения лучших практик.
Автоматизируйте все, что можно (например, настройте автоматическое форматирование).
Nrwl Nx решает множество описанных задач. Поэтому мы его и создали. Но как и с большинством других инструментов, дело не в использовании определенного инструмента, а в выборе инструментов и процессов.
Автор: Victor Savkin
Источник: https://blog.nrwl.io/
Редакция: Команда webformyself.
