Что делать, если другой разработчик испортил проект?

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

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

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

Спокойно поговорить с ним об этом должно быть первым шагом, ведь вы же коллеги.

Я должен думать, что менеджеру достаточно контроля версий или другой видит, кто запорол проект?

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

Или я должен поговорить с ним, спросив об изменениях, которые он сделал?

Говорить с ним. Не вините его. Укажите, почему он сломан, а затем спросите: «Как мы можем это исправить?» Подчеркните, что все, о чем вы заботитесь, — это довести проект до конца.

Я новичок в этой компании, и он тоже. Но он, кажется, менее опытен, чем я.

Ну и что? Это не соревнование. Будут другие, более опытные, чем вы.

Говорить с ним. Не бегите к менеджеру, когда что-то не строится.

Вы уверены, что ваша среда настроена правильно? Есть ли вероятность, что вы что-то упустили? Дважды проверьте, прежде чем обращаться к коллеге. Когда вы обратитесь к нему, я предлагаю сформулировать вопрос как просьбу о помощи в создании проекта.

Что-то вроде «Я удалил репозиторий, но он не собирается. Я не уверен, что я что-то неправильно настроил, не могли бы вы мне помочь?»

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

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

Как я могу справиться с этим?

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

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

Поговорите с ним один на один об изменениях. Посмотрите, не является ли это проблемой конфигурации с вашей стороны. Если это так, проблема решена.

Если нет, посмотрите, как вы можете использовать рабочий процесс, чтобы этого больше не повторилось.

Изучив, как включить обзоры и автоматические сборки в вашей текущей системе, обратитесь к техническому руководителю. Скажи что-нибудь вроде

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

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

Шаг 1: Поговорите с ним. Упомяните, что сборка сломана, и последняя фиксация в ней была его фиксацией, поэтому спросите его, что произошло (важно не говорить «вы сломали сборку!», потому что а) это обвинение и б) возможно, его изменение на самом деле не было изменение, которое сломало сборку, например, может быть, это было изменение конфигурации, или, может быть, вы забыли об изменении, которое вы сами внесли, и т. д., и в этом случае вы выглядите очень резким и обвиняющим).

Шаг 2: Если он воспримет ваше заявление, поработайте с ним, чтобы исправить это, а если он не понимает, что пошло не так, объясните ему это. Объяснение ему этого научит его, как не совершать ту же ошибку снова. Это называется наставничество и очень важно среди коллег, особенно более опытных (по отношению к менее опытным). Ваше начальство будет высоко ценить вас, если вы сможете продуктивно участвовать в наставничестве.

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

Шаг 3: В следующий раз, когда этот конкретный коллега сломает сборку, промойте и повторите. Если это происходит несколько раз, и вы чувствуете, что это образец безответственности, вы можете пойти к своему менеджеру и сказать: «Привет, Боб, ты знаешь, что Джо несколько раз нарушал сборку, и я пытался поговорить с ним о это, но, похоже, ему все равно, не могли бы вы поговорить с ним об этом?» или что-то вроде того. Не впадайте в агрессию или обвинение; сделать вопрос о поломке сборки, а не о коллеге. Ваш менеджер решит, как лучше действовать дальше.

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

Некоторые серверы сборки могут даже обслуживать созданные артефакты, если это необходимо.

Если у вас его нет, получите его. Хорошим местом для начала является Jenkins, с которым очень легко начать.

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