Как я могу взять на себя ответственность за мой код, когда коллега делает ненужные улучшения без уведомления?

Один из моих товарищей по команде является мастером на все руки в нашем IT-магазине, и я уважаю его понимание.

Однако иногда он просматривает мой код (он занимает второе место в команде лидера нашей команды, так что это ожидаемо) без единого мнения. Поэтому иногда он просматривает мои изменения, прежде чем они достигнут конечной цели, и сразу же вносит изменения ... и однажды даже сломал мою работу.

В других случаях он делал ненужные улучшения для моего кода, которому более 3 месяцев.

Это раздражает меня по нескольким причинам:

1. Мне не всегда дают возможность исправить свои ошибки
2. Он не нашел время, чтобы спросить меня, что я пытался сделать, когда он в замешательстве, что может повлиять на его тестирование или изменения
3. Я не всегда думаю, что его код читается
4. Сроки не являются проблемой, и его текущая рабочая нагрузка не требует никакой работы в моих проектах, кроме проверки изменений моего кода.

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

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

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

Добавлены уточнения:

• У нас есть 1 ветка разработки. Я не жду, пока все мои изменения завершат одну задачу, потому что я рискую потерять какую-то значительную работу - поэтому я проверяю, что мои изменения строятся и ничего не нарушают.
• Меня беспокоит то, что мой товарищ по команде не объясняет причину или цель его изменений. Я не думаю, что ему нужно мое благословение, но если мы не согласимся с подходом, я подумал, что было бы лучше обсудить плюсы и минусы и принять решение, как только мы оба поймем, что происходит.
• Я еще не обсуждал это с руководителем нашей команды, так как я бы предпочел разрешать личные разногласия без привлечения руководства, если в этом нет необходимости. Поскольку моя забота казалась скорее личной проблемой, чем угрозой нашей работе, я решил не беспокоить руководство команды. Я работаю над идеями процесса проверки кода - чтобы помочь продвигать преимущества более организованных проверок кода, не делая все это о моих любимых мозолях.

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

Для меня предотвращение конфликта в этой ситуации сводится к двум вещам:

1. Предоставлено . Разговор с кем-то о его / ее коде позволяет разработчику знать, что вы заинтересованы, и вы можете обсудить это как взрослые профессионалы.

2. Забудьте о «владении кодом» - команда владеет кодом . Другие люди, желающие внести изменения, - это хорошо. Если старший разработчик вносит изменения, которые «нечитабельны» или хуже, отмените их. Вам не нужно быть агрессивным, просто дайте редактору понять, что его / ее изменения не сработали, и вы более чем счастливы обсудить ваше возвращение.

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

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

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

Кроме того, вы упоминаете, что ваш коллега вносит изменения сразу же. Это тоже неправильно, но, конечно, вы уже это знаете; Вы бы не задавали этот вопрос, если бы его подход к фанатикам не был проблемой. Однако я думаю, что вы ищете решение не в том месте. Честно говоря, ваш коллега немного напоминает мне ... меня, и то, что мне помогало в подобных ситуациях, было четко определенным и надежным процессом проверки и набором замечательных инструментов. Вы не хотите, чтобы ваш коллега пересматривал ваш код и просил его остановиться и поговорить с вами до того, как каждое небольшое изменение не сработает. Возможно, какое-то время, но он скоро достигнет точки, когда это станет слишком раздражающим, и вы вернетесь к тому, с чего начали, или, что еще хуже, он просто перестанет просматривать ваш код.

Ключом к решению здесь может быть инструмент рецензирования кода. Я обычно избегаю рекомендаций по продукту, но для рецензий на код Atlassian's Crucibleдействительно спасатель жизни. То, что он делает, может показаться очень простым, и это так, но это не значит, что это не удивительно. Он подключается к вашему хранилищу и дает вам возможность просматривать отдельные наборы изменений, файлы или группы файлов. Вы не можете изменить код, вместо этого вы комментируете все, что не совсем правильно. И если вам абсолютно необходимо изменить чужой код, вы можете просто оставить комментарий с набором изменений, объясняющий ваши изменения. Вступительное видео на странице продукта Crucible стоит посмотреть, если вы хотите больше подробностей. Ценообразование Crucible не для всех, но существует множество свободно доступных инструментов рецензирования. Один из них, с которым я работал и который мне понравился - это Board Review, и я уверен, что вы найдете много других с помощью простого поиска Google.

Какой бы инструмент вы ни выбрали, он полностью изменит ваш процесс. Не нужно останавливаться, встать со стула, перебить другого человека и обсудить изменения; все, что вам нужно сделать, это установить какое-то время в неделю и просматривать комментарии (один раз в неделю это всего лишь предложение. Вы знаете свой график и распорядок дня лучше, чем я). Более того, основные обзоры хранятся где-то в базе данных, и вы можете получить их в любое время. Это не эфемерные дискуссии вокруг кулера с водой. Мой любимый вариант использования старых обзоров - это представление нового члена команды в нашей базе кода. Всегда приятно, когда я могу вывести кого-то нового через базу кода, указывая, где именно мы застряли, где у нас были разные мнения и т. Д.

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

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

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

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

Что в этом процессе заставляет вас брать на себя ответственность за «свой код»? Вы несете единоличную ответственность за поддержание работы определенных функций? Ведущий сказал: «Майкл, я хочу, чтобы ты взял на себя ответственность за ...»? Или ваша ответственность подразумевается в том, что лидерство и остальная часть команды смотрят на вас каждый раз, когда нарушаются определенные функции?

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

Не то чтобы это решило всю ситуацию, но вы можете попробовать добавить больше комментариев к вашему исходному коду.

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

И все, попробуйте приготовить лимонад, а не тратить время на сосание лимонов. Как сказал Майкл, в общем, товарищи по команде не из-за того, что ты плохо выглядишь. Постарайтесь учиться на своих ошибках и применять их в будущих ревизиях.

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

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

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

Хороший сотрудник будет поддерживать связь с вами и указать на проблемы с вашим кодом для вас - и пусть вам исправить / изменить его, или реагировать соответствующим образом . Я очень благодарен, что даже когда я был новичком, мои наставники всегда указывали мне, что я делаю неправильно, объясняли, почему, и позволяли (или заставляли ) это исправить. Это сделало меня лучшим программистом, и все получили пользу. И это то, что я всегда делал при рассмотрении работы, выполненной другими. Тогда вы (или кто-то еще) действительно узнают что-то от своего «мастера на все руки», и код и команда все поправляются, включая вашего учителя: обучение помогает пониманию.

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

Если вы пишете код, то я должен пересмотреть его.

Если я изменю ваш код во время проверки, то это уже не код, который я проверял, а код, который я изменил. Поэтому это необходимо пересмотреть. Вероятно, вами.

Если я зафиксирую ваш новый код с моими изменениями, а кто-то не просмотрит мои изменения, то я совершу (1) непредвиденное изменение и (2) наихудший возможный грех, если проверки кода будут восприняты всерьез.

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

Если бы я был на вашем месте, я бы попросил вас поговорить один на один с этим человеком и спокойно, но твердо объяснить мое ПО. Владение кодом команды и т. Д. - это нормально, но если вы не предоставите каждому разработчику достаточно места для выполнения своей работы, ошибок и улучшений, вы никогда не создадите хороший код. Это может быть область трения раньше, чем позже.

(Существует совершенно другой ответ, если бы он был на workplace.stackexchange. Найти правильный способ проверки кода - это очень просто. Убедить вашего коллегу выполнить это гораздо сложнее).