Должен ли программист исправить чью-то неудачную сборку? [закрыто]

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

Второй программист поступил правильно, или он должен был просто подождать, пока первый программист не исправит проблему?

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

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

По-разному.

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

• Находится ли проект на этапе, когда все изменения должны быть связаны с существующим тикетом? Если так, вы подали билет? Этот билет был назначен вам?

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

Да, все в порядке. Тем не менее, оригинальный программист непрофессионален, прежде чем тестировать, будет ли компилироваться сборка.

Ваша репутация на 100% под вашим контролем. Подобные вещи бросают тень на вашу репутацию, и попытка отравить запятнанную репутацию очень сложно.

сообщаться

Для этого сценария нет строгих правил (помимо правил вашей команды).

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

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

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

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

Мой девиз: не связывайтесь с SVN после 3 часов дня, чтобы вы всегда могли исправить свои ошибки сборки.

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

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

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

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

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

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

Как правило, правило таково: вы нарушаете сборку - вы исправляете сборку, но есть исключения, особенно если исправление очевидно и / или ответственное лицо недоступно.

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

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

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

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

Это нормально, если это не обычное явление, в этом случае я бы попросил, чтобы босс позвонил ему и заставил его вернуться и исправить это сам.

Это зависит, это зависит ...

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

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

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

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

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

Во-первых, «пошел домой» - это анахронизм. Программисты больше не идут домой - они просто онлайн или офлайн. Вы могли бы пинговать и ждать.

Более серьезно, на самом деле есть две части вопроса. «просматривать изменения кода» - это нормально; отдых не может быть правильным. Что если его суждение о пропавшей библиотеке было неверным?