Добро пожаловать в третью статью из моей серии об управлении стрессом в индустрии программного обеспечения. В этой статье мы более подробно рассмотрим подходы, ошибки и лучшие практики для снижения стресса в виде пулл-реквестов через призму рецензента.
Как инженер-программист, я считаю, что преодоление стресса имеет решающее значение для успешной карьеры, и я намерен продолжать это исследование.
Процесс проверки запроса на вытягивание (PR) должен быть совместным и конструктивным опытом, но, к сожалению, это не всегда так. Когда PR подвергается неэтичной проверке, уровень стресса у отправившего его человека может резко возрасти.
Вместо того, чтобы быть поддерживающим и полезным опытом, неэтичные обзоры часто включают личные нападки, необоснованную критику и необоснованные требования, которые могут быть невероятно обескураживающими и подавляющими. Подобные обзоры могут вызвать у людей чувство разочарования, разочарования и стресса, что может оказать длительное влияние на их уверенность, мотивацию и общее самочувствие.
Важность подготовки: стратегии для беззаботного процесса рассмотрения запроса на включение
Важно не только сосредоточиться на процессе проверки с точки зрения рецензента, но и на шагах, которые инженеры могут предпринять перед отправкой запроса на включение (PR). Как инженеры, мы можем подготовить почву для гладкого и конструктивного процесса проверки, и время, потраченное на подготовку, может помочь уменьшить стресс и гарантировать, что наш PR будет воспринят в лучшем свете.
Принимая упреждающие меры, такие как тщательное тестирование нашего кода, четкое документирование наших изменений и получение отзывов от коллег, мы можем помочь задать тон для положительного и продуктивного обзора.
Помните, что хорошо подготовленный PR может не только уменьшить стресс, но также может привести к лучшим результатам и более быстрому разрешению проблем. Итак, давайте возьмем все под контроль и максимально используем этот важный шаг в процессе разработки программного обеспечения.
Тестирование перед отправкой PR
Я всегда советую членам моей команды провести тесты перед отправкой PR. Почему? Тестирование — неотъемлемая часть процесса подготовки пулл-реквеста (PR), на которую следует обратить внимание. Даже если у вас есть специальная группа контроля качества, тщательное тестирование кода перед отправкой имеет решающее значение.
В конце концов, конечной целью является обеспечение того, чтобы ваш код работал на вашей машине так же, как и на целевой машине развертывания. Оценивая свою задачу, не стесняйтесь включать это время в общее время выполнения.
В результате вы можете помочь свести к минимуму потенциальные проблемы в процессе проверки и обеспечить себе душевное спокойствие, тщательно протестировав свой код. Этот процесс может повлечь за собой запуск тестов на вашем компьютере, выполнение небольших целевых тестов после развертывания или даже привлечение помощи ваших коллег для проведения тщательной проверки.
Помните, что адекватное тестирование вашего кода может помочь предотвратить стресс и разочарование в дальнейшем и сделать процесс проверки более плавным и эффективным. Итак, воспользуйтесь этим важным шагом и тщательно протестируйте свой код перед отправкой PR.
Подготовьте четкую PR-документацию
Второе, что инженеры могут сделать перед отправкой PR, — предоставить четкую документацию. Это ключевой момент, когда речь идет об обеспечении плавного и беззаботного процесса проверки. При отправке запроса на включение (PR) важно не только иметь хорошо задокументированный код, но и включать сопроводительную документацию, объясняющую внесенные вами изменения.
С помощью документации вы поможете рецензентам понять цель и логику вашего кода. Это не только облегчает их работу, но и помогает свести к минимуму риск недопонимания или неправильного толкования.
Я считаю, что инвестирование времени в четкую документацию стоит усилий, поскольку это может помочь предотвратить разочарование, свести к минимуму риск ошибок и привести к более быстрому и эффективному процессу проверки. Так что найдите время, чтобы должным образом задокументировать свой код и сопутствующие пояснения, и вы будете на пути к беззаботному просмотру.
Унифицируйте свой код для максимальной эффективности
Мне нравятся стандарты, потому что они говорят мне, что я должен просто следовать тому, что потребовало много работы, чтобы сделать это приемлемым для сообщества. Такие стандарты, как ISO и IEEE, имеют решающее значение для обеспечения качества и согласованности в разработке. Эти стандарты необходимы для повышения качества, удобства сопровождения и согласованности кодовой базы. Вот почему необходимо уделять особое внимание соблюдению стандартов кодирования в кодовой базе проектов разработки программного обеспечения.
Как инженер, при отправке запроса на вытягивание (PR) важно убедиться, что ваш код соответствует установленным стандартам кодирования и передовым методам вашей организации.
Это включает в себя соблюдение соглашений об именах переменных, функций и классов для повышения удобочитаемости и удобства сопровождения кода, использование согласованного форматирования кода для уменьшения количества ошибок и повышения удобочитаемости, реализацию надлежащей обработки ошибок с четкими сообщениями об ошибках и надлежащее ведение журнала, предоставление хорошо прокомментированного кода для объяснения его логику и предоставлять контекст рецензентам, а также следовать передовым методам обеспечения безопасности, чтобы свести к минимуму уязвимости.
Есть много инструментов, которые могут помочь вам в этом, например:
- https://github.com/hassanhabib/The-Standard от @hassanhabib
- https://plugins.jetbrains.com/plugin/7973-sonarlint
- https://marketplace.visualstudio.com/items?itemName=SonarSource.sonarlint-vscode
- https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode
- https://learn.microsoft.com/en-us/visualstudio/ide/create-portable-custom-editor-options?view=vs-2022
После того, как вы настроите эти инструменты, вы сможете автоматизировать многие вещи и сосредоточиться на кодировании и доставке.
Это приводит к упорядоченному и эффективному процессу проверки, снижению стресса и обеспечению успеха проекта разработки программного обеспечения.
Обычные коммиты
Для меня использование обычных коммитов помогло улучшить качество и эффективность моего процесса разработки. Вот почему я рекомендую использовать его, и вы, как разработчик, стремящийся улучшить свою кодовую базу и оптимизировать рабочий процесс запроса на вытягивание, должны попробовать его.
Для этого есть несколько причин. С обычными коммитами я смог сделать свои запросы на слияние короткими и удобными для просмотра. С другой стороны, я обнаружил, что гораздо проще сообщить цель и контекст изменений, вносимых в кодовую базу. Это потому, что я структурирую свои сообщения коммитов стандартизированным образом.
Как правило, я отслеживаю свои изменения, используя согласованный формат сообщения о коммите и фокусируя каждую фиксацию на конкретном изменении. Рецензенты также могут оставлять отзывы об определенных частях моего кода с четкими сводками в моих сообщениях о коммитах. Легче сотрудничать с другими разработчиками, создавая более мелкие и целенаправленные запросы на вытягивание. Попробуй это!
Перейдите по этой ссылке, чтобы узнать больше об обычных коммитах.
Пример контрольного списка перед отправкой PR
Вот мой пример контрольного списка, которому инженеры могут следовать перед отправкой запроса на включение (PR):
Обзоры запросов на вытягивание с помощью эмпатических подходов
Когда дело доходит до проверки запроса на вытягивание (PR), эмпатия относится к стилю проверки кода, который делает упор на понимание мотивов и контекста участника. Вместо того, чтобы создавать конфронтационную среду для обратной связи и сотрудничества, этот подход создает позитивную рабочую среду.
Цель эмпатического обзора — понять, почему было внесено изменение, какую проблему оно пыталось решить и как было сформулировано решение. Благодаря такому пониманию рецензент и автор могут завоевать доверие и уважение, что поможет выявить любые потенциальные недостатки или области для улучшения.
Ключом к эмпатическому обзору запроса на включение является предоставление конкретной, действенной обратной связи. Это означает предоставление обратной связи, которая должна быть четкой, краткой и иметь непосредственное отношение к анализируемому коду. Обзор кода помогает автору понять, что нужно улучшить и что нужно изменить.
Такие комментарии, как «это выглядит неправильно» или «мне это не нравится», бесполезны, поскольку они не предоставляют конкретной информации, которую автор может использовать для улучшения кода. В отличие от этого, конкретный, действенный отзыв может включать: «Переменная «temp» недостаточно описательная, рассмотрите возможность использования более описательного имени, такого как «temporary_value»» или «Эта функция слишком длинная и сложная, рассмотрите возможность разбить ее на более мелкие, более управляемые функции».
Также важно учитывать контекст кода и автора при предоставлении отзыва. Предоставление дополнительных указаний и пояснений может быть полезным, если автор является новичком в проекте или конкретном языке программирования.
Вы можете помочь автору улучшить код, предоставив конкретную и действенную обратную связь. Все выиграют от лучшего качества кода и более позитивной среды для совместной работы.
Сосредоточенность на коде, а не на человеке — ключ к успеху
Эмпатический обзор фокусируется на коде, а не на авторе. Избегая личных нападок и критики в адрес автора, мы можем вместо этого сосредоточиться на улучшении самого кода.
Атаковать авторский код личными нападками, например, называть его «ленивым» или «глупым», контрпродуктивно и только создает конфронтационную среду. В результате могут быть задетые чувства, испорченные отношения и отсутствие мотивации.
Вместо этого следует сосредоточиться на улучшении кода. Это означает предоставление конкретной, действенной обратной связи, которая фокусируется на коде, а не на авторе. Вместо того, чтобы говорить: «Этот код ужасен», более продуктивным и чутким подходом было бы: «Этот код можно улучшить, используя более эффективный алгоритм или рефакторинг, чтобы упростить его обслуживание».
Поддержание позитивной и конструктивной рабочей среды для обратной связи и сотрудничества может быть достигнуто путем сосредоточения внимания на коде и избегания личных нападок. В результате код станет лучше, а отношения между членами команды — крепче.
Уважать и всегда быть профессионалом
Чтобы провести эмпатическую проверку пулл-реквеста, крайне важно быть уважительным и профессиональным. Вы должны использовать профессиональный, уважительный и уместный язык, независимо от того, согласны ли вы с внесенными изменениями.
Если вы используете неуважительный или непрофессиональный язык, например, личные нападки или оскорбительные выражения, это не будет продуктивным. Это приведет к обиде и испорченным отношениям между вами и другими людьми. Если это произойдет, это может создать конфронтационную и негативную среду, которая препятствует сотрудничеству и совершенствованию на рабочем месте.
Даже если вы не согласны с изменениями, используйте профессиональный и уважительный язык. Сосредоточьтесь на улучшении кода с помощью вежливого и конструктивного языка. «Это глупое изменение» можно сказать более уважительно и профессионально, сказав «Можем ли мы прыгнуть по вызову, я могу поделиться с вами трюком, который много раз спасал мне жизнь».
Создание позитивной и конструктивной среды обратной связи требует уважения и профессионализма. В результате код станет лучше, а отношения — крепче.
Контрольный список или рецензенты
Рецензенты могут использовать следующий контрольный список, чтобы обеспечить эффективную и чуткую обратную связь:
Изучите влияние пул-реквестов на разработку программного обеспечения.
Работая над этой статьей, я попросил разработчиков поделиться своим мнением о пул-реквестах и их влиянии на разработку программного обеспечения. Результаты анализируются здесь.
Как бы вы оценили эмоции, которые вы обычно испытываете при создании запроса на вытягивание?
Эмоции, возникающие при создании запроса на вытягивание: ответы варьируются от разочарования, удовлетворения, смущения и волнения с оценками от 0 до 10. Интересно отметить, что разочарование — это обычная эмоция, которую испытывают многие разработчики при создании запросов на вытягивание.
Как бы вы оценили свои чувства после того, как наконец отправили запрос на вытягивание, над которым работали в течение длительного периода?
Большинство разработчиков сообщили, что чувствуют себя удовлетворенными или взволнованными после отправки запроса на вытягивание. Это указывает на то, что завершение и отправка запроса на вытягивание обычно рассматривается как положительное достижение.
Что вы почувствовали, когда получили отзыв о запросе на вытягивание?
Наиболее распространенная эмоция, о которой сообщается в ответ на получение отзыва о запросе на вытягивание, — это разочарование, которое предполагает, что некоторые разработчики могут испытывать трудности с отзывами, которые являются критическими или трудными для рассмотрения.
Как бы вы оценили влияние вашего уровня уверенности на создание запроса на вытягивание?
Большинство разработчиков оценили свой уровень уверенности как умеренное влияние на создание запросов на вытягивание, предполагая, что уверенность является важным фактором, но не обязательно самым важным.
Как бы вы оценили влияние страха быть отвергнутым на создание пулл-реквеста?
Боязнь отказа была оценена как имеющая среднее или сильное влияние на создание запросов на включение, что указывает на то, что некоторые разработчики могут не решаться отправлять запросы на вытягивание, опасаясь негативных отзывов.
Что бы вы посоветовали другим рецензентам по улучшению процесса проверки запросов на включение?
Наиболее распространенные предложения по улучшению процесса рецензирования включают в себя добавление правильных причин для комментариев, разбиение больших запросов на вытягивание, сосредоточение внимания на лучших практиках, а не на бизнес-контексте, и тщательный выбор слов при оставлении комментариев.
Какие рекомендации вы бы дали другим разработчикам, чтобы обеспечить успешное и эффективное создание запросов на вытягивание?
Большинство разработчиков рекомендовали, чтобы запросы на вытягивание были небольшими, чтобы разработчики проверяли свой собственный код перед отправкой и чтобы команда была в курсе изменений в проекте.
По вашему опыту, как вы относитесь к запросам на вытягивание? Считаете ли вы их эффективным и действенным инструментом для обеспечения высококачественной разработки программного обеспечения? Кроме того, есть ли какие-либо альтернативные подходы, которые вы бы порекомендовали изучить для улучшения процесса запроса на вытягивание?
В целом, разработчики рассматривают пул-реквесты как эффективный инструмент для обеспечения качественной разработки программного обеспечения. Однако некоторые также отметили, что процесс может быть разочаровывающим или неприятным, если рецензенты неприятны или критичны.
Респонденты опроса не рекомендовали никаких альтернативных подходов, что указывает на то, что процесс запроса на вытягивание в целом считается эффективным и действенным.
В заключение, этот опрос показывает, что пулл-реквесты в целом положительно воспринимаются как инструмент обеспечения высококачественной разработки программного обеспечения. Тем не менее, есть некоторые проблемы, связанные с этим процессом, в том числе разочарование и страх быть отвергнутым.
Чтобы решить эти проблемы, разработчики рекомендовали разбивать большие запросы на вытягивание, сосредоточившись на лучших практиках и проверяя собственный код перед отправкой. Кроме того, важно тщательно выбирать слова, оставляя комментарии, чтобы не вызвать разочарование или обиду.
Окончательно
Тщательно тестируя свой код, предоставляя четкую документацию и придерживаясь стандартов кодирования, инженеры могут свести к минимуму стресс в процессе проверки запроса на включение.
Рецензент, с другой стороны, может использовать эмпатический подход, сопереживая коду, а не человеку, предоставляя конкретную и действенную обратную связь, проявляя уважение и профессионализм.
Опрос показывает, что разочарование и страх быть отвергнутым являются общими проблемами. Тем не менее, команды разработчиков программного обеспечения могут преодолеть это, разбивая более крупные запросы на вытягивание, следуя передовым методам, просматривая собственный код перед отправкой и тщательно выбирая слова при оставлении комментариев. В результате передовой опыт может ускорить время решения и улучшить результаты.
Мы можем предоставить конструктивную обратную связь, которая приведет к улучшению качества кода и укреплению отношений в команде. Этого можно добиться, сосредоточившись на коде, избегая личных нападок, используя профессиональный и уважительный язык, поощряя обсуждение и учитывая контекст. Последовательная и эффективная обратная связь также может быть обеспечена с помощью контрольного списка.
Культура разработки программного обеспечения и компании могут быть продуктивными, если создается конструктивная среда для обратной связи и сотрудничества.
P.S. Если вы считаете, что я могу чем-то помочь, не стесняйтесь обращаться ко мне, и я свяжусь с вами как можно скорее. [email protected]
Ваше здоровье! 👋
