# Одна голова - хорошо, а две - лучше

(В оригинале - Two Heads Are Often Better than One)

Программирование требует сосредоточенности, а сосредоточенность требует уединения. Таков один из стереотипов.

Подход «одинокого волка» потихоньку меняется на более коллективный, который позволяет для программистов повысить качество, продуктивность и удовлетворенность от работы. Согласно новому подходу, разработчикам приходится более тесно сотрудничать друг с другом и с не-разработчиками – бизнес-аналитиками, системными аналитиками, тестерами и пользователями.

Что это означает для программистов? Быть техническим экспертом теперь недостаточно, нужно еще быть эффективным в работе с другими.

Сотрудничество – это не задавание вопросов или сидение на митингах. Это, закатав рукава, сделать работу вместе с кем-то.

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

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

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

Но какова долгосрочная ценность изучения нового сочетания клавиш? Как измеряется повышение качества результирующего продукта в результате введения парного программирования? Как оценить влияние партнера, не дающего вам довести до конца решение сложной задачи? Одно из исследований показывает повышение эффективности и скорости на 40% (J. T. Nosek, "The Case for Collaborative Programming," Communications of the ACM, Март 1998 года). А какова ценность снижения «риска лотереи»? Большинство подобных показателей достаточно сложно поддаются измерению.

Кто с кем должны образовать пары? Если вы новичок в команде, то важно найти кого-то, кто является экспертом. Точно также важно, чтобы он обладал навыками коуча. Если вы не сильны в предметной области, то образуйте пару с экспертом в предметной области.

Если вы еще не убеждены, то проведите эксперимент. Объединитесь с коллегами. Образуйте пары по интересным, сложным проблемам. Посмотрите, как оно пойдет. Попробуйте повторить эксперимент несколько раз.

Автор оригинала - [Adrian Wible](http://programmer.97things.oreilly.com/wiki/index.php/Adrian_Wible)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/ru/thing_47.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.