Введение. С ростом бизнеса и быстрым увеличением числа членов команды разработчиков со всего мира приезжает много новичков, а также существуют разные стили и привычки кодирования. Обычно много проблем в коде обнаруживается при взаимном просмотре кода, со временем в коде появляются проблемы, которые сложно поддерживать, и даже возникают низкоуровневые ошибки. Поэтому я попытался провести некоторое исследование контроля качества внешнего кода, а также обобщил некоторые впечатления, чтобы поделиться с вами.
Автор: Чжэн Чжэньбо
Введение в план этой статьи
- Стандарты кодирования
- Избыточные файлы и код
1. Спецификации кодирования
В некоторых старых проектах мы часто сталкиваемся со следующими проблемами:
1.1 Формулировка стандартов кодирования
Как разработать стандарты кодирования? Это вечная тема.Были даже разработчики, которые постоянно модифицируют правила eslint в соответствии со своими привычками и представлениями.Да, очень субъективные разработчики будут это делать, и в конце концов обнаружат, что правила eslint превратились в кашу.
Если вы более объективны, вы можете рассмотреть проблему в этих трех аспектах:
- Учет привычек: Максимально учитывайте привычки каждого члена команды.У людей есть личности, и учесть кажется невозможным.
- Строгие правила: Чем строже правила, тем лучше, и никогда не позволяйте ему быть распущенным и непринужденным.
- Проголосуйте: голосование кажется наиболее демократичным решением, но часто самые спорные правила не будут иметь большого значения в количестве голосов.
Если вы можете получить результаты с помощью трех вышеперечисленных методов, то вы босс, и все становится слишком просто. Но в любом случае каждое расширенное правило может найти точки опоры и точки опровержения.При формулировании спецификаций студенты обычно выражают свое мнение в нескольких пунктах:
- Привычка: «Я делаю это все время, никаких проблем»
- Отраслевой стандарт: «Пойдите и посмотрите открытый исходный код большой компании».
- Необходимость: «Я никогда не видел JS, который не работает без точки с запятой в конце строки».
- Отнимает много времени: «Один раз табуляция экономит время и усилия, чем табуляция дважды; точки с запятой в конце строк — пустая трата жизни».
1.2 Нахождение баланса между качеством кодирования и эффективностью кодирования
Есть ли способ решить эти споры? Как соблюсти баланс? Можно сказать, что правила eslint, разработанные различными командами сообщества открытого исходного кода, расцветают повсюду, например, prettier, eslint-config-standard, airbnb и т. д. При выборе спецификаций кодирования следует учитывать следующие моменты:
- Подбор технологий, подходящих для проекта: Например, наша команда стек технологий использует React, Node.js, ES6, тогда мы можем четко знать, как выбрать направление.
- Высокая степень признания сообществом: я считаю, что уровень обсуждения сообществом не меньше, чем у членов команды.Если спецификация получает более 1w звезд, это уже здорово.
- Есть ли поддержка плагинов: возможность поддержки ESLint, JSCS и т.д.
Основываясь на вышеуказанных критериях, мы выбрали более 8 правил w + eslint, поддерживаемых фронтенд-командой airbnb. После того как стандарт сформулирован, как члены команды могут быстро адаптироваться к нему?
- Редактор конфигурации: Если вы используете VSCode, вы можете настроить «eslint.autoFixOnSave»: true, чтобы код автоматически исправлялся по правилам eslint при сохранении кода, и ученикам было очень удобно.
- Плагин редактора: если вы используете VSCode, вы можете установить плагин Eslint, который может отображать неправильный код в режиме реального времени.
- Советы по сборке: Если вы используете webpack, вы можете использовать eslint-loader вместе с eslint-friendly-formatter, это может дать разработчикам хорошую подсказку. Вы можете обратиться к этой статьеПодробное объяснение введения eslint в webpack
Таким образом, спецификация eslint изначально приземлилась.
1.3 Исправить код предков
После того, как спецификация настроена и реализована, что мне делать с наследственным кодом? Итак, мы столкнулись с другим голосом:
- Этот код написан не мной: "Кто написал, тот исправит"
- Я не смею измениться: «Как взять на себя вину, если создаешь проблему»
- Измените его в следующий раз: «Я спешу выпустить его, или я изменю его в следующий раз».
- eslint-disable: "disable - это здорово, меня ничто не остановит"
Вот наш путь исправления кода предков: Сначала посмотрите, насколько серьезна проблема:
npx eslint src
1.3.1 Добавьте файл .eslintignore, чтобы исключить сторонние js-файлы
Однако после расследования было обнаружено, что большинство ошибок, о которых здесь сообщается, происходят из сторонних библиотек, но они не являются пакетами npm.Эти файлы часто не соответствуют текущим стандартам кодирования, а некоторые из них были сжаты кодом, и не должен проверяться eslint. После блокировки обнаружения сторонних файлов остальные ошибки eslint по-прежнему имеют 2w+, которые классифицируются как неправильные:
1.3.2 О CRLF
В обработке текста каждая операционная система также имеет свой собственный набор стандартов:
Dos и Windows используют «возврат каретки + перевод строки, CR/LF» для обозначения следующей строки; UNIX/Linux использует «новую строку, LF» для обозначения следующей строки; Macintosh (система MAC OS) использует «возврат каретки, CR» для обозначения следующей строки.
Итак, если в команде есть Windows-плееры, символ новой строки для создания файла — CRLF, что не является большим недостатком, но если вы столкнетесь с игроком Vim или Emacs и откроете файл, вы увидите такую ситуацию:
- Установите разрывы строк IDE, например VSCode:
- Конфигурация VSCode по умолчанию: Файл - Настройки - Настройки - Поиск: символы конца строки по умолчанию. превратиться в
\n - EditorConfig: еще лучше, если в вашем проекте есть EditorConfig:
#Unix-style newlines with a newline ending every file [*] end_of_line = lf insert_final_newline = true
- Настройте git config: вы можете преобразовать код в LF единообразно, когда git commit, тогда вы можете узнать об этом
git config core.autocrlf, возможно вы видели эту конфигурацию, но не обязательно правильно использовали, на самом деле у него есть 3 значения для настройки:
ture: git pull преобразует окончание LF в CRLF false: не выполнять преобразование, когда git pull ввод: git pull преобразует CRLF в LF
Тогда то, что следует использовать здесь, этоgit conifg core.autocrlf inputЛюбой из вышеперечисленных решит вашу проблему с новой строкой.
1.3.3 Автоматический ремонт
После того, как все это будет исправлено, вы можете попробовать разрешить ESLint автоматически исправлять волну:npx eslint src --fix
1.3.4 Регулярное исправление
800+ ошибок распределены по разным страницам.Каждому члену команды можно выделить несколько страниц для исправления и выходить в сеть пачками.Самое главное для такого масштабного исправления - пострелизный мониторинг:
1.4 Раньше я думал, что ESLint — это все
Возможно, вы думаете, что с ESLint все в порядке, если нет ошибки, на самом деле яму часто не так просто найти, как в следующем примере:
绝对路径的引入должно быть написано в相对路径引入перед ним, поэтому он быстро изменил его:1.5 Соблюдайте правила
После того, как мы сформулируем спецификации и исправим код, нужно соблюдать правила, иначе все будет напрасно.
- Git hook: для настройки git hook можно использовать такие инструменты, как pre-commit, husky и т. д. С помощью скрипта npm вы можете выполнить команду eslint перед отправкой кода, чтобы проверить, соответствует ли измененный файл спецификации. В противном случае ненулевое значение выхода завершит коммит git. Однако есть и некоторые недостатки использования git hook на фронтенде: например, каждый раз при отправке кода приходится ждать eslint, что сильно снижает опыт разработки, также бывают случаи, когда некоторые студенты удаляют пре- зафиксировать файл ловушки, чтобы обойти обнаружение; добавить в
--no-verifyотключить обнаружение. - Веб-хук: Преимущество в том, что сервер используется для проверки и его нельзя обойти во внешнем интерфейсе, а недостаток в том, что для этого нужно использовать ресурсы сервера. О том, как построить веб-хук, вы можетеобратитесь к этой статье
1.6 Другие мысли о спецификации внешнего кода
Вышеупомянутое относится к спецификации кода JS, а также может использоваться для CSS.stylelintЧтобы сделать определение спецификации, но это больше касается спецификации формата кода.Если вы хотите написать код хорошо, ESLint и ему подобные не всесильны, например, кодчистый путь, здесь есть много парадигм, на которые можно сослаться, и это именно то, что ESLint не может помочь вам удержать, поэтому ESLint не панацея.
2. Избыточные файлы и код
2.1 О избыточных файлах
Вы можете подумать, что избыточные файлы — это проблема, но они не очень критичны. Даже если вы старый пташка, можно генерировать избыточные файлы.
2.2 Почему создаются избыточные файлы?
В итеративном процессе кода часто легко проигнорировать и удалить соответствующие файлы.Есть два сценария: 1. Удалите требование в коде JS, но забудьте удалить соответствующий файл (img/css/js/и т. д.). 2. Удалите фон в CSS и забудьте удалить соответствующий файл изображения. Удаление кода очень приятно. Пока страница обновляется без ошибок, она чувствует себя о ** к. Накопившиеся избыточные файлы медленно увеличивают все хранилище.
2.3 Очистите лишние файлы
Если вы строите с помощью веб-пакета, вы можете легко проанализировать зависимости всего проекта. Шаг 1: Запустите команду в корневом каталоге и импортируйте зависимости файлов в stats.json.Этот шаг занимает немного больше времени.Я запускал его один раз в проекте, и на 1420 файлов ушло 35 секунд.
webpack --json > ./stats.json
Шаг 2: Используйте glob, чтобы получить все пути к файлам в каталоге:
glob('!(node_modules)/**/*.*')
В сочетании с файлом stats.json, сгенерированным на первом этапе, можно отфильтровать файлы без ссылок.
2.4 Избыточный код
2.4.1 О избыточном CSS
Анализировать избыточный CSS в проекте на самом деле достаточно сложно по трем основным причинам: 1. Вложенность элементов или компонентов страницы: нельзя судить о том, влияет ли стиль на соответствующий элемент только на уровне статического анализа. 2. Глобальная область действия стиля: в .css объявляется стиль, который может воздействовать на любой DOM на странице. Таким образом, необходимо обойти все DOM и CSS в проекте. Необходимо объявление стиля чтобы проверить все DOM.Если есть N объявлений стиля, это будет очень дорого в вычислительном отношении. 3. У CSS нет ограничений: стили нескольких файлов CSS также могут воздействовать на элемент DOM, потому что часто используются библиотеки пользовательского интерфейса с открытым исходным кодом, и соответствующие элементы DOM будут стилизоваться в соответствии с требованиями дизайна, поэтому это слишком гибко. Привносимые им неуправляемые характеристики затрудняют управление.
2.4.2 Разрешение избыточного CSS
CSS ModulesОбласть css может быть объединена, какой стиль класса может быть явно объявлен в dom, и можно гарантировать, что стиль компонента не повлияет на другие компоненты:
2.5.1 О избыточном JS
В итерации кода очень вероятно удаление использования некоторых методов, поэтому в классе останутся некоторые избыточные методы, которые также сложно обнаружить eslint, потому что нет возможности судить о том, будут ли эти методы в классе после создания экземпляра.используется в какой-то момент. Если вы хотите найти эти избыточные методы, вам также необходимо проанализировать все зависимости JS от всего проекта, что потребует больших вычислительных ресурсов и времени.
2.5.2 Попытка разрешить избыточный JS
В настоящее время нет хорошего способа решить эту проблему, возможно, ее можно проанализировать двумя способами: 1. Соглашение об именах: например, если метод, начинающийся со знака подчеркивания, является закрытым методом, вы можете только проанализировать, используются ли все частные методы в этом файле. 2. Разметка комментария. Если вам не нравится способ подчеркивания, вы также можете рассмотреть возможность добавления комментария, чтобы пометить его.
2.6 Избыточные файлы/код. Резюме
1. Будьте осторожны при удалении кода 2. Анализ избыточности 3. Используйте инструменты разумно 4. Пострелизный мониторинг