Стандартные коммиты не спасут ваши сообщения коммитов
Исследуем, почему простого следования стандартам коммитов недостаточно для написания хороших сообщений коммитов, и представляем ключевые стратегии мышления для улучшения вашего процесса разработки и естественного создания значимых коммитов.
YijunDeveloper
Хватит тратить недели на аутентификацию пользователей
Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.
Быстрый поиск в интернете покажет множество статей о том, как писать сообщения коммитов. 90% из этих статей говорят вам использовать стандартные коммиты. Однако значительное число разработчиков все еще испытывают трудности с этим. Они знают, что должны следовать этим стандартам, но им трудно применять их на практике. Каждый раз, когда они коммитят код, они мучаются, писать ли "рефакторинг" или "задание". Я даже видел проекты, где список сообщений коммитов состоит исключительно из одного и того же сообщения: "фича: добавить страницу", потому что написание сообщений коммитов было для них слишком сложным, и они просто сдались.
Я не говорю, что стандартные коммиты плохие. У них много известных преимуществ:
Они обеспечивают единый формат, делая сообщения коммитов более стандартизированными
Они удобны для парсинга автоматическими инструментами, обеспечивая автоматическое создание журналов изменений
Они помогают членам команды понять цель и объем изменений в коде
Они позволяют быстро идентифицировать различные типы изменений в коде
Однако, когда разработчик все еще испытывает трудности с написанием хороших сообщений коммитов даже после использования стандартных коммитов, давать ему статью о том, как использовать стандартные коммиты, учить его, что значит тип фича, что значит тип починка, на самом деле бессмысленно. Это как дать продвинутую кулинарную книгу тому, кто не умеет готовить, не научив его пользоваться основными ингредиентами и инструментами. Тем не менее, такие статьи повсюду в интернете. Мало кто понимает, что стандартные коммиты могут быть действительно эффективными, только когда у разработчиков есть четкое мышление и способность точно делить задачи.
Поэтому стандартные коммиты не плохи, но прежде чем дойти до них, нам нужно установить правильный подход к разработке и использовать научное мышление разработчика.
Ключевое мышление для написания хороших сообщений коммитов#
В разработке программного обеспечения "делать одну вещь за раз" — важный принцип. Это применимо не только к написанию кода, но и к коммиту кода. Когда мы сосредотачиваемся на одной конкретной задаче или изменении за раз, наш код становится более ясным, а намерения — более явными. Этот метод не только улучшает читаемость кода, но и значительно упрощает процесс ревью кода. Рецензенты могут легче понимать и проверять цель каждого изменения.
Кроме того, этот метод предоставляет удобство для возможных откатов кода. Если возникают проблемы, мы можем легче найти и откатить конкретные изменения, не затрагивая другие несвязанные части. Самое главное, когда каждое изменение делает только одну вещь, сообщение коммита, описывающее это изменение, естественно, становится более точным и значимым.
На практике это означает, что мы должны ясно определить задачу, которую нужно выполнить, до начала кодирования. После выполнения задачи мы должны незамедлительно сделать коммит кода, а не ждать, пока будут завершены несколько задач, и сделать их все сразу. Если мы обнаружим другие области, требующие изменения во время выполнения текущей задачи, лучший подход — записать их и заняться ими отдельно после завершения текущей задачи. Например, когда вы реализуете функцию и обнаруживаете некоторые существующие ошибки, что вы должны сделать, так это не исправлять ошибку прямо сейчас вместе с вашим новым кодом функции, а сначала реализовать функцию, затем исправить ошибку, которую вы обнаружили, в другом коммите, или сначала исправить ошибку, а затем закоммитить функцию.
Сообщения коммитов фактически существуют до написания кода#
Многие разработчики начинают думать о том, как писать сообщения коммитов после завершения кода, но на самом деле сообщения коммитов должны существовать до начала кодирования. Это потому, что сообщения коммитов по сути отражают шаги, которые мы выполняем для завершения задачи. Другими словами, это наши список дел.
Когда мы начинаем задачу, мы должны сначала подумать о том, какие конкретные шаги необходимы для выполнения этой задачи. Эти шаги — наш список дел, и в то же время это наши будущие сообщения коммитов. С этим списком дел, каждое из наших изменений в коде имеет цель, удерживая нас сосредоточенными во время кодирования и предотвращая отклонения от задачи.
Более важно, что этот метод может значительно улучшить нашу эффективность. Когда мы завершаем шаг, соответствующее сообщение коммита уже подготовлено, и мы можем использовать его напрямую, сокращая время, затраченное на размышления о том, как описать изменение. В то же время, поскольку эти сообщения коммитов созданы, когда у нас уже есть полное понимание задачи, они обычно более высокого качества и информативные.
Предположим, вам нужно реализовать новую функцию регистрации пользователей. Вы можете планировать шаги вашей задачи следующим образом:
Рефакторинг существующего компонента формы для большей общности и повторного использования
Создание формы регистрации пользователя
Реализация интеграции API для регистрации пользователя
Добавление модульных тестов для функции регистрации пользователя
Обновление документации для функции регистрации пользователя
Сообщения коммитов, соответствующие этим шагам задачи, могут быть следующими:
рефакторинг: улучшить существующий компонент формы для повторного использования
фича: создать форму регистрации пользователя
фича: реализовать интеграцию API для регистрации пользователя
тест: добавить модульные тесты для регистрации пользователя
док: обновить документацию для функции регистрации пользователя
Таким образом, у вас есть четкие шаги задачи и соответствующие краткие сообщения коммитов перед началом кодирования. Эти сообщения коммитов на самом деле ваш список дел, направляющий вас через весь процесс реализации функции.
Когда вы завершаете каждый шаг, вы можете использовать соответствующее сообщение коммита, чтобы закоммитить ваш код. Это не только помогает вам лучше организовывать и выполнять задачи, но и обеспечивает, что каждый коммит фокусируется на конкретном шаге, делая весь процесс разработки более ясным и управляемым. Если вам нужно слегка подправить сообщение коммита во время реального кодирования, вы можете внести незначительные изменения, чтобы точнее описать фактические изменения.
Стандартные коммиты становятся естественным выбором#
Когда мы развиваем правильное мышление для разработки, использование стандартных коммитов становится естественным. На этом этапе вы обнаружите, что выбор соответствующего префикса типа (например, фича, починка, рефакторинг и т. д.) становится легким, потому что ваши сообщения коммитов уже явно отражают ваши шаги задачи.
Если вы хотите узнать больше о том, как использовать стандартные коммиты, в интернете есть множество отличных статей. Но помните, что эти стандарты могут быть действительно эффективными только при наличии правильного мышления для разработки.
Написание хороших сообщений коммитов — это не просто следование определенному формату. Это требует от нас сохранять ясное мышление во время процесса разработки, четко представлять цель каждого изменения и обдумывать, как описать нашу работу до начала кодирования.
Стандартные коммиты действительно полезный инструмент, но они могут оказать максимальный эффект только в сочетании с правильным мышлением для разработки. Практикуя два принципа "делать одну вещь за раз" и "думать о сообщениях коммитов заранее", мы можем не только улучшить качество сообщений коммитов, но и повысить общую эффективность разработок и качество кода.
Я надеюсь, что эта статья поможет вам переосмыслить ваш процесс разработки и побудит вас попробовать эти методы. Помните, что хорошие привычки в разработке требуют времени на формирование, но когда они формируются, они значительно улучшают вашу рабочую эффективность и качество кода.
