Чтобы представить вещи в контексте, программная инженерия вращается вокруг определенных принципов проектирования / структуры. Которые помогают в управлении всем в целом качеством кода базы кода. Это очень важно при работе в команде. Размер команды пропорционален потребности в таких принципах.
У нас есть набор шаблонов проектирования, каждый из которых заботится о «разделении проблем» в зависимости от того, что должен делать конкретный шаблон. Но мы не должны забывать, что намерение начинается с единственной строчки кода ⊆ function.
Чтобы сразу понять некоторые вещи:
- Причина, по которой мы хотим следовать этим принципам, заключается в том, что каждый инженер, независимо от алгоритмов, которые они реализуют, должен следовать некоторым шаблонам, упрощающим читаемость и понимание целей (обзоры PR также становятся более простым процессом 💪).
- Это ни в коем случае не является необходимым, но такие «проверки» поддерживают стандарт кода на должном уровне, и после того, как соглашение о коде закреплено после пары итераций, такие методы упрощают подключение разработчиков, а также повышают скорость разработки, поскольку мы видим похожие шаблоны. вокруг.
В рабочем пространстве VSCode можно использовать несколько расширений, которые помогут в поддержании таких шаблонов и упростят прохождение этих «душераздирающих» конвейерных тестов еще до создания запроса на вытягивание.
Метрики кода помогают разбить функцию или класс на более читаемую и менее сложную в когнитивном отношении структуру, предупреждая нас в случае, если мы неосознанно добавляем довольно много работы в одну функцию. Этот плагин рассматривает определенные логические структуры как сложные и помогает сделать функцию как можно более компактной. Один раз можно сказать, что это заставляет разработчика больше думать о single responsibility principle.
Я упомянул действия конвейера, например, под этим я имел в виду такой инструмент CI, как
Климат кода помогает установить определенные правила в .codeclimate.yml файле конфигурации, где команда / организация может настроить базу кода для выполнения определенных правил, таких как file-length, cognitive-complexity, function-line и т. Д. Конечно, это необходимо использовать в судебном порядке в определенных местах, например, в исходном коде приложения. папку, а не в миграциях, спецификациях и исходных скриптах. Поскольку цель состоит в том, чтобы убедиться, что исходная папка находится на должном уровне, и любой (новый / опытный) может войти и закодировать функцию, придерживаясь конфигураций.
Цель состоит в том, чтобы уменьшить перегрузку ответственности в одном блоке кода и сделать его более читабельным путем его разделения. Чем читабельнее код, тем лучше он понимает стоящее за ним намерение. Это помогает с масштабируемостью, скоростью и дает лучшее представление о потоке данных.
Это расширение linter берет ваш локальный .codeclimate.yml файл и дает вам представление о том, почему инструменты конвейера дают сбой. Они также дают возможность использовать интерфейс командной строки, но расширение намного легче.
Если вы хотите больше узнать о спецификациях линтеров и кодовом климате в целом, ссылка ниже - это блог, который углубляется в это.
«Https://maddevs.io/blog/code-climate-code-analysis-locally-using-vscode-remote-containers кад/
В этом блоге размером в байт я пришел к выводу, что эти два расширения очень помогли мне и моей очень поддерживающей команде не только улучшить качество кода и читаемость, но и улучшить как инженеров-программистов. В качестве побочного продукта мы находимся на пути к тому, чтобы кодовая база лучше подходила для большего числа новых супергероев программного обеспечения.
До следующего раза, до свидания
