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

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

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

180 голосов | спросил 6 revs, 5 users 53%
rajachan
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

23 ответа


302
  

Не извиниться!

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

Кроме того, я уверен, ваша команда не выполнила «Тест Joel» и не может сделать сборку в одном шаг.

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
180

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

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

Мне нравятся извинения со стороны. Вкусные, вкусные извинения.

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
79

Две кавычки для вас:

  

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

     

Любой, кто не ошибается, не пытается достаточно усердно .-- Wess Roberts

Я согласен с Jim G. , не извиняюсь, но учись у него и не делай повторить ту же ошибку ... сохранить ее СУХО;)

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
53

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

Мы назвали это Непрерывной Интеграцией Даки, и когда у вас это было в тот день, люди будут дразнить вас, но это было весело, ни один из них не должен был быть злым.

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
43

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

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

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

То есть, «Извините [EXPRESS REGRET], что я вас не устроил [ПРИНИМАЮ ОТВЕТСТВЕННОСТЬ] случайно [СОХРАНИТЬ ЛИЦА], нарушая сборку [СОСТОЯТЬ ПРОБЛЕМУ]. Пончики на меня завтра. [СДЕЛАТЬ ИЗМЕРЕНИЯ]"

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

Наконец, некоторые мысли о разрыве сборки:

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

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

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
15

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

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

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
10

Основное правило - когда вы ошибаетесь, ADMIT IT: - | Вам не нужно извиняться. Все совершают ошибки. Профессионалы признают это. Это командная работа. Остальные члены команды должны собираться вместе, чтобы помочь вам в этом. Если они этого не сделают, обратитесь за помощью. Самое большее, что нужно сказать после этого, - что мы можем извлечь из него?

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

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
6

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
5

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

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

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

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

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

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

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
2

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

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
2

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

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

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
2

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

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
2

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
1

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

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

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
1

Ошибка TEAM.

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

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

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

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
0

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

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

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
0

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

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

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
0

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

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

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

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

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
-1

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

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
-2

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

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

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
-2
  • Я бы не извинился.

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

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

  • Если локальная сборка не выполняется, тогда не должно быть разрешено вводить сервер сборки.

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
-2

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44
-2

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

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

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

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

ответил Tom Au 28 J0000006Europe/Moscow 2014, 01:50:44

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132