Бывает такое, что коллеги на работе вас раздражают и вызывают чувство, что надо бы как-то с ними расквитаться, отплатить за все те воображаемые обиды, которые они вам нанесли. Многим не представляется такой возможности. Однако если вы с ними – разработчики, то всегда есть верный способ. И этот способ – инспекция кода.
Когда всё делается правильно, инспекция кода – отличный инструмент для улучшения качества кода и распространения базовых знаний внутри команды. Но если делать всё неправильно, она может отравить человеку существование. Так что это отличный полигон для отмщения через пассивную агрессию. У коллеги всё слишком хорошо получается? Или он вечно выливает себе остатки кофе, а новый не заваривает? Или как-то раз три гола назад не поздоровался с вами, потому что не заметил, что вы в офисе? Пришло время отплатить за всё сполна при помощи инспекции кода!
Ваш первый ход в пассивно-агрессивной войне с ничего не подозревающим коллегой будет связан со стилем кода. В большинстве компаний имеются руководства по написанию кода. Изучите это руководство! А затем начинайте запрашивать изменения в тех моментах, которые там четко не оговариваются. Если руководство о чем-то не упоминает, то у вас появляется прекрасная возможность потребовать бессмысленных изменений, которые только создадут для жертвы лишнюю работу.
Прописаны ли у коллеги корректные подсказки типов данных для методов из класса модульных тестов? Нет?! Обязательно скажите ему добавить void, чтобы в будущем все знали, что у модульных тестов нет никаких возвращаемых значений. Не найдется ли у него каких-нибудь слишком навороченных названий переменных? Найдется? Пусть переименует во что-то менее навороченное. В руководстве ничего не говорится об условиях Йоды? Посмотрите, как прописано в коде, и потребуйте сделать ровно наоборот. По максимуму используйте стандарты стиля, чтобы растоптать врага.
Первым шагом можно вывести человека из себя, но чтобы разжечь в его душе ненависть, одного этого будет мало. Нужно продолжать свою миссию. И следующий ее этап – запросы на изменения, которые ничего не дадут.
Если существует два варианта реализации, требуйте, чтобы коллега переписал код в соответствии с тем, который нравится вам. Если он начнет приводить доводы – перечислять преимущества своего выбора, скажем, или недостатки вашего – не слушайте. От вас требуется только растянуть обсуждение о том, почему надо всё переписать, комментариев на двадцать. Если вы затрудняетесь с ответами, напишите что-то в духе нижеследующего, чтобы создать впечатление, будто это коллега ведет себя неразумно:
Добейтесь того, чтобы коллега чуть не весь день потратил на переписывание кода, который и без того отлично выполнял свои функции.
Не торопитесь с ответом. Обождите сутки, а лучше двое, прежде чем предпринимать любые действия, связанные с инспекцией кода. Если у вас потребуют объяснений, отговаривайтесь другими делами.
Этим вы преследуете конкретную цель: pull request должен успеть устареть. Открытые pull request-ы считаются техническим долгом, потому что на их поддержку требуется ресурс. Работа это неприятная и утомительная. Поэтому тянуть резину нужно до последнего, чтобы у коллеги масса времени уходила на то, чтобы устранять конфликты слияния.
Есть хороший способ воплотить этот план в жизнь: отказывайтесь работать с pull request-ами, у которых обнаружились конфликты слияния. Ведь код после такого конфликта может измениться, так зачем вам тратить время на инспекцию, если после устранения придется проверять его еще раз? Такая тактика отлично работает на замедление.
Если коллеге не приходится два-три раза устранять конфликты слияния у каждого pull request-а, значит, вы реагируете слишком быстро.
Запросы на изменения сами по себе хорошо добавляют работы, однако запросы на изменения, которые дадут негативные побочные эффекты, справляются с этим в разы лучше. Сначала коллеге придется приложить усилия, чтобы переписать код, а потом, когда баг обнаружится и выставит его дураком, ему придется еще потрудиться, чтобы всё исправить.
В каждом pull request-е, который вы отправляете своему врагу на проверку, добрая половина изменений должна состоять из бессмысленных исправлений стиля, о которых вас никто не просил. Отыскать реальные изменения, влияющие на функциональность, должно быть как можно сложнее, тогда человек скорее просто даст всему сразу отмашку вслепую.
Проверять код легко, когда в нем от десяти до тридцати срок. Но вам не нужно, чтобы было легко. Вам нужно, чтобы людей охватывал страх, когда от вас поступает запрос на инспекцию. А значит, все pull request-ы должны содержать по тысяче переработанных строк в десяти файлах, не меньше.
При этом настаивайте, чтобы ваши запросы обрабатывались быстро. Это же технический долг, вы что, должны тратить своё время на устранение конфликтов слияния? Докапывайтесь до всех подряд, пока ветку наконец не сольют с основной кодовой базой. Если кто-то начнет огрызаться, что сами вы, мол, не торопитесь с чужими запросами, не поддавайтесь. Объясните им, что ваши запросы гораздо важнее, и без устали твердите, что пока pull request открыт, у команды копится технический долг.
Итак, вы отправили код на проверку и нудите, как описано выше. Возможно, с вами захотят сквитаться по этому поводу. Но против попыток нанести ответный удар в ходе инспекции есть хороший прием – просто не обращайте внимания. От вас требуют каких-то изменений? Попросите приятеля всё одобрить как есть и провести слияние, а комментарии пропустите мимо ушей.
Не позволяйте людям вставать у вас на пути со своей обоснованной критикой. Пусть их замечания стекают с вашего pull request-а, как с гуся вода.
Если последовательно, раз за разом осуществлять эти шаги в течение нескольких месяцев, ваши враги раскаются во всех воображаемых обидах, которые вы от них терпели.
А вот чего делать нельзя, чтобы они ненароком не получили от инспекции удовольствия:
Когда всё делается правильно, инспекция кода – отличный инструмент для улучшения качества кода и распространения базовых знаний внутри команды. Но если делать всё неправильно, она может отравить человеку существование. Так что это отличный полигон для отмщения через пассивную агрессию. У коллеги всё слишком хорошо получается? Или он вечно выливает себе остатки кофе, а новый не заваривает? Или как-то раз три гола назад не поздоровался с вами, потому что не заметил, что вы в офисе? Пришло время отплатить за всё сполна при помощи инспекции кода!
Шаг первый: замечания по стилю
Ваш первый ход в пассивно-агрессивной войне с ничего не подозревающим коллегой будет связан со стилем кода. В большинстве компаний имеются руководства по написанию кода. Изучите это руководство! А затем начинайте запрашивать изменения в тех моментах, которые там четко не оговариваются. Если руководство о чем-то не упоминает, то у вас появляется прекрасная возможность потребовать бессмысленных изменений, которые только создадут для жертвы лишнюю работу.
Прописаны ли у коллеги корректные подсказки типов данных для методов из класса модульных тестов? Нет?! Обязательно скажите ему добавить void, чтобы в будущем все знали, что у модульных тестов нет никаких возвращаемых значений. Не найдется ли у него каких-нибудь слишком навороченных названий переменных? Найдется? Пусть переименует во что-то менее навороченное. В руководстве ничего не говорится об условиях Йоды? Посмотрите, как прописано в коде, и потребуйте сделать ровно наоборот. По максимуму используйте стандарты стиля, чтобы растоптать врага.
Шаг второй: настаивайте на изменениях, которые ничего не меняют
Первым шагом можно вывести человека из себя, но чтобы разжечь в его душе ненависть, одного этого будет мало. Нужно продолжать свою миссию. И следующий ее этап – запросы на изменения, которые ничего не дадут.
Если существует два варианта реализации, требуйте, чтобы коллега переписал код в соответствии с тем, который нравится вам. Если он начнет приводить доводы – перечислять преимущества своего выбора, скажем, или недостатки вашего – не слушайте. От вас требуется только растянуть обсуждение о том, почему надо всё переписать, комментариев на двадцать. Если вы затрудняетесь с ответами, напишите что-то в духе нижеследующего, чтобы создать впечатление, будто это коллега ведет себя неразумно:
Не понимаю, зачем ты так упираешься из-за этого запроса. Способ, который я предлагаю, тоже рабочий. Переделай, пожалуйста. Спасибо.
Добейтесь того, чтобы коллега чуть не весь день потратил на переписывание кода, который и без того отлично выполнял свои функции.
Шаг третий: долгие перерывы
Не торопитесь с ответом. Обождите сутки, а лучше двое, прежде чем предпринимать любые действия, связанные с инспекцией кода. Если у вас потребуют объяснений, отговаривайтесь другими делами.
Этим вы преследуете конкретную цель: pull request должен успеть устареть. Открытые pull request-ы считаются техническим долгом, потому что на их поддержку требуется ресурс. Работа это неприятная и утомительная. Поэтому тянуть резину нужно до последнего, чтобы у коллеги масса времени уходила на то, чтобы устранять конфликты слияния.
Есть хороший способ воплотить этот план в жизнь: отказывайтесь работать с pull request-ами, у которых обнаружились конфликты слияния. Ведь код после такого конфликта может измениться, так зачем вам тратить время на инспекцию, если после устранения придется проверять его еще раз? Такая тактика отлично работает на замедление.
Если коллеге не приходится два-три раза устранять конфликты слияния у каждого pull request-а, значит, вы реагируете слишком быстро.
Шаг четвертый: требуйте внедрить баги
Запросы на изменения сами по себе хорошо добавляют работы, однако запросы на изменения, которые дадут негативные побочные эффекты, справляются с этим в разы лучше. Сначала коллеге придется приложить усилия, чтобы переписать код, а потом, когда баг обнаружится и выставит его дураком, ему придется еще потрудиться, чтобы всё исправить.
Шаг пятый: исправляйте стиль в запросах на инспекцию кода
В каждом pull request-е, который вы отправляете своему врагу на проверку, добрая половина изменений должна состоять из бессмысленных исправлений стиля, о которых вас никто не просил. Отыскать реальные изменения, влияющие на функциональность, должно быть как можно сложнее, тогда человек скорее просто даст всему сразу отмашку вслепую.
Шаг шестой: создавайте огромные pull request-ы
Проверять код легко, когда в нем от десяти до тридцати срок. Но вам не нужно, чтобы было легко. Вам нужно, чтобы людей охватывал страх, когда от вас поступает запрос на инспекцию. А значит, все pull request-ы должны содержать по тысяче переработанных строк в десяти файлах, не меньше.
При этом настаивайте, чтобы ваши запросы обрабатывались быстро. Это же технический долг, вы что, должны тратить своё время на устранение конфликтов слияния? Докапывайтесь до всех подряд, пока ветку наконец не сольют с основной кодовой базой. Если кто-то начнет огрызаться, что сами вы, мол, не торопитесь с чужими запросами, не поддавайтесь. Объясните им, что ваши запросы гораздо важнее, и без устали твердите, что пока pull request открыт, у команды копится технический долг.
Шаг седьмой: пренебрегайте комментариями
Итак, вы отправили код на проверку и нудите, как описано выше. Возможно, с вами захотят сквитаться по этому поводу. Но против попыток нанести ответный удар в ходе инспекции есть хороший прием – просто не обращайте внимания. От вас требуют каких-то изменений? Попросите приятеля всё одобрить как есть и провести слияние, а комментарии пропустите мимо ушей.
Не позволяйте людям вставать у вас на пути со своей обоснованной критикой. Пусть их замечания стекают с вашего pull request-а, как с гуся вода.
Заключение
Если последовательно, раз за разом осуществлять эти шаги в течение нескольких месяцев, ваши враги раскаются во всех воображаемых обидах, которые вы от них терпели.
А вот чего делать нельзя, чтобы они ненароком не получили от инспекции удовольствия:
- автоматизировать всё, связанное со стилем, чтобы оно не требовало вмешательства;
- просить внести изменения только в том случае, если они дадут какие-то преимущества по сравнению с текущей версией;
- быстро реагировать на запросы и выделять в дневном расписании время строго на инспекцию;
- при запросе изменений убеждаться, что код будет соответствующим образом протестирован;
- внедрять новые стандарты стиля в отдельных pull request-ах;
- создавать небольшие pull request-ы для инспекции и отправлять их через короткие промежутки времени;
- отвечать на все замечания, либо согласием, либо объяснением, почему не согласны.
