Вы и большинство отвечающих подходите к этому как к проблеме общения между двумя коллегами, но я не думаю, что это так. То, что вы описываете, больше похоже на ужасно сломанный процесс проверки кода, чем что-либо еще.
Во-первых, вы упоминаете, что ваш коллега занимает второе место в команде, и ожидается, что он пересмотрит ваш код. Это просто неправильно. По определению, обзоры одноранговых кодов не являются иерархическими, и они, конечно, не только об обнаружении дефектов. Они также могут предоставить учебный опыт (для всех участников), возможность для социального взаимодействия и являются ценным инструментом для формирования коллективного владения кодом. Вам также следует время от времени просматривать его код, учиться у него и исправлять его, когда он ошибается (никто не каждый раз понимает его правильно ).
Кроме того, вы упоминаете, что ваш коллега вносит изменения сразу же. Это тоже неправильно, но, конечно, вы уже это знаете; Вы бы не задавали этот вопрос, если бы его подход к фанатикам не был проблемой. Однако я думаю, что вы ищете решение не в том месте. Честно говоря, ваш коллега немного напоминает мне ... меня, и то, что мне помогало в подобных ситуациях, было четко определенным и надежным процессом проверки и набором замечательных инструментов. Вы не хотите, чтобы ваш коллега пересматривал ваш код и просил его остановиться и поговорить с вами до того, как каждое небольшое изменение не сработает. Возможно, какое-то время, но он скоро достигнет точки, когда это станет слишком раздражающим, и вы вернетесь к тому, с чего начали, или, что еще хуже, он просто перестанет просматривать ваш код.
Ключом к решению здесь может быть инструмент рецензирования кода. Я обычно избегаю рекомендаций по продукту, но для рецензий на код Atlassian's Crucibleдействительно спасатель жизни. То, что он делает, может показаться очень простым, и это так, но это не значит, что это не удивительно. Он подключается к вашему хранилищу и дает вам возможность просматривать отдельные наборы изменений, файлы или группы файлов. Вы не можете изменить код, вместо этого вы комментируете все, что не совсем правильно. И если вам абсолютно необходимо изменить чужой код, вы можете просто оставить комментарий с набором изменений, объясняющий ваши изменения. Вступительное видео на странице продукта Crucible стоит посмотреть, если вы хотите больше подробностей. Ценообразование Crucible не для всех, но существует множество свободно доступных инструментов рецензирования. Один из них, с которым я работал и который мне понравился - это Board Review, и я уверен, что вы найдете много других с помощью простого поиска Google.
Какой бы инструмент вы ни выбрали, он полностью изменит ваш процесс. Не нужно останавливаться, встать со стула, перебить другого человека и обсудить изменения; все, что вам нужно сделать, это установить какое-то время в неделю и просматривать комментарии (один раз в неделю это всего лишь предложение. Вы знаете свой график и распорядок дня лучше, чем я). Более того, основные обзоры хранятся где-то в базе данных, и вы можете получить их в любое время. Это не эфемерные дискуссии вокруг кулера с водой. Мой любимый вариант использования старых обзоров - это представление нового члена команды в нашей базе кода. Всегда приятно, когда я могу вывести кого-то нового через базу кода, указывая, где именно мы застряли, где у нас были разные мнения и т. Д.
Продолжая, вы упоминаете, что вы не всегда находите код этого коллеги читабельным. Это позволяет мне знать, что у вас нет общего набора стандартов кодирования, и это плохо. Опять же, вы можете подходить к этому как к проблеме людей или к процессуальной проблеме, и снова я настоятельно рекомендую последнее. Соберите свою команду и примите общий стиль кодирования и набор стандартов как можно скорее. На самом деле не имеет значения, выбрали ли вы набор стандартов, которые являются общими в вашей экосистеме разработки, или вы придумали свои собственные. Что действительно важно, так это чтобы ваши стандарты были последовательными и чтобы вы придерживались их. Вам может помочь множество инструментов, но это совершенно другое обсуждение. Просто чтобы начать, очень просто сделать, чтобы хук перед фиксацией запустил какой-то форматировщик стиля в вашем коде. Вы можете продолжать писать свой код так, как вам нравится, и позволить инструменту «исправить» его автоматически, прежде чем кто-либо еще его увидит.
Наконец, в комментарии вы упоминаете, что руководство не считает, что отдельные ветви разработки необходимы. Что ж, есть причина, по которой мы называем их «ветвями разработчика», а не «ветвями управления». Я остановлюсь здесь, потому что нет никакой причины, чтобы разглагольствовать, которая формируется в моей голове, чтобы выбраться.
Все, что сказал, знай, что я не сомневаюсь, что твой коллега (немного) виноват здесь. Это не моя точка зрения, моя точка зрения в том, что весь ваш процесс разработки также виноват, и это легче исправить. Вооружитесь надлежащими инструментами, изучите многочисленные формальные и неформальные процессы и выберите те, которые подходят вашей команде. Вскоре вы достигнете точки, когда вы поймете, что большинство ваших «проблем с людьми» больше не существует. И, пожалуйста, не слушайте никого (в том числе себя), который говорит: «Мы маленькая команда, нам не нужно все это», оправдание. Команда компетентных разработчиков может установить необходимые инструменты менее чем за неделю, автоматизировать все, что можно автоматизировать, и больше никогда не оглядываться назад.
PS. «Право собственности на код» - это туманный термин, постоянно обсуждаемый и означающий разные вещи для разных людей. Вы можете найти блестящую коллекцию большинства различных (и иногда противоположных) мнений о C2 .