Мы привыкли программировать сидя в одиночестве, надеваем наушники и просто погружаемся в это. Но так должно быть не всегда. Вы можете взять одного из своих друзей или коллег, чтобы они сели рядом с вами, и вы оба можете начать программировать. Звучит странно, два человека сидят рядом и работают над одной и той же задачей. Не правда ли?
Нет. Иногда вам нужно просто поделиться своими взглядами с коллегами и посмотреть, насколько они по-разному думают об одной и той же проблеме. Я много делал это в своей повседневной работе. Один из моих друзей, Арвинд - https://medium.com/@arvindp94, когда нам скучно или мы думаем, что нам нужно больше информации от кого-то другого, мы обычно сидели вместе и решали проблему. Не путайте только одного человека с типом, другой участвует в обсуждениях и прочем.
Я расскажу вам о некоторых преимуществах выполнения этого упражнения время от времени. Пойдем!
Знать ошибки
Мы просто считаем само собой разумеющимся реализацию, которую делаем. Когда вы начинаете обсуждать со своим коллегой, вы понимаете ошибки, которые делаете регулярно. Например, вы могли пропустить крайний вариант «‹ »вместо« ≤ », это либо будет указано в цикле проверки, либо, в худшем случае, оно просто будет запущено в производство.
Эти ошибки могут быть такими же простыми, как указано выше, или могут быть очень высокоуровневыми, например, зачем нам создавать именно эту функцию X? Это абсолютно необходимо и т. Д. Обсуждение, которое вы проводите с коллегой, дает вам много информации, чем просто определение ошибки.
Мозговой штурм
Программирование - это не просто сидение перед компьютером и написание кода, который следует синтаксису. Иногда обсуждение выходит из-под контроля настолько, что мы в конечном итоге берем доску и маркер, рисуем компоненты, взаимосвязи и т. Д. В этот конкретный момент рисование само по себе просто не имеет смысла.
Вместе с другом у вас есть несколько контраргументов, вы меняете дизайн и в конечном итоге делаете его эффективной версией. Это лучшее, что происходит с одноранговым программированием. Глубокий мозговой штурм по какой-то конкретной проблеме дает больше информации о том, как ее следует реализовать.
В любом потоке, работая изолированно, не обсуждая то, что вы делаете, с кем-то, кто может критиковать, никогда не даст наилучшего результата.
Структура кода
Это интересная часть обсуждения. Мы привыкли выяснять, почему определенная функция или переменная должна вызываться таким образом. Это низкоуровневые строительные блоки кода. Это не заканчивается на том, какие должны быть входы для функции, что она должна возвращать, как структурировать проект, создавать ли новый файл / папку для компонентов, которые вы добавляете, и т. Д. Несколько тем, которые мы в основном используется для обсуждения
- Именование
- Входы и выходы
- Структура проекта
- Лучшие алгоритмы
Я отдельно объяснил, как я структурирую проекты, над которыми работаю: https://pramodkumar-damam73.medium.com/how-i-structure-my-project-b69a2373b2dd. дискуссий.
Меньше времени на проверку и лучший результат
В результате всех этих обсуждений вы в основном получаете действительно отточенную и подходящую версию функции / изменения, которые вы внедряете. Это означает, что циклы проверки займут очень мало времени, так как они уже проверены и отфильтрованы.
Вместе с тем, весь процесс происходит в режиме реального времени, в отличие от PR-обзоров, которые занимают много времени и несколько циклов.
Командная работа
Это еще одна важная тема нетехнического характера. Приложить два мозга к одной теме непросто. Вы попадаете в множество споров, временами они могут пойти еще хуже. Важно, как вы справляетесь с такими ситуациями. Люди, участвующие в любом обсуждении, должны быть максимально прозрачными.
Всякий раз, когда мы приводим контраргумент, мы должны указывать на аргумент, а не на человека. Нам нужно понимать, что мы преследуем общую цель - сделать функцию / изменение более эффективной.
Итак, приводите аргументы с доказательствами и причинами. Будьте открыты для принятия других взглядов и подходов, если у вас нет причин придерживаться своей версии. Не принимайте ничего на свой счет и поддерживайте здоровые дискуссии и споры.
Чаще программисты (я) умеют кодить лучше, чем общаются с людьми, что не очень хорошо. Таким образом, выполнение большего количества таких упражнений улучшит навыки, необходимые для работы в команде, и добьется наилучших результатов.
Резюме
Парное программирование - это когда два человека программируют / кодируют одну и ту же задачу, сидя рядом друг с другом (или звонок с общим экраном). Обсуждения, которые мы проводим с коллегами во время кодирования, улучшат наши технические возможности, принесут лучший результат и улучшат наши навыки работы в команде.
Итак, найдите идеального партнера и попробуйте! Я пишу о подобных опытах в Твиттере. Следуйте за мной здесь - https://twitter.com/pramodk73
