Как сказать коллеге, что он допустил массовую ошибку программирования?

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

Есть несколько путей потенциального снижения:

1. Просто прямо скажите ему, что есть ошибка — дружеский подход может не сработать, так как он заметил, что вы «вмешиваетесь в его дела». Так что, если вы скажете, что я нашел ошибку из-за X, то он может ее решить.
2. Попытка внедрить проверки кода . Если у вас есть свобода реализации рабочих практик, предложите своей команде выполнять проверку кода при каждой регистрации. Таким образом, вы сможете просмотреть этот чекин и указать на ошибку в обзоре.

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

Все делают ошибки, указывать на ошибки в чьем-то коде — все равно, что указывать на то, что у вас был кашель. Это вполне естественно, как бы хорошо мы ни готовились, вы не сможете избежать этого на 100%, поэтому это не должно быть табу.

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

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

Мы нашли ошибку в A после последнего патча, нам нужно исправить C, D. Чтобы избежать подобных ошибок в будущем, я думаю, было бы хорошей практикой делать X, Y, вы согласны? Если нет, что, по вашему мнению, мы можем сделать по-другому, чтобы избежать этого?

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

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

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

1. Зарегистрировать ошибку
2. Сделать тестовый пример
3. Исправьте ошибку. Сохраните тестовый пример в качестве доказательства
4. Исправить связанные проблемы

Нас это сейчас не волнует, вы должны сосредоточиться на X

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

Поговорить с коллегой, конечно, лучше всего, мой ответ дает альтернативу идеалу.

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

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

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

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

Просто скажи ему это прямо.

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

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

Я чувствую... когда ты... я хочу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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