若不碎我，必逆境生花
содержание
- Угол проекта
- угол формата
- кодовый угол
- Git угол
- угол редактора
предисловие
相信大家都有过这种情况，接盘。没错，你不知道在你面前放着的代码经过几个人的手，里面有几种风格。我见过一个项目，7、8个人接手过，轮到我接手的时候先吐了半个小时。在中大型项目中，这是一种常态，我通常称此类项目为shi山。那么我们怎么才能把项目code质量这一块，掌控的死死的呢？代码的健壮性如何增强？
мой последний пост«Внешняя биржа оптимизации производительности»Рассказали об оптимизации производительности проекта в процессе разработки проекта. Эта статья основана на идее оптимизации, контроля качества и надежности кода.
1. Перспектива проекта
搭建框架，定制技术
1. Unified Framework - унифицированные технические средства
Если вы работаете над средним или крупным проектом или моделью командной разработки, это должно быть основным принципом.На этапе просмотра документа с требованиями вы поймете примерную суть бизнеса и технические трудности в проекте, а затем передовые студенты в проекте будут исследовать технологию унифицированным образом.
Однако, почему вы это придумали?Я видел довольно много, которые не следуют этому стандарту.
Пример 1: поскольку js с открытым исходным кодом не может быть найден
react 项目引用 jquery （貌似是为了引用一个jq拖拽插件）
Об этом особо нечего сказать, такой ситуации вообще быть не должно, мы должны больше обсуждать, исследовать больше решений и расширять наши решения для различных бизнесов.
Мы рекомендуем вам порекомендовать веб-сайт для поиска технологических библиотек, а также узнать о последних и самых популярных технологических библиотеках в рейтинговом списке.
Пример 2: компоненты пользовательского интерфейса не соответствуют требованиям проекта
项目中运用两种UI框架，antd、antd-mobile
Когда UI-компоненты не соответствуют требованиям проекта, внедрить два UI-фреймворка однозначно невозможно, и нагрузка на проект становится слишком большой.
Я рекомендую, чтобы каждый проект сначала рисовал свою собственную библиотеку компонентов пользовательского интерфейса, собирал частную библиотеку npm компании, а затем компоненты в проекте, который делает каждый, могли бы обосноваться и построить свою собственную библиотеку npm, которая может не только иметь компоненты пользовательского интерфейса, бизнес-компоненты, строительные леса и т. д.
Во-вторых, угол формата
1. эслинт (ворс: марля для перевязки ран)
Важный шаг в спецификации кода js. Поскольку javascript — слабый язык, он гибкий и имеет широкий набор правил. Поэтому часто возникает проблема «как ни пиши», а стиль кодирования у всех разный. Например: смешивание табуляции и пробела, использование устаревших методов и т. д.
Если вы настроили eslint, я собрал здесь некоторые свойства конфигурации, вы можете сопоставить некоторые спецификации, необходимые в проекте:
Я делюсь файлом конфигурации eslint в моем проекте здесь. Вставьте его в свой проект и используйте напрямую.
2. стайлинг
stylelint — это то же самое, что и eslint, но набор спецификаций для css.
Портал:Краткое введение в stylelint
Статьи на портале объясняются более подробно, поэтому я не буду вдаваться в подробности.
В-третьих, угол кода
- именование переменных
Это очень простой момент, а также самый меланхоличный момент для многих людей Слишком сложно давать имена переменным.
Аспекты клишированного формата:
骆驼式命名法（Camel-Case）又称驼峰式命名法，是电脑程式编写时的一套命名规则（惯例）。正如它的名称CamelCase所表示的那样，是指混合使用大小写字母来构成变量和函数的名字。程序员们为了自己的代码能更容易的在同行之间交流，所以多采取统一的可读性比较好的命名方式。
CamelCase Само собой разумеется, это самое основное соглашение об именах.
После этого проблема
很多业务词语我不知道英文怎么拼怎么办？
Объедините одну и ту же платформу перевода. Справедливости ради, Google Translate и Baidu Translate не обязательно переводят одно и то же слово.
После этого проблема повторилась.
变量名拼接过长，按什么顺序拼？
Я также видел способ думать об этом вопросе некоторое время назад, согласно учебнику английского языка. Единая английская грамматика, глаголы, существительные, прилагательные. Грамматика английского предложения обведена кружком, чтобы сосредоточиться на тесте.
比如说有个方法叫“坐火车去拉萨的途中做一些事情”，我认为正确的：onTheWayToLhasaByTrainDoSomeThing()，常见的写法：ByTrainToLhasaOnTheWayDoSomeThing() -- 途中坐火车去拉萨做一些事情。语法还是要注意一下的，否则上面这就变成两个方法了
1. Доработка компонентов
1. Компонент не превышает 250 строк
Часто видно, что, когда компонент в проекте открывается, существует 1000+ строк, а ремонтопригодность и наследие очень плохая. В большинстве случаев (некоммерческие потребности) компоненты с более чем 250 рядами могут быть разделены на более мелкие компоненты для обслуживания. Когда вы демонтировали все компоненты, вы будете демонтировать множество чистых компонентов компонентов, которые не смешиваются с бизнесом. Это абстрактное извлечение общих компонентов, и вы обнаружите, что существует много общих компонентов, которые могут быть извлечены.
2, оптимизация глобального загрязнения стиля
Когда компоненты достаточно абстрактны и достаточно разделены, обратите внимание на проблему загрязнения стиля.Большинство проектов, с которыми я связался, идут непосредственно к хешу стиля, но здесь рекомендуется плагин имен классов, а бизнес-сплайсинг однозначно идентифицируется перед className, что лучше, чем использование хэша напрямую.Отладка, и каждый компонент не будет перепутан, даже если формат тот же, и className назван так же.
Как использовать:
npm i classnames --save
установить общедоступный метод
3. Оптимизация времени рендеринга
Я в этом вопросе«Поговорите со всеми о том, как оптимизировать производительность внешнего интерфейса»Упоминается в этой статье, в оглавлении IV-2.
Решение проблемы состоит в разумном запуске рендеринга.
2. Абстракция данных — логическое разделение
Эти два слова несколько официальны и, вероятно, означают «снос». После демонтажа и последующего слияния.
Как было сказано выше, при абстрагировании компонента мы оговариваем около 250 строк. Метод настраивается в строке 100. Я считаю, что каждый всегда будет видеть множество огромных методов.Если внимательно проанализировать этот метод, то он должен быть перемешан с бизнесом, и он не выдерживает раздельной логики и бизнеса, так что даже если вы напишете заметку, этот метод приведет на все тело. , После устранения одной проблемы остается 10 проблем, что очень страшно.
Поэтому мы оговариваем, что метод не должен превышать 100 строк.Если ваш метод превышает 100 строк, это означает, что его можно разбить на две или более меньшие логические комбинации.
Это называется логической развязкой. После того, как мы его разберем, мы обнаружим, что большая часть логики на самом деле одинакова. В это время мы можем абстрагировать данные, извлекать общедоступные методы, помещать их в библиотеки общедоступных методов, писать заметки и использовать документы. . Мы вполне можем осуществлять дальнейшее обслуживание, наследование, модификацию и так далее. Давным-давно я поместил эту библиотеку методов на диск U и ношу ее с собой...
Ключевой момент здесь: jsinspect, абстракция компонентов и логическая абстракция, описанные выше, могут быть организованы с помощью этого плагина.После установки пути проверки будет напрямую сгенерирован список файлов, сообщающий вам, где и где сходства могут быть абстрагированы, который очень прост в использовании.
3. попробуй поймай
Очень важные детали, мы часто говорим, что детали утеряны, верно? все внимательно смотрите
如果接口返回statusCode异常，可以在你的ajax层拦截掉，如果statusCode 200ok，但是接口返回数据异常，那就gg了。为什么呢？如果你需要一个array，后台突然返回了个object，极大多数都会触发js错误，界面直接崩掉之后展示js错误信息。
Такого рода ситуации в проекте недопустимы, даже если сервер взорвет страницу переднего плана, должна быть всплывающая подсказка «Сервер взорвался, пожалуйста, не забудьте прочитать завтра газету». Правильно, тогда мы молча позволяем пользователю выйти из системы. Итак, где наша попытка поймать здесь?
Если все промисы снабжены попыткой перехвата, проблем не возникает, кроме проблем и причин.
promise(() => {}).then(res => { try { res... } catch { ... } })
Однако здесь всегда есть небольшая загвоздка, мы можем поставить этот метод захвата js ошибок на входе, да, роутинг. Проекты одностраничного приложения заключаются в том, чтобы вставить маршрут в одностраничный узел и попытаться поймать во внешнем слое вставленного метода раз и навсегда.
4. Все узлы должны иметь уникальный идентификационный ключ
Это также очень важно.Теперь, независимо от того, реагируют ли, vue или angular, все они являются режимами разработки на основе компонентов.В этом режиме основным принципом является алгоритм сравнения, который строит виртуальное дерево, которое используется для определения, какие компоненты перерисовываются и какие перерисовываются.Не нужно перерисовывать.
Ключи для обычных элементов DOM генерируются автоматически. Однако когда возникнет проблема? Например
我需要渲染一万条数据，后台没返回唯一识别id，用角标代替
Тогда: если ключ уникален
5. Красивее
Этот плагин используется для форматирования кода, так что, даже если код имеет беспорядочный формат во время разработки, правильно, скомпилируйте его, и он станет унифицированным форматом. Очень подходит для командной разработки.
这个时候有些同学可能会有个疑问，我的开发工具，比如vscode，可以下载开发工具插件，如图。
开发工具中也可以装一些插件辅助你开发，但是这个，只能辅助你自己，如果你的同事没有装，或者装了跟你配置的不一样，那么就非常不理想了，所以说，还是在项目中配置eslint，prettier等规范为上策。
В-четвертых, точка зрения Git
1. Предварительная фиксация
通过git precommit钩子，每个人在上传代码的时候做一层拦截，保证上传到gitlab上的代码质量。
Тут особо нечего сказать, все поймут после прочтения конфигурации package.json
Просто следуйте моей конфигурации и просматривайте вышеупомянутые eslint, stylelint, prettier и другие спецификации каждый раз, когда вы загружаете код. Конечно, вы также можете настроить некоторые операции.
2. мерж-реквест
Заблокируйте ветку master.Когда остальную часть кода нужно слить в master, вам нужно отправить запрос на слияние, а затем провести проверку кода.По крайней мере, два человека могут слить код в master-ветку после обзор. Наши масштабные проекты в этом режиме очень строгие. Вы также можете научиться писать и обсуждать идеи друг у друга.Эта функция поставляется с gitlab, просто настройте ее, и вы можете узнать об этом, если вам это нужно.
5. Угол редактора
这一点来说，项目中可以统一开发工具的配置，文件名为.editorconfig的根目录配置。
Мы можем унифицировать среду конфигурации инструментов разработки через файл .editorcofig.Даже если ваши коллеги используют возвышенное, используемый вами vscode не повлияет на стиль кода, правила и другие вопросы.
Я также даю файл конфигурации прямо здесь.
END
上周很忙，手里同时三个项目，真是在抽时间写文章，写文章真的没那么简单，对于一些东西的串联的时候才发现自己不足的地方很多，多谢各位包容，如果有错误欢迎大家指出。这周的任务虽然还是很紧，我还是会完成我的承诺。不辜负我的28个关注人。我去改bug了，下次见。
Напишу 4 статьи до конца марта соответственно
«Внешняя биржа оптимизации производительности»
«Сообщение об оптимизации качества внешнего кода» (эта статья)
«Мониторинг внешнего кода и связь»
«Обмен вопросами внешней безопасности»
Осадить некоторые знания о процессе разработки в прошлом году. Спасибо.