Ничего сложного в выполнении, много чего можно выиграть после того, как сделано.

Платформа управления исходным кодом довольно распространена почти в каждой компании. Я начал работать с SVN, а с Git познакомился в первые годы существования. Благодаря своему опыту я узнал, как работает процесс совместной работы (и все еще учусь), и здесь я поделюсь некоторыми идеями по улучшению ваших запросов на вытягивание, независимо от того, работаете ли вы с GitHub, GitLab, BitBucket или любым другим Git. инструмент менеджера.

Совершайте раньше, совершайте чаще

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

Комментируйте, что делает код, а не то, что сделали вы

Для каждого создаваемого вами коммита вы должны написать осмысленные комментарии, чтобы показать другим разработчикам в вашей команде статус кода. Хитрость заключается в том, чтобы писать о том, что код делает сейчас, а не о том, что сделали вы, например:

Вы добавили новую библиотеку, чтобы начать писать интеграционные тесты, допустим, RestAssured. Теперь, если вы напишите, что вы сделали, будет что-то вроде:

git commit -m ‘Added RestAssure lib’

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

git commit -m ‘App uses now RestAssure to perform int tests’

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

Обзоры кода — ключ к улучшению конечного продукта

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

Избегайте больших запросов на включение

Это очень распространено, когда вы работаете в совместной среде. Мы уже знаем о важности правильной проверки кода, но теперь мы также должны сделать этот процесс проще и эффективнее. Рецензент должен уметь читать код и обнаруживать связь, которую он имеет между всеми измененными файлами, поэтому теперь представьте, что вы пытаетесь создать эту абстракцию в своей голове с более чем 15 измененными файлами. Вам не нужно вносить все изменения в один PR, вместо этого разделение функции на небольшие обновления кода поможет улучшить процесс рецензирования и уменьшить количество конфликтов кода, когда ваши коллеги вносят свои изменения (представьте, что вы решаете конфликт с более 10 файлов). Если вы изменяете существующую функциональность, рассмотрите возможность использования флагов функций, чтобы не сломать текущую, а затем после завершения и тестирования снимите флаг и отпустите его.

Пишите осмысленные PR-описания

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

  • В чем цель пиара
  • Как это было протестировано
  • Другие наблюдения

Например, в случае нашего добавленного интеграционного теста, если у нас уже есть завершенный PR, мы могли бы написать что-то вроде этого в описании PR:

What's the PR purpose
Add integration tests using RestAssured to improve the code quality. This PR includes an example about how to start writing int test for the other services.
How it was tested?
Once the dependency is downloaded, execute the command `make test:int` to run the integration test example. You should see the success message with the expected output.
Other observations
This PR is only considering one service as an example, we need to create integration tests for the other services.

Теперь рецензент будет знать весь контекст относительно PR, и обратная связь, которую вы могли бы получить, будет лучше.

Как видите, написание кода больше связано с сообщением людям о том, что делает код, а не с тем, чтобы просто давать инструкции компьютеру. Следуя этим 5 пунктам, вы улучшите процесс совместной работы в своей команде, потому что эволюция кода более прослеживаема и будет полезна вам, вашим товарищам по команде и будущим разработчикам, присоединяющимся к компании.