Погрузиться в мир программирования — это все равно, что отправиться в отпуск, прыгнуть в море, а потом осознать, что «на самом деле здесь скрывается всякое».

Что, конечно, верно, и если вы останетесь там достаточно долго, скорее всего, вам придется иметь дело с некоторыми из этих вещей — будь то немного водорослей, касающихся вашей ноги (что, я уверен, мы можем согласиться, особенно ужасно) или что-то другое.

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

Такие вещи, как рекурсия, замыкание, подъем, область видимости… поначалу все это довольно запутанно, но, возможно, ни одна из них не является столь же необычной, как ваше первое знакомство с «парным программированием». Который, если вы не слышали раньше, в значительной степени делает то, что написано на банке. Два программиста объединяются, один занимает позицию «водителя» (пишет код), а другой — «навигатора» (инструктирует, какой код писать), и в паре они программируют.

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

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

Словно незнакомец вдруг прыгнул с тобой в ванну.

Хотя, каким бы странным и неудобным ни казалось на первый взгляд парное программирование, польза от него феноменальна. Честно говоря, сначала мне не очень понравилась эта идея, и, честно говоря, я не уверен, что многим это нравится. Я имею в виду, вы уже знаете, как «водить машину», и вы, вероятно, знаете, как «ориентироваться», верно? Так какой смысл в паре, когда можно делать и то, и другое?

Что ж, давайте обсудим это.

Во время практики вы, вероятно, читали чужой код в Интернете и думали: «Это интересное решение, но как оно работает?».

Было бы неплохо, если бы рядом с вами был кто-то, кто уже сталкивался с подобным кодом? Кто-то, с кем вы могли бы обсудить плюсы и минусы разных идей?

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

Правильно, это парное программирование.

Однако иногда неприязнь к спариванию возникает из-за недостатка уверенности, а не из-за ее чрезмерной уверенности. Вопрос «А что, если мой партнер лучше меня?» скоро появится, и это нормально. Мы все немного нервничаем, когда пишем код. Некоторые из нас схватывают это быстрее, чем другие, и это нормально. Это не должно отвлекать вас от работы с другими. На самом деле, вы, вероятно, многому научитесь у этих людей, которые могут быть немного впереди.

Способ приблизиться к этому — простая комбинация комплимента/вопроса (потому что все любят комплименты).

«Эй, код, который ты пишешь, действительно хорош, есть даже некоторые моменты, которых я никогда раньше не видел. Вы не возражаете, если я задам вам несколько вопросов по этому поводу, пока мы продолжим?»

Кажется, не так уж сложно спросить, не так ли? Нет, потому что это не так. Люди любят говорить о вещах, в которых они хороши. Вам просто нужно убедиться, что в обмен на время, которое они потратили на помощь вам, вы нашли время, чтобы выслушать и понять. Только не сравнивай себя.

«Но что, если мой партнер будет меня тормозить?»

Помните, ранее я упоминал о том, что никогда раньше не приходилось никому объяснять свой код? Ну, на самом деле это довольно сложно, если вы к этому не привыкли. Декларирование кода другим — неотъемлемая часть работы в команде, и чтобы быть эффективным в этом, нужна практика. Особенно, когда вы пытаетесь поговорить с другими людьми, которые могут быть не такими технически подкованными.

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

И, наконец, скрытая польза от спаривания.

В этой статье я не расскажу всего о Дзен, но парное программирование также поможет вам стать лучше.

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

Почему?

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

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

Это похоже на выбор чего-то нового из меню, а не ту же самую старую корму, которую вы обычно едите.

А в другой раз вы мгновенно столкнетесь с человеком, о котором никогда не думали, и вдруг обнаружите, что смеетесь вместе над заданием и, возможно, даже заводите нового друга. Что довольно мило на самом деле, не так ли?

Так что не пугайтесь парного программирования. Наслаждайся этим.