Комментарии 6
Прочел про парное программирование, никогда такого раньше не видел. Поделитесь — кто в России такое практикует, не хочется ли прихлопнуть чем-нибудь человека за неделю работы?:)
Какие плюсы и минусы дает такой подход?
Какие плюсы и минусы дает такой подход?
Ну вот на хабре недавно статья была, например: https://habr.com/ru/company/barsgroup/blog/533630/
Технически парное программирование можно разделить на два этапа:
1) этап он знаком каждому когда один более опытный и знающий код объясняет другому возможно даже не менее опытному как и что там работает и как быстро закодить задание т.е. говоря обычным языком вводит в курс дела.
Польза тут очевидно быстро ознакомить с проектом еще одного человека.
2) этап то, что практикует Пивотал это когда двум кодерам дается одно и тоже задание на один день (предполагается, что задание можно сделать за один день) и тут начинается кодировка на одном экране с двумя клавиатурами. При определенной сноровке такой метод работает если задания хорошо прописаны и работа довольно рутиная. Здесь в Долине этот метод прижился исключительно в Пивотал, я как один из бывших пользователей и разработчиков сервисов Cloud Foundry не скажу, что метод хорош, но «париться» с приятной девушкой я бы не отказался. С мужиками как-то особо больше получаса не имеет смысла. На практике обсудили, закодили тест кейс совместно вполне достаточно получаса.
Основной вывод метод неплох и им владеть надо так как бывают ситуации когда имеет смысл парное программирование ИМХО.
1) этап он знаком каждому когда один более опытный и знающий код объясняет другому возможно даже не менее опытному как и что там работает и как быстро закодить задание т.е. говоря обычным языком вводит в курс дела.
Польза тут очевидно быстро ознакомить с проектом еще одного человека.
2) этап то, что практикует Пивотал это когда двум кодерам дается одно и тоже задание на один день (предполагается, что задание можно сделать за один день) и тут начинается кодировка на одном экране с двумя клавиатурами. При определенной сноровке такой метод работает если задания хорошо прописаны и работа довольно рутиная. Здесь в Долине этот метод прижился исключительно в Пивотал, я как один из бывших пользователей и разработчиков сервисов Cloud Foundry не скажу, что метод хорош, но «париться» с приятной девушкой я бы не отказался. С мужиками как-то особо больше получаса не имеет смысла. На практике обсудили, закодили тест кейс совместно вполне достаточно получаса.
Основной вывод метод неплох и им владеть надо так как бывают ситуации когда имеет смысл парное программирование ИМХО.
Ребята, верните возможность отката восстановления системы из снапшота!
Жесть какая-то. "Я работаю 9 часов в день, спасибо парному программированию, что всего 9".
Роли распределяются так: драйвер печатает код, фолловер — проверяет и смотрит наперед, какие ошибки могут возникнуть в его работе.
Никогда этого не понимал. Неужели у кого-то печатать код или «понажимать на кнопки» как говорит один человек занимает какое-то значимое время?
Обычно когда понял что именно надо написать и эта идея уже проверена и точно рабочая и хорошая осталось дело техники. Самая скучная часть.
Просто аккуратно реализовать все придуманное. А потом переписать разок минимум, сделать кучку тестов, отладить, выкатить и прочая скучная рутина сжирающая время как не в себя.
Зачем второму человеку сидеть и смотреть на эту рутину?
Поучаствовать в обсуждении идеи? Конечно
Если там планируется нетривиальный алгоритм, то обсудить и его? Конечно.
Архитектуру при её необходимости обсудить и даже описать отдельно? Конечно.
Посмотреть на результат? Код ревью называется. Конечно. Глупые ошибки или просто неверные реализации самых правильных идей у всех бывают.
Но вот зачем сидеть смотреть как другой человек нажимает на кнопки непонятно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Один день из жизни разработчика VMware