От беспорядочной кодовой базы до новой эры стабильного качества во всей компании
Вам когда-нибудь приходилось разрабатывать запутанный код? Вы когда-нибудь меняли проекты и чувствовали себя потерянными из-за разных стандартов?
Вероятно, каждый прошел через один из таких сценариев. Мы тоже были, но мы нашли способы улучшить единообразие стиля кода в компании.
Вот основные проблемы, которые привели к противоречивой кодовой базе, с которой нам пришлось столкнуться:
- много разработчиков в уникальном проекте
- много разработчиков во многих проектах
- специфические потребности компании (например, индивидуальные правила, которым необходимо следовать)
Сначала позвольте мне начать с истории…
В сентябре 2017 года мы выпустили первое PWA (Progressive Web App) QuintoAndar. Это означает, что мы фактически переписали все существовавшее ранее интерфейсное приложение.
(Я был частью этой команды, это был потрясающий опыт! Я расскажу об этом в другом посте)
Через год после выпуска у нас сейчас около 10 PWA. Все они используют один и тот же стек: React + Redux и повторное использование кода между проектами.
Мы уже получили представление о том, насколько плохи могут быть дела на нашем старом веб-сайте, если все не будет под контролем, и мы определенно не хотели, чтобы наш блестящий новый проект пошел по тому же пути.
Как всем известно, JavaScript - потрясающий язык программирования с тысячами библиотек и различными проектами по всему миру. Однако мир JS не совсем идеален! Но если бы мне пришлось резюмировать главный спор:
«Лучшее и худшее в javascript - это отсутствие ограничений, которые позволяют нам делать все, что мы хотим»
У нас так много «свободы» с JS, что удивительно, потому что мы можем создавать множество вещей. Однако это тоже опасно! Только представьте, что многие разработчики могут делать все, что захотят, в одном проекте без каких-либо стандартов / согласованности.
Это может превратиться в беспорядок, поскольку это был наш старый проект. Грязный код трудно читать, тестировать и поддерживать. Это делает проект более «глючным», и новым разработчикам становится труднее внедрить его.
Как разработчик я бы предпочел не давать такой «свободы», поскольку мы можем получить немного слишком много творчества!
Итак ... Как мы не повторили ошибок старого проекта в новых? Как мы предотвратили беспорядочный код?
Мы устанавливаем границы своей «свободы»! Мы накладываем ограничения на проект, чтобы код был чистым и непротиворечивым. Это помогает разработчикам быть творческими в решениях проблем, не связанных с стилем кода.
Как мы установили границы?
Прежде всего, мы задействовали как минимум одного рецензента кода в каждом запросе на вытягивание! К сожалению, это не автоматизировано, потому что это зависит от людей, поэтому оно также не может масштабироваться, и некоторые ошибки и несоответствия пройдут!
Для автоматизации мы использовали анализаторы кода, чтобы проверить стиль кода и передовые методы. Таким образом, мы можем гарантировать, что все файлы JS в проекте будут согласованными.
Это приводит к улучшению читаемости и ремонтопригодности кода. Это также помогает находить синтаксические ошибки и содержать меньше ошибок. Сделать этот процесс частью CI - ключ к обеспечению соблюдения стандартов в течение всего цикла разработки.
Линтеры кода есть практически для любого языка программирования, в JS наиболее популярным является Eslint *.
* Если вы хотите узнать, как это работает внутри компании, вы можете увидеть здесь, а по eslint есть много статей, как вы можете увидеть здесь.
Теперь вы можете подумать:
Хорошо, линт .. Все знают .. Почему я читаю эту статью?
Нам пришлось масштабировать это решение для нескольких проектов и репозиториев, и это может стать проблемой. По мере роста компаний растет и количество проектов на JS, включая серверную часть на NodeJS.
Итак, как сохранить одинаковый стиль кода и качество кода для всей кодовой базы?
Как я уже говорил, у нас есть 10 PWA и библиотека внутренних компонентов. Вдобавок к этому у нас есть несколько микросервисов в NodeJS. Как мы видим на изображении ниже:
Таким образом, мы действительно понимаем, как сложно поддерживать одинаковый стиль кода и качество кода во всей кодовой базе.
Тем не менее, вы можете подумать, что это не большая проблема, потому что мы можем просто скопировать и вставить конфигурацию и правила eslint во ВСЕ наши проекты .
Это решение, но, очевидно, не самое лучшее!
Каждую новую конфигурацию или новое правило, которое вы хотите ввести, вы должны пройти через все проекты, реплицирующие одно и то же.
Настоящая опасность здесь заключается в том, что вы можете забыть применить какое-то изменение в одном из них, и когда вы это увидите, мы снова не будем следовать одному и тому же стилю кода = ›несогласованная база кода 😑
Для этого лучший способ исправить это - использовать классную функцию Eslint под названием Совместно используемые конфигурации.
Общие конфигурации
Все конфигурации eslint проекта находятся в файле с именем .eslintrc. Этот файл является важной частью вашего проекта, и иногда вы можете захотеть поделиться им с другими проектами или людьми.
Как мы можем этим поделиться?
Общая конфигурация позволяет публиковать параметры конфигурации в npm. Разрешить другим загружать и использовать его в своих проектах ESLint.
Все, что вам нужно сделать, это добавить его как dev-зависимость в свой проект и расширить в файле ресурсов eslint.
Прямо сейчас в npm есть много общих конфигураций, как мы можем видеть здесь. Один из самых популярных - Airbnb. Это тот, который мы используем и в QuintoAndar, но мы почувствовали необходимость добавить и наши собственные настройки.
Таким образом, мы создали наши общие пакеты конфигурации eslint-config-quintoandar. Но, как вы знаете, у нас есть определенные вещи для PWA (передняя часть) и некоторые из наших микросервисов (серверная часть). Вот почему мы создали:
- eslint-config-quintoandar-base - это пакет npm, который является общим для всего в JS и использует NodeJS (см. на GitHub).
- eslint-config-quintoandar-pwa - еще один пакет npm, который имеет определенные конфигурации для реагирования приложений. Он расширяет базовый пакет QuintoAndar (eslint-config-quintoandar-base) и добавляет определенные вещи (см. На GitHub).
Не стесняйтесь использовать наши пакеты, и мы также открыты для внесения взносов. Все задокументировано. Если вы хотите создать свой собственный, вы также можете использовать его в качестве справочника.
В QuintoAndar мы все еще работаем над этими пакетами и их использованием. Но результаты видны, с помощью этого инструмента вы можете поддерживать такое же качество кода и приложений, потому что мы могли бы использовать правила, которые помогают находить ошибки и повышать производительность.
Например, одно простое правило, которое помогает нам избежать ненужной потери производительности, заставляя не использовать стрелочные функции или привязку внутри рендеринга компонентов React, например это (строка 8):
Приведенный выше код не передается в наш eslint и, следовательно, нарушает сборку (CI), вынуждая разработчика исправить это.
Пример выше - это правило, которое уже существует в пакете, предоставленном Airbnb. Если вы чувствуете необходимость, как и мы, создать правила для ваших конкретных сценариев, вы можете создать собственные правила.
Пользовательские правила
Иногда вам нужно обеспечить соблюдение определенного правила в своей кодовой базе, которое не будет актуальным за пределами вашей компании, или вам нужно создать правило, которого еще нет во многих существующих плагинах с открытым исходным кодом. .
Создать новое правило действительно легко и просто.
Вам просто нужно использовать AST (абстрактное синтаксическое дерево), чтобы найти то, о чем вы хотите сообщить, и установить описание того, как это исправить. Если вам нужно более подробное описание, вы можете найти его в этой статье или в eslint docs.
В QuintoAndar - пакет npm с нашими собственными правилами:
eslint-plugin-quintoandar (GitHub).
В этом плагине у нас есть разные виды пользовательских правил:
Правила, применимые к каждому проекту любой компании, например:
- Правило не позволяет использовать
target="_blank"безrel="noopener noreferrer"
Правила, применимые только для QuintoAndar, например:
- Правило, созданное для исключения внутреннего компонента, который больше не должен использоваться, или его также можно применить к функциям или файлам.
Правило об устаревании файла в вашем проекте - это самое простое правило, которое вы могли бы создать. Вам просто нужно подтвердить импорт следующим образом:
Как видите, очень легко настроить правила lint в соответствии с новыми потребностями вашей команды или компании, поддерживая согласованность и качество кода во всей кодовой базе.
Итак, окончательное решение для обеспечения стабильного качества кода во всей компании было:
- Добавить eslint во все проекты
- Создавайте и используйте npm-пакеты с общей конфигурацией для компании
- Создавайте новые индивидуальные правила в соответствии с новыми требованиями
Тем не менее, эти шаги не решат всей проблемы, потому что теперь это означает, что каждое новое правило должно применяться ко всем файлам во всех репозиториях одновременно.
Он не масштабируется и опасен, потому что мы можем сломать приложения. Итак, нам нужно понять, как применять правило постоянно, используя прогрессивный способ их применения.
Я уже сломал несколько приложений, пытаясь применить новое правило повсюду одним выстрелом. Однако я нашел лучший подход. Вы хотите узнать об этом?
См. следующую статью, в которой объясняется, что и как использовать Progressive Lint и почему вы должны начать это делать.
Прогрессивный линт: как постоянно улучшать кодовую базу
Во-первых, в моей работе (в QuintoAndar) я известен как« пристрастившийся к пуху или человеческий пух , потому что я всегда добавляйте мелкие детали на… medium.com »
Присоединяйтесь к нам
Если вам нравятся сложные задачи и вы хотите работать в стартапе, который меняет весь процесс аренды, используя технологии и дизайн в качестве основных компонентов. Посмотрите наши вакансии на нашей странице карьеры. Мы всегда ищем талантливых людей, которые хотят учиться.
Спасибо за прочтение! Я всегда открыт для получения отзывов, рекомендаций или вопросов, не стесняйтесь обращаться ко мне !!
LinkedIn: https://www.linkedin.com/in/pamepeixinho
Twitter: https://twitter.com/pamepeixinho секс
GitHub: «https://github.com/pamepeixinho
Веб-сайт: https://pamepeixinho.github.io
Моя фамилия ЛиттлФиш, я иногда плаваю и кодирую. «Море» тебе попозже! 😉
