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


71

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

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

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

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

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

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

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

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

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

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

20
Используете ли вы git, CVS или TFS для своего репо кода? Просто откат его коммитов. Он получит это в конечном счете :)

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

13
Почему у вас есть незавершенные изменения в общей ветке? Это плохая идея, и не только по той причине, с которой вы столкнулись.
Hyde

15
Конечно, это зависит от того, какую VCS вы используете, но это может быть чем-то, на что стоит обратить внимание, начиная больше использовать ветки. С персональной ветвью, IMO замечательно, когда вы можете фиксировать (и передавать с DVCS) всякий раз, когда вам хочется, не беспокоясь, и сливаться только тогда, когда сделано с деталью, или сливаться только частично, когда это необходимо (хороший DVCS делает это довольно легко). Также отлично работает с обзором кода, способным естественным образом сделать это и исправить проблемы перед слиянием.
Hyde

4
@Jesslyn - Ваш руководитель вообще обеспокоен тем, что ваш напарник тратит время на ненужные улучшения старого кода? По крайней мере, кажется, что ваш товарищ по команде неэффективно тратит время на внесение ненужных изменений, а не на работу с более приоритетными задачами. Кроме того, если ваш товарищ по команде предпочитает тратить время на «исправление» вашего кода, а не на то, чтобы дать вам возможность сделать это самостоятельно, это также кажется довольно неэффективным. Обсуждали ли вы какие-либо из этих проблем с руководителем вашей команды?
Утес

Ответы:


81

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

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

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

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

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


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

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

7
@Jesslyn, если он делает это с тобой, скорее всего, он делает это со всеми. Я сомневаюсь, что кто-то считает это против тебя. (Если он не делает это со всеми, у вас может быть другая проблема)
user606723

3
@tgkprog: (1) Конечно, очень важно получить обратную связь от других, и я узнал кое-что из просмотра кода других, но (2) если вы хотите учиться друг у друга, вы должны предложить изменение и обсудить это вместе. , Просто менять случайные вещи, потому что вы думаете, что код лучше после изменения, - неправильный подход. Существуют лучшие подходы, такие как проверка кода с использованием инструментов обзора.
Джорджио

2
да, я думал о случаях, когда я исправлял код других пользователей до 11:00, но даже тогда отправлял письмо команде, чтобы они тоже могли это проверить, включая наш QA ....
tgkprog

86

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

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

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

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

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

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

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

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

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


7
+1 и больше, если бы я мог. Отличный ответ, который касается лучших способов улучшить такой процесс.
Вальдфи

2
Да, OP нуждается в инструменте проверки кода, чтобы вы могли просматривать код вместе, это не просто кто-то меняет код, потому что ему это нравится. Мы только начали использовать smartbear.com/products/software-development/code-review на работе
Хуан Мендес,

19

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

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


5
+1 За указание на важный факт: либо существует групповое владение, и (1) все несут ответственность (2) каждый может изменить код, либо существует индивидуальное право собственности и (1) владелец модуля несет ответственность (2) каждое изменение должно быть одобрено владельцем модуля. Часто возникает путаница, когда член команды должен нести ответственность за модуль, но старший член чувствует себя вправе вносить случайные изменения в код. Другими словами, нужно избегать ситуации «ответственность без власти».
Джорджио

4

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

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

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

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


3
Мальчик, который может запутаться. Представьте себе - добавьте комментарий, в котором говорится: «Этот код не завершен», а затем забудете удалить его после завершения кода.
riwalk

1
@ Stargazer712, более запутанно, чем иметь неполный код в ветке?
user606723

Для этого и нужны наборы полок. Не проверяйте неполный код.
riwalk

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

1
Их называют TODO, они все время остаются в рабочем коде
Хуан Мендес

4

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

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

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

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


1
Помимо первоначального утверждения (есть команды, которые принимают групповое владение, и другие команды, которые принимают индивидуальное владение), я нахожу замечания в этом ответе ОК (+1 для этого): я также наблюдал, как владение общим кодом использовалось, чтобы подорвать команду положение участника в команде путем произвольного изменения их кода. Поэтому я не понимаю, отрицательные голоса. Было бы хорошо, если бы downvoters хотел объяснить.
Джорджио

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

1
@Jesslyn - я полагаю, что за меня проголосовали из-за моего утверждения «каждый косвенно« владеет своим собственным кодом »». Это философский вопрос, а не политический вопрос. :-)
Вектор

1
@Mikey: «Каждый косвенно« владеет своим собственным кодом »». Конечно, это может быть предметом споров. Программисты, которые не работают не по найму, обычно подписывают контракт, в котором говорится, что они не владеют исходным кодом. Кроме того, я думаю, что автор кода - это тот, кто лучше всех понимает код, и если кто-то еще изменит код, то ни автор, ни второй разработчик действительно не поймут код на 100%.
Джорджио

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

1

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

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

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


0

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.