Повторное использование кода является одним из наиболее распространенных ключевых моментов в разработке программного обеспечения. Множество фреймворков, библиотек призваны структурировать код для повторного использования. Как оказывается, каждый из инструментов имеет не только собственный подход к достижению этой цели, но и свое собственное определение повторного использования кода.
Что подразумевается под повторным использованием кода?
Истинное определение повторного использования кода — это не специальный процесс, а стратегия развития. Многоразовые компоненты должны изначально создаваться с учетом их повторного использования, что предполагает тщательное планирование и интуитивный API-интерфейс. Хотя современные инструменты и фреймворки могут поддерживать и стимулировать, повторное использование невозможно только с помощью технологии — для этого требуется налаженный между командами процесс, и обязательства на всех уровнях компании.
Поэтому, когда мы говорим про повторного использование, это не подразумевает только техническую часть. Оно также включает в себя корпоративную культуру, обучение и множество других соображений. Мы затронем некоторые из них здесь, но дело в том, что повторное использование кода — это процесс, который затрагивает все стадии разработки и каждый уровень организации.
Walmart состоит из нескольких брендов, включая Sam's Club, Asda, и региональных филиалов, таких как Walmart Canada и Walmart Brazil. Эти бренды имеют десятки приложений, созданных и поддерживаемых сотнями разработчиков.
Поскольку каждый из этих брендов занимает свое место в Интернете, у каждого есть разработчики, работающие над компонентами, которые являются общими для всех брендов Walmart, например: карусель, Breadcrumbs, всплывающие окна, компоненты форм оплаты. Дублирование той же самой работы, которая сдалала другая команда — трата времени и денег, а также допускается возможность совершить те же ошибки разными командами. Устранение дублирования позволяет разработчикам быть более сфокусированными на проектах.
На бекенде потвроное использовние кода происходит более интуитивно: какой-нибудь сервис может принимать запросы от разных брендов и возвращать соответствующие для этого бренда данные(есть разные способы справиться с этим в зависимости от формы данных). Для фронтенда ситуация немного сложнее, потому что данные с сервера преобразуются и стилизуются соответственно конкретному бренду. Для фронтенда повторное использование кода не является полностью решенной проблемой.
Повторное использование React компонентов в @WalmartLabs
Мы выбрали React для Walmart.com, в основном, из-за того, что его компонентная модель является хорошей отправной точкой для повторного использования кода, особенно в сочетании с Redux для управления состояниями. Несмотря на это, в Walmart до сих пор возникают трудность повторного использования фронтенд кода.
Инструменты для повторного использования кода
Первая задача связана с техническими средствами совместного использования кода. Компоненты должны версионироваться, легко устанавливаться и обновляться. Мы завели отдельную GitHub организацию, куда мы поместили все React компоненты. В настоящее время компоненты объединены в репозиториях на основе команд, которые их создали, но мы находимся в процессе перехода к более функциональному виду, например: репозиторий «Navigation», содержащий компоненты «Breadcrambs», «Tabs» и «Sidenav Links». Мы держим все компоненты во внутреннем npm реестре, что позволяет устанавливать определенные версии компонентов, гарантируя, что приложение внезапно не поломается при обновлении компонента.
Поскольку код используется несколькими командами, нам необходимо соблюдать согласованную структуру в пакетах и стандарты для сотен компонентов. Поэтому мы пришли к созданию Electrode Archetypes для компонентов и приложений. Archetypes содержат eslint, babel и webpack конфигурационные файлы и являются основным местом, где мы управляем зависимостями с помощью Gulp задач и npm скриптов. Начинать разработку со застандартизированной структурой позволяет нам поддерживать высокие стандарты во всей компании, также это добавляет разработчикам уверенности в чужом коде и увеличивает шансы повторного использования кода. Также повышает уверенность налаженные Continious Integration и Continous Deployment процессы, которые запускают Eslint, тесты производительности и кроссбраузерные тесты, используя разные разрешения экрана. При создании пулл реквестов Continious Integration может публиковать бета-версии компонентов и запускать функциональные тесты всех приложений, использующих этот компонент. Это дает гарантии, что пулл реквест ничего не сломает.
Meta команда
В первые дни этого проекта большинство разделяемых компонентов были внесены только определенными командами, и эти компоненты менялись очень быстро. В конце концов, мы отобрали нескольких разработчиков с глубоким пониманием структуры Electrode и Walmart изнутри и создали группу, которую мы называем meta командой. Эти люди посвящают несколько часов или один день каждые несколько недель, чтобы просмотреть код, входящий в организацию компонентов, обеспечить соблюдение всех лучших практик и, в целом, содейтсвуют и помогают возможными способами. Эта команда также собирала общие сведения о том, что создается во всей организации, и продвигала Electrode в своих собственных командах. Участники meta команды также распостраняли информацию о предстоящих изменениях archetypes в своих командах и собирали отзывы для основной команды Electrode.
Это было хорошое начало, но мы все же еще видели дополнительные возможности как улучшить повторное использование кода.
Проблема обнаружения сотен компонентов
Мы начали замечать много одинаковых сообщений в наших Slack каналах. Разработчики спрашивали, существут ли уже компонент для определенной задачи. UX команды хотели видеть, какие компоненты доступны. Менеджеры интересовались, какие компоненты создаются другими командами. Общей нитью всех этих сообщений было обнаружение конмпонентов. Нам нужен быстрый и простой способ узнать, какие компоненты доступны, увидеть, как они используются и как с ними взаимодействовать, узнать больше о реализации, конфигурации и зависимостях.
Нашим ответом на эту задачу был Electrode Explorer, о котором я рассказывал в предыдущем посте. Explorer позволяет разработчикам просмотреть сотни компонентов, доступных в @WalmartLabs, читать их документацию и видеть, как они реально выглядят в браузере, и даже просмотреть предыдущие версии компонента и увидеть, как они менялись с течением времени. Поскольку Electrode Explorer предоставляет веб-интерфейс для всех компонентов React в организации, разработчикам не нужно запускать npm install для того, чтобы увидеть и повзаимодействовать с компонентом.
Трудности полного избавления от дублирования
Даже уже имея все эти инструменты и процессы для повторного использования кода, мы по-прежнему испытывали трудности. Одна из проблем заключалась в том, что команды часто разрабатывали новые компоненты, не осознавая, что они могут быть полезными для других команд. Компоненты не получалось повторно использовать, если они изначально не были включены в экосистему с повторным использованием кода. Даже в рамках общей системы компонентов мы наблюдали много дублирования, также были и компоненты, которые слегка отличались от подхода в других компонентах с похожими задачами. Мы поняли, что одного технологического решения недостаточно — нужно было менять в масштабах компании, в которой все заинтересованные стороны на всех уровнях используют подход, ориентированный на повторное использование кода. Это включало в себя выделение проектного времени для обобщения компонентов, расширение существующих компонентов вместо создания новых, и осознанно искать возможности совместного использования кода, где было возможно.
Чтобы помочь в этом процессе, мы создали процесс, где мы могли предложить новые компоненты. В рамках этой системы разработчики обсуждают новые компоненты перед началом работы над ними. Это дает разработчикам в других командах возможность предлагать существующие решения или альтернативные подходы и осведомляет о происходящем других людей в коллективе.
Процесс предложений компонентов вместе с мета-процессом помогли избежать все еще происходивших время от времени дублирований.
Важность Continious Integartion и Continious Deployment (CI / CD)
Мы столкнулись с одной серьезной проблемой, что пока одна команда будет работать над компонентом — это может навредить приложению другой команды. Если вы не заблокировали компонент на определенной версии в проекте, ваш CI / CD может сообщить о провалившихся тестах, потому что компонент был изменен в другой команде. Это очень неприятные ситуации, которые приводили многие команды к блокированию компонентов на определенных версиях, что не позволяет даже принимать новые патчи для компонента.
Вот именно в этот момент CI / CD проявляет себя во всей красе. Когда компонент обновляется, автоматизация должна запускает тесты приложениях, которые использую ту же основную версию компонента. Тесты запускаются даже если приложение заблокировало компонент на определенной версии. CI / CD система создает пулл реквест на запрос обновления заблокированной версии до новой, если тесты прошли успешно. В случае провалов на тестах команды получают уведомления, и позже совместно разрешают проблему.
Inner source философия
Основополагающим фактором для многократного использования стало наше понимание философии open source / inner source, описанной Лораном Десегуром в предыдущей статье. WalmartLabs уже много лет активно использует и разработывает open source, чему свидетельствуют проекты, как Hapi, OneOps и Electrode. За пределами компании не так заметно, но мы очень привержены к модели inner source, которая, по сути, является закрытой реализацией open source. В inner source подходе ни одна команда или разработчик «не владеют» компонентом — все компоненты являются общими для всей организации. Это уменьшает возможные ошибки и позволяет разработчикам сосредоточится на улучшение существующих компонентов.
Такая политика значительно расширила возможности для повторного использования. Что еще более важно, она информирует разработчиков о нашей приверженности к философии сотрудничества. Также это позволяет разработчикам использовать свое время и знания там, где они больше всего необходимы, вместо проведения времени отлавливая сложную ошибку в коде, и они приносят реальную пользу компании, что легко заметить.
Выводы
Повторное использование — это не просто техническое решение, но и философский подход, который требует организационной приверженности и имеет долгосрочные последствия. В WalmartLabs мы видели преимущества, которые он может принести — сейчас мы переводим SamsClub.com на платформу Electrode, и наши разработчики повторно используют сотни компонентов от Walmart.com с настройками для Sam's Club.
Расскажите вашу историю повторного использования — с какими проблемам вы столкнулись? Как вы их решали? Что хотели бы улучшить в дальнейшем?
Автор: semashko_sergey
