Мысль: если бы вас попросили составить спецификацию отправки кода (инструмент Git), что бы вы сделали?

игнорируемые детали

Информация о представлении кода — это очень мелкая деталь в разработке, так как она не оказывает никакого влияния на саму работу кода, основная функция — облегчить поиск и откат кода, поэтому легко игнорируется разработчиками. Но ее значение подобно проектной документации и комментариям, которые необходимы для качественных проектов.Хорошая представляемая информация может не только помочь разработчикам быстро найти код указанной версии, но и отразить привычки и осведомленность разработчиков.

В этой статье мы хотим поговорить с вами об этой небольшой детали и выращивании инженеров-программистов (далее — инженеров), которые могут дать тем, ктоВыход на работу впервые или в трудный период карьерного ростанемного вдохновения для читателей.

Информация о представлении кода нашего текущего проекта довольно беспорядочна, поэтому необходимо установить спецификацию представления кода.

Давайте поговорим о самосовершенствовании на работе с помощью трех разных инженеров.

генеральный инженер

Если вы не выполняли подобную работу, первое, что нужно сделать, получив задание, — это открыть браузер и выполнить поиск по ключевым словам, таким как «спецификация представления кода», и вы найдете множество релевантных результатов. После некоторой сортировки получается следующая информация:

Формат подачи информации

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

type：提交类型，可选值如下
* work: 开发中(work in progress)
* feature：新功能(new feature)
* fix：修补bug(fix bug)
* doc：文档(documentation changes)
* style： 格式(change code format)
* refactor：重构(modify code but not feature)
* test：增加测试(test code)
* chore：构建过程或辅助工具的变动(changes don't modify src and test files, only config or tasks)
scope：
用于说明 commit影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
subject：commit 目的的简短描述。
body: 对本次 commit 的详细描述
footer: 描述一些特殊情况，不兼容变动和issue关闭。

Инструменты для написания сообщений фиксации

НапримерCommitizen, основная операция выглядит следующим образом:

# 安装命令行工具
npm install -g commitizen

# 安装依赖
commitizen init cz-conventional-changelog --save --save-exact

# 通过扩展命令提交
git add .
git cz

Организуйте вышеуказанный формат записи в документ, затем установите зависимости в проекте и попробуйте следующее, задача выполнена ~

Думай дальше

Но это всего лишь стандарт для обычных инженеров, а как должны мыслить отличные инженеры?

Отличие хорошего инженера от обычного инженера в том, чтоДумайте о работе и активно совершенствуйтесь. то естьНе только удовлетворен тем, что все сделано, но и проявляет инициативу, чтобы добиться цели.Есть примерно два способа что-то сделать:

Все остальные могут это сделать, но вы можете сделать это по-другому.
Вы можете делать то, что никто другой не может.

Очевидно, что создание спецификации коммита относится к первому случаю, поэтому хорошие инженеры думают дальше.

Отличный инженер

Есть ли что-то, что можно улучшить в текущей программе?

формат записи

На каждую подачу информации приходится писать много контента, и если каждый раз подавать код так же хлопотно, как написать небольшую композицию, то это неизбежно вызовет отвращение. Это все равно, что ехать на работу менее получаса, но теперь для поездки на велосипеде требуется всего один час для путешествия с низким уровнем выбросов углерода, поэтому осуществимость такого регулирования очень низка. Так сжато:

Если путь к файлу длинный или количество файлов велико, область действия станет очень длинной, что повлияет на просмотр объекта. И измененное имя файла (папки) также можно найти при запросе определенных записей отправки. Что более хлопотно, так это то, что будет контрпродуктивно, если вы пропустите или напишете его неправильно при отправке, поэтому он будет опущен.
И тело, и нижний колонтитул относятся к подробному описанию коммита, объединенному в необязательное описание.

инструмент отправки

git czКоманды могут быть заменены, хотяgit commitкоманда для фиксации кода, но она не используется инженерамиgit czвсе еще используяgit commitотправить код, проверка будет недействительной. Поэтому для обеспечения эффективной реализации наших спецификаций необходим инструмент проверки, а что касается инструмента git, то он для нас уже подготовлен — хуки. Хуки аналогичны жизненному циклу веб-компонентов, которые могут запускать соответствующие сценарии оболочки до и после выполнения определенных операций. иgit commitЕсть 4 хука, связанные с командами, по порядку:

предварительная фиксация. Запускается перед отправкой, не получает параметров и может выполнять некоторые действия по проверке файла.
подготовка-фиксация-сообщение. Запускается перед отправкой, получает параметры сообщения, используемые для добавления содержимого перед отправкой.
сообщение фиксации. Запущенный перед отправкой, он может получать параметры сообщения, чтобы проверить, соответствует ли сообщение отправки спецификации.
после фиксации. Запускается после отправки и может выполнять такие операции, как автоматическая отправка и развертывание кода.

Здесь мы выбираемcommit-msgДля этого соответствующий скрипт будет выглядеть следующим образом:

#!/bin/sh

if grep -Eq "^(work|feature|fix|refactor|doc|test|chore|style|revert):\s*\w+" "$1"; then
  exit 0
else
  echo "Please format your commit message as follow:"
  echo "<type>:<title>"
  echo "<description>(optional)"
  exit 1
fi

Есть ли что-то, что можно добавить к текущему плану?

формировать норму

Норма подобна системе.Хорошая система требует не только дизайна создателей, но также знаний и сотрудничества исполнителей. Итак, еще одна вещь, о которой следует подумать, когда у вас есть документация и инструменты, — это продвигать их в команде. Наиболее распространенные способы продвижения — это проведение PPT-совещаний и тренингов или размещение информации на вики команды, чтобы напомнить всем проверить ее, поэтому я не буду здесь вдаваться в подробности.

на шаг впереди

В этот момент задание не только выполнено, но и считается выполненным. Но для достижения наибольшего личного совершенствования одного совершенства недостаточно, оно должно быть превосходным. такВ дополнение к тому, чтобы добиться цели, вы также должны подумать о том, чтобы максимизировать ее ценность.

Выдающийся инженер

Возвращаясь к примеру, возможно ли это решение для других команд/сценариев?

общность

Проблем с написанием формата в принципе нет, а вот инструмент отправки может стать большой помехой. Node.js обычно является просто инструментом для фронтенд-команд. Если его будут продвигать и использовать в других командах, стоимость обучения не будет упомянута, а в проект будут внесены дополнительные зависимости, да и работоспособность несильна.

Нужно ли искать подходящие решения для проектов на других языках разработки? Это, безусловно, возможно, но не обязательно лучший способ, поскольку затраты времени слишком высоки, лучший способ - найти общее решение.

или крючок

На самом деле, git уже предоставил нам это решение, и это тот хук, который мы использовали раньше. Несмотря на то чтоcommitizenЭтот тип модуля Node.js не является межъязыковым решением, но он использует интерактивный способ пошагового предоставления подсказок, а затем ввода данных пользователем, что лучше для людей, не знакомых со спецификацией. Таким образом, мы можем использовать эту форму в скрипте хука.

Но разработчики, знакомые со спецификацией, могут захотеть напрямую использоватьgit commitКоманда отправляется за один раз, поэтому также добавляются некоторые проверки — выдаются интерактивные подсказки для отправки информации, которая не соответствует спецификации, и разработчикам предлагается заполнить информацию для отправки поэтапно. Из-за длинного содержания сценария он не будет размещен здесь, заинтересованные читатели могут перейти по адресу склада в конце статьи, чтобы просмотреть его.

Полный

Если вы хотите сделать его более совершенным, вы можете использовать функцию шаблона, предоставляемую git.Для конкретного использования вы можете проверить адрес склада, указанный в конце статьи.

Суммировать

Отношение к работе определяет потенциал инженера, а размерность мышления определяет потолок способностей инженера (конечно, это предложение может использоваться и в других позициях).

Хотя разработать спецификацию коммита несложно, можно сделать вывод, что различия между инженерами разных уровней в этих двух аспектах:

	генеральный инженер	Отличный инженер	Выдающийся инженер
отношение к работе	Что компания организует делать и учиться, отсутствие инициативы.	Может выполнять поставленные компанией задачи, иногда превосходя ожидания, и использовать время для учебы после работы.	Может не только часто превосходить ожидания по выполнению задач компании, но и активно думать о существующих проблемах команды, продукта или областей, которые можно улучшить, и ставить задачи самим себе
измерение мышления	одиночные, точечные. Сосредоточьтесь только на самой задаче, только подумайте, как выполнить задачу	Линейный, вертикальный. Подумайте о цели, стоящей за задачей, и о том, как лучше достичь цели, а не просто выполнить задачу.	Сетка, глобальная. Переключите мышление на идентичность, чтобы максимизировать ценность результатов миссии для организации.

Если вы считаете, что эта статья была вам полезна, ставьте лайк, спасибо за прочтение~

Справочная статья:

«Хук, вызванный git commit»
"Сообщение фиксации и руководство по написанию журнала изменений"

Укажите канонический адрес склада:GitHub.com/Pressure обречено…

моя новая книга«Удивительный инженер JavaScript: от Front-End до Full-End Advanced»Он был поставлен на полки и был рекомендован многими техническими экспертами, такими как г-н Руан Ифэн, Я надеюсь помочь большему количеству фронтенд-инженеров расти и совершенствоваться вместе, с обширными возможностями и глобальным видением, и стать великим инженером JavaScript!