Ви та більшість відповідачів підходите до цього як до питання спілкування двох колег, але я не думаю, що це так. Те, що ви описуєте, більше нагадує жахливо порушений процес перегляду коду, ніж будь-що інше.
По-перше, ви згадуєте, що ваш колега займає друге місце, і очікується, що він перегляне ваш код. Це просто неправильно. За визначенням, рецензування експертного коду не є ієрархічною, і вони, звичайно, не стосуються лише пошуку дефектів. Вони також можуть забезпечити досвід навчання (для всіх учасників), можливість соціальної взаємодії та довести цінний інструмент для побудови колективного володіння кодом. Ви також повинні час від часу переглядати його код, вчитися у нього і виправляти його, коли він помиляється ( кожен раз це не робить правильно ).
Крім того, ви згадуєте, що ваш колега вносить зміни відразу. Це теж неправильно, але ви, звичайно, це вже знаєте; Ви б не ставили цього питання, якби його підхід до гун-хо не був проблемою. Однак я думаю, що ви шукаєте рішення в неправильному місці. Якщо чесно сказати, ваш колега трохи нагадує мені ... мене, і те, що працювало для мене в подібних ситуаціях, було чітко визначеним і ґрунтовним процесом огляду та набором дивовижних інструментів. Ви насправді не хочете зупиняти колегу від перегляду вашого коду, і просите його зупинитися і поговорити з вами до того, як кожна маленька зміна насправді не спрацює. Можливо, на деякий час, але незабаром він досягне того моменту, коли це стане занадто дратує, і ви повернетесь туди, де ви почали, або ще гірше: він просто перестане переглядати ваш код.
Ключовим рішенням тут може бути інструмент перевірки коду експертного коду. Зазвичай я уникаю рекомендацій щодо продуктів, але для кодових оглядів Atlassian's Crucibleнасправді рятувальник життя. Те, що це робиться, може здатися дуже простим, і воно є, але це не означає, що це не надзвичайно дивовижно. Він підключається до вашого сховища і надає вам можливість переглянути окремі набори змін, файли або групи файлів. Ви не можете змінити жодний код, натомість коментуєте все, що не дуже добре. І якщо ви абсолютно повинні змінити чужий код, ви можете просто залишити коментар із набором змін, що пояснює ваші зміни. Вступне відео на сторінці продукту Crucible варто переглянути, якщо ви хочете отримати більше деталей. Ціни на тиглі не для всіх, але є численні вільно доступні інструменти експертної оцінки. Один, з яким я працював і мені подобається, - це Board Board, і я впевнений, що ви знайдете багато інших за допомогою простого пошуку в Google.
Який би інструмент ви не вибрали, він повністю змінить ваш процес. Не потрібно зупинятися, вставати з крісла, перебивати іншого та обговорювати зміни; все, що вам потрібно зробити, це встановити деякий вихідний час щотижня і переглядати коментарі (раз на тиждень - це лише пропозиція. Ви знаєте свій графік і розпорядок дня краще, ніж я). Що ще важливіше, що основні огляди десь зберігаються в базі даних, і ви можете їх отримати будь-коли. Вони не є ефемерними дискусіями навколо охолоджувача води. Мій улюблений випадок використання старих оглядів - це представлення нового члена команди в нашій кодовій базі. Завжди приємно, коли я можу пройти когось нового через базу коду, вказуючи, де саме ми застрягли, де у нас були різні думки тощо.
Продовжуючи, ви зазначаєте, що не завжди знайдете код цього колеги читабельним. Це дає мені знати, що у вас немає загального набору стандартів кодування, і це погано. Знову ви можете підходити до цього як до проблеми людей, або ви можете підходити до цього як до проблеми процесу, і я знову настійно пропоную останню. Зберіть свою команду та якомога швидше прийняти загальний стиль кодування та набір стандартів. Не важливо, ви вибрали набір стандартів, який є загальним у вашій екосистемі розвитку, або ви придумали свій власний. Що насправді важливо, щоб ваші стандарти були узгодженими і ви їх дотримувались. Багато і багато інструментів там можуть допомогти вам, але це зовсім інша дискусія. Просто для початку, Дуже просто зробити, це запустити гачок, який попередньо здійснює, запустити якийсь формат форматів у вашому коді. Ви можете продовжувати писати свій код, скільки завгодно, і дозволити інструменту "виправити його" автоматично, перш ніж хтось його побачить.
Нарешті, у коментарі ви зазначаєте, що керівництво не вірить, що окремі гілки розробників необхідні. Що ж, є причина, що ми називаємо їх "галузями розвитку", а не "галузями управління". Я зупинюсь тут, оскільки немає причин, щоб гнів, який формується в моїй голові, вийшов.
Все, що сказано, знайте, що я не сумніваюся, що ваш колега тут (трохи) винен. Це не моя суть, я в тому, що весь процес розробки також винен, і це легше виправити. Озброїться належними інструментами, вивчіть численні формальні та неофіційні процеси та виберіть ті, які відповідають вашій команді. Незабаром ви досягнете точки, коли зрозумієте, що більшість ваших "проблем з людьми" вже не існує. І, будь ласка, не слухайте нікого (включаючи себе), який викликає виправдання "ми невелика команда, нам не потрібно все це". Команда компетентних розробників може встановити необхідні інструменти за менш ніж тиждень, автоматизувати все, що можна автоматизувати, і ніколи не озиратися знову.
PS. "Кодове володіння" - це неясний термін, який постійно дискутується, і він означає різні речі для різних людей. Ви можете знайти блискучу колекцію більшості різних (а іноді і антитетичних) думок щодо С2 .