Как извиниться, если вы нарушили ночную сборку [закрыто]

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

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

Не извиняйся!

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

Кроме того, держу пари, что ваша команда не прошла «тест Джоэла» и не может сделать сборку за один шаг.

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

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

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

Я люблю извинения коллег. Вкусные, вкусные извинения.

Две цитаты для вас:

Человек, который не делает ошибок, обычно не делает ничего .-- Уильям Коннор Мэги

Тот, кто не делает ошибок, не старается изо всех сил .-- Wess Roberts

Я согласен с Джимом Г. , не извиняйся, но учись у него и не повторяй ту же ошибку снова ... СУХОЙ;)

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

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

Мы взяли что-то вроде сломанной сборки и превратили ее в упражнение по построению команды.

"Извини, моя ошибка!" Я обычно извиняюсь, когда нарушаю сборку. Такое случается. Но, как говорили другие, это возможность улучшить ваши системы, чтобы один человек не мог так легко сломать сборку для всех остальных.

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

• Выразить сожаление.
• Обозначить проблему.
• Брать ответственность.
• Делать поправки.
• Сохранить лицо.

То есть: «Мне жаль [ЯВНО ВЫРАЖЕНО], что я доставил вам неудобства [ПРИНЯТЬ ОТВЕТСТВЕННОСТЬ] случайно [СОХРАНИТЬ ЛИЦО], нарушив сборку [СОСТОЯНИЕ ПРОБЛЕМЫ]. Пончики на мне завтра. [СДЕЛАТЬ ПОМОЩЬ]»

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

Наконец, несколько мыслей о нарушении сборки:

Я работаю в команде компилятора C # / Visual Basic. Конечно, сегодня Visual Studio - это настолько масштабный проект, что у него есть собственная команда, которая занимается только управлением инфраструктурой сборки, и огромная комната с собственной выделенной системой кондиционирования воздуха. Еще в середине 1990-х годов, когда я начинал в качестве стажера, команда по сборке Visual Basic была одним стажером - мной - и шкафом, полным машин. Времена изменились!

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

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

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

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

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

Фундаментальное правило - когда вы ошибаетесь, ОБРАЩАЙТЕСЬ: Вы не должны впадать в извинения. Все совершают ошибки. Профи это признают. Это командная работа. Другие члены команды должны собраться вместе, чтобы помочь вам в этом. Если нет, обратитесь за помощью. Самое большее, что нужно сказать потом, - что мы можем из этого извлечь?

Говорят, что успешный брак основан на трех маленьких словах: «Я был неправ».

Если кто-то не делает случайную ошибку, он не работает, но ошибка, на которой он не учится - две ошибки.

Самое лучшее извинение - это быстрое исправление разрыва

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

Если ваши коллеги осторожно тестируют свои изменения и ожидают найти разрывы в ночной сборке, то (C) у вас хрупкий процесс (и вам нужно ввести тестирование, подобное тому, которое можно найти в Extreme Programming).

Вполне возможно, что (D) Ваши изменения привели к непредвиденным изменениям в коде Билла, которые были либо ранее, либо изменены в той же сборке, что и ваша.

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

• (A) Я не прошел тест сборки, но проверил мои изменения. Извините, я изменяю свой процесс, поэтому я не буду делать это снова.
• (B) Я прошел тест сборки и добавил тест JUnit XYZtest.java, чтобы уменьшить вероятность повторного появления.
• (C) Поскольку у нас нет процесса тестирования сборки, я создаю его для своих изменений. Я хотел бы поделиться с вами, как мы можем улучшить наш процесс сборки.
• (D) Я буду работать с Биллом над написанием теста JUnit XYZtest.java, чтобы уменьшить вероятность повторного появления.

Я уверен, что есть (E), о котором я не думал.

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

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

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

Как подойти к этому, зависит от атмосферы в вашей группе. Если это культура вины, я бы очень внимательно отнесся к извинениям и как ты это делаешь. Если это совместная позитивная атмосфера, то да, что-то вроде: «Я все испортил, извините. Как мы можем избежать этого в будущем?» это, наверное, хорошая идея.

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

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

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

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

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

Как правило, я бы сказал:

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

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

КОМАНДА не удалась.

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

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

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

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

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

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

И да - не извиняйся. Просто поговорите с вашим менеджером и дайте ему понять, что вы узнали из того, что вы сделали.

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

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

Вы должны делать непрерывные сборки, а не ночные.

Лучше поздний ответ, чем никогда ...

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

Лично я вижу сломанную сборку как возможность.

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

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

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

Но да, не забудьте исправить это. Не ахти какое дело. Это не в производстве. Просто бесполезная ночь.

Обычная практика в моей компании:

• Кричать "это был не я!" (обычно CVS / SVN доказательства в противном случае)
• Носить футболку с надписью "my-userlogin ist Schuld!" (да, у 50% наших разработчиков такая рубашка)
• Утверждая, что он работает в локальном sendbox и все тесты пройдены просто отлично

У моей компании также есть хороший способ справиться с таким «инцидентом»:

• Работник должен носить следующий костюм в течение полдня ( http://www.tradoria.de/kostueme/kruemelmonster-sesamstrasse-kostuem-kruemelkostuem-337103661.html )

• Я бы не стал извиняться.

• Я бы обвинял CI-лидера в том, что он позволил мне совершить неправильную сборку.

• Должен существовать процесс CI, чтобы мешать разработчикам фиксировать испорченный код.

• Если локальная сборка завершается неудачно, то не следует разрешать вход на сервер сборки

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

Если вы работаете над проектом с открытым исходным кодом,

просто скажите "Извините, я сломал сборку. Может быть, я был слишком сонный!"

и добавьте его в качестве комментария github.

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