Еще одна замечательная пара дней обучения в Makers Academy пролетела незаметно, и я объединился с членами нашей когорты, чтобы справиться с набором задач Boris Bikes. Этот пост представляет собой резюме нескольких уроков, которые мне удалось извлечь из своего опыта.

NB: Все это не евангелие.

Состав

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

Основные правила: методология переключения

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

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

Основные правила: разрешение конфликтов

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

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

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

Основные правила: другие аспекты работы - обсуждение, обсуждение, обсуждение

Кажется, это хорошо сработает, если вы обсудите способы работы между парой. Конкретные примеры, которые мне действительно понравились:

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

Учимся учиться

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

Например, предположим, что вы переключаетесь с переменной экземпляра, содержащей только одно значение, на переменную экземпляра, содержащую массив. У вас есть тестовый метод, который проверяет, равна ли ваша переменная nil. После того, как вы переключились на массив, ваша переменная экземпляра никогда не будет nil, и поэтому тест не будет действовать так, как вы ожидаете. Чтобы понять это, почему бы не попробовать свои переменные в IRB / PRY? Вот так:

[1] pry(main)> array = nil
=> nil
[2] pry(main)> array.nil?
=> true
[3] pry(main)> array = []
=> []
[4] pry(main)> array.nil?
=> false
[5] pry(main)>

Скажем, у вас есть метод, который зависит от unless variable.nil? возврата true. Но теперь ваш variable является массивом, и ваш тест никогда не вернет true (потому что созданный массив всегда true, даже если он пуст (проверьте его в IRB / PRY, потому что, возможно, я лгу или не знаю, о чем говорю )), так как же нужно будет изменить ваш метод? Обсуди это, тест-драйв.

Еще одна вещь, которая действительно хорошо работает и подтвердила для меня Таксономию Блума, - это следующее:

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

Итак, объясните, объясните, объясните :)

В любой паре всегда трое.

Когда дядя Боб * пробивал карты со своим партнером по паре, чтобы кормить своего голема **, мы вправе сказать, что в этих сеансах парного программирования их было только двое - дядя Боб и его пара. Однако, и это то, что я почерпнул из семинара по отладке, когда вы объединяете программу сегодня, вас будет как минимум трое - вы, ваш партнер по паре и Голем. Наши големы говорят - они говорят нам, поняли ли они нас или нет, если мы оскорбляем, и, чтобы быть очень вежливым, наши Ruby и RSpec Golems говорят нам, где в наших заклинаниях или алхимических рецептах искать ошибки, которые вызывают размытость несчастье, исходящее от нашего Голема.

Итак, прочтите и поймите сообщения об ошибках при парном программировании (и при полетах в одиночку). Они сделают ваш опыт проще, а вашего Голема - более послушным.

* Дядя Боб в мире разработки программного обеспечения не является, как можно предположить, общей ссылкой на класс. Фактически, он настоящий человек.
** Голем - хотя этот термин происходит из еврейского фольклора, определение, которое мне больше всего нравится, звучит так: метафора безмозглого существа, которое служит человеку в контролируемых условиях. но враждебен к нему со стороны других , иначе говоря, ваш компьютер :)