Должен ли я сказать кому-то, что их совершение вызвало регресс?

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

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

Если это хорошая идея, чтобы сказать им, что это хорошие способы сделать это, не вызывая обиды или не заставляя их защищаться?

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

115 голосов | спросил 11 revs, 3 users 47%
Scott
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

17 ответов


37

Если вы просто подходите к ним, чтобы рассказать им о той ошибке, которую они совершили, если вы не лучший дипломат в мире, это будет трудно для нее не просто звучать как «Ха!» - посмотрите на эту ошибку, которую вы сделали! » , Мы все люди, а критиковать трудно.

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

  

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

Тогда либо:

  

Им: Конечно, thats для обработки ... ситуации, о которой я не знал ...

Или что-то вроде строк:

  

Им: Нет, жаль, что я не помню, выглядит неправильно.

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

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

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
170

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

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

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
70

Да, всегда . Как программист, ваша работа - учиться на ошибках.

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
23

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

Если речь идет о том, чтобы объяснить людям, как не вводить ошибки, ищите их.

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
19

В общем, да .

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

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

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

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

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
6

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

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
5

Здесь вы получаете отличные ответы.

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

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

Она сказала мне почти извиняющимся тоном, что, похоже, проблема, и у меня будет время посмотреть на нее?

Довольно часто ошибка была моей, и она это знала. Это умение.

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
5

Я думаю, что в этом вопросе есть более глубокая проблема. Да, заявителю следует, конечно же, узнать о последствиях их изменений, чтобы они могли понять, что произошло, а не повторять то же самое. Тем не менее, контекст вашего вопроса указывает, что you подготовил и отправил исправление без знания исходного сообщения, что они даже вызвали проблему. В этом и заключается более глубокая проблема: почему заявитель уже не знает о регрессии и , почему они сами не исправились? Описанная ситуация может указывать на отсутствие подотчетности или бдительности со стороны первоначального заявителя, что является потенциальной проблемой в отношении их общей эффективности и мотивации.

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

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
4

Хорошее отношение к вашему вопросу! Все говорят вам, что делать. Вы должны сказать? ДА! В любое время вопрос спрашивает: «Должен ли я больше общаться?», Ответ почти всегда ДА!

Но добавить что-то другое: ваша предпосылка испорчена.

  

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

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

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

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
2

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

Скажите им, когда его только двое.

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
2

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

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
2

В дополнение к тому, что говорили другие, убедитесь, что это НАСТОЯТЕЛЬНО их фиксация, которая вызвала ошибку. Конечно, не обвиняйте кого-то другого в вашей собственной ошибке. Независимо от того, насколько тактично вы к ним приближаетесь, вы все равно будете мочиться, если вы обвинили их в чем-то, чего они не делали. (Говоря как кто-то, кто постоянно обвинялся в чужих ошибках, один раз кто-то подошел ко мне и сказал, что я сделал что-то совершенно глупое, и я поднял журнал фиксации и обнаружил, что последним, кто коснулся этой строки кода, был кто-то обвинял меня. Как-то он все еще думал, что это моя вина, потому что я написал эту статью изначально.)

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
2

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

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

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

Я обычно нахожу, что он работает лучше всего, когда вы начинаете с комплимента, а затем переходите к ошибке ... что-то вроде «исправление, которое вы внедрили, отлично работает, НО оно, кажется, сломало x, y, z» или «спасибо для выполнения a, b, c, BUT, похоже, вызывает x, y, z "

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
2

Простой ответ: Да.

Дольше ответ: Моя последняя работа была в компании Agile, которая использовала TDD с инструментами CI, чтобы гарантировать, что то, что было в нашем SVN-репо, было хорошим, рабочий код всегда. Когда что-то было совершено, наш сервер TeamCity получил копию, скомпилировал и выполнил модульные тесты. Он также проводил интеграционные тесты ежечасно. Если что-то было совершено, что привело к сбою CI, все получили электронное сообщение о том, что сборка была нарушена на основе фиксации определенным человеком.

Это не всегда ломало все; к сожалению, мы не применяли покрытие кода, и даже если что-то было уделено экзаменам на единицу или интеграцию, они могли бы не осуществлять этот код достаточно. Когда это произошло, кто-то, кто поставил задачу решить известную проблему (если QA поймал ее) или дефект (если, dun-dun-dun, клиенты сделали), запустит «вину» (показывает, кто последний модифицировал каждую строку файл кода) и определить виновника.

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
2

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
1

В игре много факторов.

  • Насколько серьезной является ошибка?
  • Каковы отношения старшинства между вами и нарушителем?
  • Как занят /стресс из команды?
  • Был ли выключатель работать в своей части кода или вашей?
  • Насколько вы уверены, что это настоящая ошибка, и насколько уверены, что ваше исправление верно?

Если проблема была незначительной - опечатка /thinko /cut & пасту, а прерыватель - занятый сверстник, и вы уверены в своей оценке проблемы, вам, вероятно, не нужно привлекать его к их вниманию. (например, foo.x = bar.x; foo.y = bar.y, foo.z = bar.y).

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

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

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
1

Что произойдет, если вы не скажете им?

Концы

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

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

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

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

Профи

Люди не смущаются и не раздражаются, указав свои ошибки.

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50

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

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

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