Ответственность за воспроизведение ошибок

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

1. Он прав?
2. Что я могу сделать в этой ситуации? Создание модульного теста невозможно, поскольку оно зависит от некоторых случайных временных интервалов сети.

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

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

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

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

Но - он ИМХО на 100% неправ, что это должно быть в форме юнит-теста. Если вы можете описать тестовый сценарий таким образом, чтобы он мог воспроизвести сбой (по крайней мере, с большой вероятностью в разумный промежуток времени или путем ручного тестирования), у вас есть доказательство того, что проблема существует - что должно установить ваш коллега в ответственности, чтобы исправить это. Конечно, если вам удастся создать сценарий, который будет воспроизводить ошибку быстрее, это будет полезно для него. В идеале можно было бы сделать из этого автоматический тест, и это зависит от вашей организации, которая несет ответственность за это.

Обе стороны должны приложить некоторые усилия.

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

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

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

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

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

Это означает, что вы действительно несете ответственность за разработку воспроизводимого контрольного примера, ЕСЛИ ВЫ ХОТИТЕ ИСПРАВЛЕНО. Вам может быть все равно, будет ли это исправлено, и в этом случае вы сделали все, что можно и нужно от вас ожидать. Возможно, вы захотите исправить это, но этого недостаточно для того, чтобы посвятить время воспроизведению. Это вполне приемлемо.

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

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

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

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

Вы нашли ошибку, вы сообщили об этом, и он был придурком по этому поводу.

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

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

Зарегистрируйте как можно больше информации в трекере ошибок и продолжайте.

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

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

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

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

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

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

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

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

Если это не работает, у вас есть следующие варианты:

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