Все много писали про «Парное программирование». Как это клёво и всё такое. Но как бы возникает проблема, что два программиста за день пишут как бы 150% работы одного программиста. Ну то есть теоретически меньше.

А вот у нас в компании было так, что просто за каждым коммитером (тот кто имеет право добавлять код в основную ветку программы) был назначен ревьюер и после коммита в trunk (основную ветку программы), тикет (да!!! каждый коммит должен быть сделан по тикету) переводился на ревьюера (в тикете писался номера коммито(ов) для этого тикета). Ревьюер отсматривал изменения и или переводил тикет тестеру или же возвращал его коммитеру по одной из причин: логическая ошибка, не соблюдение правил кодирования, сложный код который нельзя прочитать и он не задокументирован, ну или же он явно видел ошибку в коде (напр. забыл проэскейпиться).

Таким образом повышалась как читаемость — соблюдались все правила кодирования, так и документированность — сложные участки кода были задокументированы.

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

А у вас что-нить подобное использовалось/используется?

UPD. понял свою ошибку. Переименовал топик.

Ни об одной теме я не слышал столько негативных отзывов, как об Аджайл. Дескать, он и неэффективный, и не работает, и подходит для ленивых, и придуман для зарабатывания бабла на консультациях, и вообще, нам аджайл не подходит.



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

Перевод этой статьи может послужить хорошей пошаговой инструкцией для тех, кто регулярно пользуется парным программированием, или хотя бы совместным просмотром кода, и при этом знаком и готов использовать текстовые редакторы, работающие в текстовом режиме (Emacs, vi и т.п.). В статье дано много интересных ссылок, советую по ним пробежать глазами, а первый комментарий содержит ссылку на аналогичный опыт, но с более чистым аналогом GNU Screen — tmux.

У нас в Siyelo две распределённых команды, одна в Кейптауне, вторая в Скопье. Нам приходится придумывать, как заниматься удалённым парным программированием между офисами. Существует много возможностей (отличный обобщающий пост здесь).
Раньше мы постоянно пользовались Skype'ом для разделения экрана, но у нас при этом возникали следующие проблемы:

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

У меня достаточно много опыта в программировании, накопленного за последние несколько лет. Часть опыта я приобрёл работая в своей команде, что-то при работе с клиентам, а некоторый опыт появился благодаря coding dojo и работе на open source проектах.
Для программистов знающих как использовать парное программирование оно предоставляет возможность улучшить свою производительность. Но при этом не стоит ожидать, что программисты значительно улучшат свою производительность с самого начала работы. Парное программирование требует постоянного обучения, а также осознания самими программистами чёткой разницы между исполнителем (тот кто стучит по клавиатуре), и штурманом. Ниже приведено более детальное описание.

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

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

Диспозиция: проект полностью пишется «нашей» командой с нуля в течении полугода. В этот момент по инициативе заказчика решено начать делать регулярные (раз в две недели) ревью кода и вообще проверить проект на соответствие их стандартам кода, архитектуры и идеологии. Стоит отметить, их специалисты представлены не сферическими техническими начальниками в вакууме, а вполне адекватными программистами синьор уровня из США (не Индия, заметьте), которые пишут свои проекты параллельно с нашим.

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

Очень часть слышу от фрилансеров ответы:
1)Занят
2)Смогу сделать завтра/через неделю/месяц.
3)Должен отказаться, всех денег все равно не заработаешь.
4)Нет столько свободного времени.
5)Не успею сделать в срок.
6)С таким не работал/нет опыта.

Вы будете реже встречаться с такими проблемами если у вас будет напарник по вашей же специальности, этот простой ход сделает вашу жизнь приятнее и мягче. В данном случае я не имею ввиду пары программист + дизайнер(хотя и от большего количества таких пар я бы тоже не отказался), а имею в виду пары к примеру программист wordpress + программист wordpress.
Давайте посмотрим на плюсы от пары фрилансеров по сравнению с одним:

Сделать удаленное парное программирование удобным — задача не из простых, но у Floobits все может получиться.

Floobits позволяет использовать свой любимый редактор для совместной работы над кодом в реальном времени — сейчас поддерживаются только Sublime Text, Vim и Emacs; кроме того, есть и традиционный для подобных сервисов веб-редактор кода, работающий прямо в браузере.

Поскольку обойтись только редактором было сложно, со временем выяснилось, что парная разработка — это не только распространение кода, но и «расшаривание» терминалов (для этого был разработан Flootty), а еще и реал-тайм обновление кода на тестовом сервере (для этого был разработан несложный diff-shipper). Кроме того, для голосового чата и обмена видео в веб-редактор была добавлена поддержка Google+ Hangouts

Вдохновившись этой статьей от СКБ Контур, решили провести Code Retreat у себя на факультете (Томский государственный университет, факультет информатики). Правда у нас целью было не обучение каким-то конкретным технологиям, а скорее просто знакомство (половина участников с 1-2 курсов), фан и немного ненормального программирования.

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

Речь идёт про теоретическую возможность сделать сайт для поиска напарников для па́рного программирования.



Когда кому-то нужна помощь, он заходит на сайт, нажимает на кнопку «Нужна помощь» и описывает суть проблемы.

Например:

Всем привет, меня зовут Антон, мне 12. Дело такое: друг написал сайт, но у него по-дурацки реализована защита от накрутки в форме голосования. Хочу продемонстрировать ему проблему в действии, но я никак не могу понять, как в Python правильно использовать CookieJar с urllib2 — серьёзно, какое-то запутанное API. Так в остальном у меня почти всё готово, осталось как раз вот поддержку cookies прикрутить. Буду рад, если поможете!

Время на реализацию (приблизительно): 30 минут
Время для связи: любой день недели, с 3 p.m. до 12 a.m.

python, cj, cookiejar, urllib2

Это перевод статьи Analysis Paralysis: Over-thinking and Knowing Too Much to Just CODE Скотта Хансельмана за 30 марта.

Прочитал сегодня пост на ArsTechnica «Я знаю слишком много чтобы программировать быстро. Что мне делать?» — это обзор вот этого вопроса на StackOverflow:

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

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

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

Последние две мои статьи — интервью со спикерами одной прошедшей конференции. Мне показалось интересным поговорить с человеком, который в свое время отказался выступать на этой конференции, “из за одного маленького семейного обстоятельства”. Этот человек — Сергей SergeyT Тепляков, MVP, автор отличной книги про паттерны проектирования, адепт TDD, ныне разработчик Tools for Software Engineers в Microsoft и мейнтейнер библиотеки Code Contracts.

Под катом много текста про конференции, TDD, парное программирование, архитектуру Code Contracts, Хабру.

Привет Хабр! Хочу поделиться с вами одним инструментом, который помогает мне делать меньше ошибок в коде и реже гуглить по вопросам разработки.

Привет, Хабр! В своей работе мы используем парное программирование и сегодня хотим поделиться с сообществом советами, которые помогают нам повысить эффективность этого метода.



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

В первом выпуске видеоблога АйтиХайп мы пришли в гости в Додо Пиццу, где обсудили интеграцию IT и бизнеса, экстремальное программирование, Agile, удаленную работу, архитектуру их систем и особенности найма. Можно пройти под кат и почитать цитаты из интервью и немного истории, а можно сразу перейти к видео.

Программируя вместе за одним компьютером, Джефф Дин и Санджай Гемават изменили курс компании — и весь Интернет. На иллюстрации: лучшие программисты Google иногда кажутся двумя полушариями одного мозга. Рисунок Дэвида Планкерта

Однажды в марте 2000 года шесть лучших инженеров Google собрались в импровизированном конференц-зале. Произошло ЧП: с октября 1999 года остановились краулеры. Хотя пользователям ещё выдавали поисковые результаты, но они устарели на пять месяцев. На карту было поставлено больше, чем предполагали инженеры. В данный момент Ларри Пейдж и Сергей Брин вели переговоры о поставке поиска Google на крупнейший в интернете портал Yahoo и обещали увеличить поисковый индекс в десять раз, чтобы идти в ногу со Всемирной паутиной, которая за предыдущий год удвоилась в размере. Если краулеры не починят, google.com застрянет в прошлом, сделка с Yahoo может провалиться, а компания рискует сжечь полученные инвестиции и кануть в небытие.

Драйвер и навигатор в действии (северокорейский вариант методики)

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

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

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

У меня была неделя — целая бесконечность, которой мне не хватило. Снова и снова я перебирал в голове варианты использования того, что должен сделать, но картинка идеального модуля не клеилась. Всегда находился кейс, который хорошо показывал: такой дизайн — говно. Я думал, играл на гитаре, пробовал писать, тупил в монитор, гуглил, играл с детьми, снова думал — голова всегда была занята дурацким модулем.

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

В понедельник утром я отправил пулл реквест. Его приняли с восторгом. Но способ, на который я пошел… вот уж никогда не думал, что отважусь на такое.

Публикуем перевод статьи, которую мы нашли на hackernoon.com. Ее автор, Thiago Miranda, пишет о том, как сделать работу с Git более удобной и эффективной.

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

Парное программирование

Мне кажется, чтобы просто объяснить, как устроено парное программирование, можно привести в пример раллийные гонки. Там есть водитель (драйвер) и штурман (навигатор). Водитель сосредоточен непосредственно на управлении автомобилем. Штурман же контролирует на каком участке мы сейчас едем, и подсказывает пилоту о предстоящих поворотах и трамплинах.

Так же и в парном программировании.

Многие разработчики слышали о практике парного программирования, но оно все еще имеет разношерстное толкование и применение. Одна из причин неоднозначного признания в том, что преимущества очевидны не сразу, а окупаются в среднесрочной и долгосрочной перспективе. И оказывается не всё так просто, как “работаем вдвоем за одним компьютером”, поэтому некоторые быстро отказываются от этого способа при появлении первых проблем. Тем не менее, по нашему опыту, парное программирование однозначно подходит для командной работы и создания качественного ПО.

P.S. Предлагаемые в статье техники затрагивают моменты удаленной совместной работы, что в текущих условиях вдруг стало особо актуальным.