Фагнер Блэк написал о “вредных советах”, которые нужно избегать при парном программировании.
Парное программирование — это техника, при которой исходный код создается парой людей, программирующих одну задачу за одним рабочим местом. Ведущий программист управляет компьютером и думает над кодом в деталях. Штурман сосредоточен на картине в целом и непрерывно просматривает код, производимый ведущим программистом.
Эта статья суммирует наиболее эффективные способы испортить опыт парного программирования.
Принуждать к парному программированию
Каждого человека команды нужно принуждать к парному программированию. Лучше всего в строго определенное время, когда менеджеры знают, что это лучшее время, чтобы программировать в паре, например, время работы вне офиса, время ланча или у кого-то есть занятия “поважнее”.
Контролировать и требовать результаты ASAP
Парное программирование обещает быстрее писать программное обеспечение с меньшими затратами. Ключевым моментом здесь является строгое измерение времени, которое два разработчика тратят на выполнение задачи.
Руководство должно убедиться, что разработчики, занимающиеся программированием в парах, понимают, что компания нуждается в результатах, и что деньги компании расходуются. Это определенно сделает их менее эффективными, потому что они будут в стрессе из-за давления, которое принудит их предоставить посредственный результат, который подтвердит менеджерам и другим разработчикам, что парное программирование не работает.
Создавать давление — это лучший способ притвориться, что вы поощряете кого-то работать усерднее и быстрее.
Два программиста, выполняющие работу одного
Каждому в компании должно быть ясно, что парное программирование — это две обезьяны, которым платят за работу, которую может выполнить и один. Таким образом, менеджеры должны требовать парное программирование только при необходимости. Это должно быть понятно через все источники связи с сотрудниками.
Помните, что недостаточно просто неправильно заниматься парным программированием. Все должны знать, насколько это бесполезно. Виновато оно, а не культура компании.
Всегда старайтесь быть лучше, чем ваш коллега
Парное программирование должно быть возможностью для разработчика продемонстрировать свои навыки использования неизвестных функций, характерных для языка, с которым он работает. Если коллега сомневается, что эта функция полезна, назовите их глупыми за то, что они не понимают такой базовой концепции, и порадуйтесь, что они учатся у лучшего разработчика страны.
Никогда не признавайтесь, что не знали новой для себя информации, которую вам сообщает коллега. Вы знаете все.
Говорите, что делать и не задавайте вопросов
Всегда говорите коллеге, что ему нужно сделать и не принимайте никаких предложений. Вы должны быть тем, кто говорит, что делать. Всегда используйте самое сложное решение, чтобы продемонстрировать свое замечательное знание синтаксиса библиотеки, фреймворка или языка, с которыми работаете.
Работайте в паре с новичками
Всегда предпочитайте работать с новичками, а не с теми, кто знает, что делает. Если возможно, напугайте их своими знаниями, чтобы они покинули компанию перед тем, как отберут ваше место.
Другая польза от работы с новичками – это то, что на вопросы вы можете отвечать что угодно, и они не узнают, что ответы были неверными! Никогда не предлагайте поискать ответы в интернете, чтобы убедиться в их правильности, скажите, что вы уже все знаете, и поиск ответа потратит деньги компании. Также говорите, что им не следует верить всему, что они видят в интернете.
Не выдавайте ключевую информацию о бизнесе и технологии
Если коллега задает вопросы о бизнесе или технологии, дайте информацию таким образом, чтобы она казалась такой абстрактной, что копание в деталях займет слишком много времени. Скажите им верить и учиться вместе с вами, а вы будете говорить, что делать, и в следующий раз они уже будут знать ответ.
Смейтесь над коллегой
Одна из лучших вещей — смеяться над новичком или (желательно) опытным разработчиком, когда они делают что-то неправильно.
Если вам нужно что-то объяснить дважды, высмейте этот факт, вы ведь понимаете все с первого раза.
Считайте, что каждый хочет протестировать вас
Если кто-то, кто лучше вас технически, пытается попросить о помощи, предположите, что они пытаются проверить вас, и это может быть опасно, потому что они могут вас разоблачить. Найдите оправдания не заниматься программированием вместе и попросите их проверить ваш код после того, как вы внесете большое количество исправлений. Если вы меняете код с неверными предпосылками, его становится сложнее переписать, потому что тогда стоимость обзора кода сильно возрастает, чем при заранее замеченной проблеме. Если кто-то предлагает подумать над архитектурой, у вас есть оправдание для менеджера, потому что “код работает”, и тогда им придется просто принять вашу архитектуру, потому что для нетехнического специалиста кажется, что если что-то работает, то не нужно ничего менять.
Отклоняйте любое предложение по архитектуре или надежности
Не принимайте предложения по улучшению архитектуры любого из ваших коллег, если только конечный результат вашего кода не сломает что-то, что видно руководству. Если ваш партнер предлагает улучшения, скажите, что это только их мнение, и призовите их быть более объективными.
Если предложение могут понять только технические специалисты, скажите менеджерам, что человек, предлагающий их, некомпетентен, потому что они вносят предложения, чтобы показаться “умными”.
Заключение
Многие компании повторяют эти ошибки, а значит обречены на провал и скоро навсегда покинут рынок. Помните, что вы отвечаете за свою собственную карьеру и избегайте людей, которые совершают эти ошибки.