Что такое парное программирование?

Зачем вообще нужно читать статью о том, что такое парное программирование? Разве его название уже не все объясняет? Ну и да, и нет. Как следует из названия, парное программирование - это когда два разработчика работают на одной машине для мозгового штурма, решения проблем и работы над различными задачами. Но что они делают? Они просто встречаются и обсуждают программы? (Мне лично хотелось бы это сделать) Обычно у каждого человека своя роль. В большинстве случаев один человек будет «водителем», а другой - «наблюдателем». При парном программировании драйвер пишет код, а наблюдатель просматривает написанный код, предлагая следующие шаги и различные способы написания логики, а также проверяя ошибки или возможные ошибки. Роли могут перемещаться и переключаться между ними в любое время, что я действительно рекомендую, потому что это позволяет постоянно проверять и писать код с разных точек зрения. Эта форма парного программирования может иметь место всякий раз, когда вы задаете вопросы руководителю / наставнику о коде, который вы пишете, или с коллегами и товарищами по команде, которые работают над одним и тем же проектом с вами.

Зачем нужна парная программа?

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

В программировании большую роль играет эффективность. Чем эффективнее будет ваш код, тем он станет понятнее и легче для чтения, что снизит вероятность появления ошибок и упростит совместную работу над ним или возможность вернуться к нему. Часто программисты сталкиваются со словом «СУХОЙ». Каждый раз, когда я пишу код, я задаюсь вопросом: «Может ли этот фрагмент кода быть DRIER?». Сделать ваш код СУХИМ означает сделать его более эффективным и исключить повторяющиеся коды более модульными. Я считаю, что с помощью парного программирования легче писать сухой код, не возвращаясь снова и снова, чтобы высушить ваш код. Когда разработчик пишет код, в его голове много чего происходит. Это будет зависеть от масштаба проекта, но программисту есть что учитывать при написании кода. Поскольку все мы люди, люди совершают ошибки, а код никогда не допускает ошибок, даже незначительных. Даже отсутствие точки с запятой или одного пробела может привести к поломке всего приложения и появлению сотен строк ошибок. Если вам повезет, вы можете сразу найти ошибку и исправить ее, но, по моему опыту, я потратил часы на отладку, написание логики разными способами, навигацию по гигантской файловой структуре, чтобы в конце концов обнаружить, что я неправильно написала переменную. Также, когда ошибка возникает в файле с тысячами строк кода, найти ошибку самому может стать кошмаром.

1 const someVariable = "some value";
...
2003 if(!someVarable) {
2004  ...
2005 };

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

Преимущества парного программирования

  • Обеспечивает лучшее понимание кода. Если говорить вслух на протяжении всего кода (метод «резиновой утки»), он дает более четкое представление о написанном коде.
  • Предоставляет опыт обучения в случаях, когда один не знает, а другой знает конкретную реализацию кода.
  • Снижение затрат сил и времени на производство.
  • Лучшее качество кода. Снижает риск ошибки или более эффективного рефакторинга кода.

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

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

- Жан Бартик, один из самых первых программистов

Когда мы должны заниматься парной программой?

Итак, когда именно вы должны принять решение о парной программе? Я думаю, что есть определенные ситуации, когда было бы лучше всего использовать парную программу, а это не так.

Do :

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

Нельзя:

  • Когда вы слишком заняты и нуждаетесь в том, чтобы кто-то написал за вас код, пока вы работаете над разными задачами. Таким образом вы не только торопитесь выполнять свои задачи, но и тратите время члена команды. Расставляйте приоритеты в том, что можно сделать, никогда не позволяйте одному человеку делать все.
  • Когда вы «чувствуете себя», это становится сложной задачей, и вы хотите ее избежать. Может возникнуть соблазн попросить пожилых людей сразу взглянуть на ваш код и рассказать, как это делается, но это не оставит вам места для роста.
  • Когда вы знаете, что вам нужно делать, и ваш партнер тоже. Тот факт, что вы установили время для парной программы со своим товарищем по команде, не означает, что вы должны это делать. Если это задача, которую можно выполнить самостоятельно с минимальными трудностями, было бы непродуктивно задействовать время и усилия еще одного члена команды для выполнения этой задачи.
  • Когда вы оба не заняты и тратите слишком много времени на что-то, что вы оба не можете решить. Это может занять больше времени и, в конечном итоге, потратить ваше время без выполнения каких-либо задач. Важно решить, когда прекратить парное программирование, и подумать о другом подходе к ситуации.

Для будущих парных программистов

Я помню, как в первый раз выступил в паре с программой «равные пары», и я был очень взволнован этим. На протяжении всего времени я открывал для себя разные способы решения проблем (что я считаю одним из самых замечательных аспектов программирования) и по мере продвижения вперед делал меньше ошибок. Мы оба не были уверены в своих ролях и продолжали прыгать в код друг друга, но мне это действительно нравилось.

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

использованная литература