Разумно ли настаивать на воспроизведении каждого дефекта перед его диагностикой и устранением?


70

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

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

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

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

Разумно ли настаивать на воспроизведении каждого дефекта и отладке перед диагностикой и исправлением?

Или же:

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

Отладка для бабы?

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

И последнее, но не менее важное, если вы согласны со мной:

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


7
иногда нет смысла настаивать на воспроизведении, когда у вас есть журнал с трассировкой стека. Некоторые ошибки параллелизма в Java такие же, на самом деле самые простые из них возникают, когда вы получаете журнал с NPE и трассировку стека, указывающую на строку, которая «очевидно» использует некоторый объект, созданный с помощью new. И эти ошибки не гарантируются надежно воспроизводимыми в соответствии со спецификацией Java Memory Model
gnat,

5
Вы хотите получить «правильный» ответ - вы должны воспроизвести каждую ошибку, чтобы знать, что она исправлена, или ответ «держите клиента платящим нам $$» - иногда у вас нет времени и ресурсов для этого, и Ваш начальник ожидает, что вы используете свой опыт, чтобы приложить все усилия, чтобы все исправить?
KutuluMike


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

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

Ответы:


72

Разумно ли настаивать на воспроизведении каждого дефекта и отладке перед диагностикой и исправлением?

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

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

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

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

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

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

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


3
«Воспроизведение ошибки, ее исправление, а затем демонстрация того, что решение предотвращает повторное возникновение ошибки - вот где она должна закончиться». - Моя точка зрения точно
амфибия

2
«Потому что, если они никогда не воспроизводят ошибку, они не могут знать наверняка, что она исправлена». Аминь ...
Марьян Венема

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

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

1
@orip: анализ затрат / выгод также должен учитывать клиента: учитывает ли стоимость игнорирование клиента с возможным риском потери учетной записи (и, возможно, потери других клиентов из-за того, что они слышат от этого первоначального клиента, или если они также испытывают ошибку, но еще не сообщили о ней формально) перевешивают затраты времени разработчика, потраченного на воспроизведение и исправление ошибки?
FrustratedWithFormsDesigner

35

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

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


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

3
Если вы можете найти многопоточное состояние гонки с помощью проверки кода, вы должны иметь возможность последовательно воспроизводить его, изменяя код с помощью дополнительных операторов блокировки, которые заставляют потоки запускать / останавливать в последовательности, которая их запускает. ex Thread1-Запуск и пауза, thread2-Запуск и пауза, 1-начало с использованием общего объекта и пауза, 2-изменение общего объекта и пауза, 1-попытка с использованием общего объекта и barf. Самая большая проблема такого подхода заключается в том, что, хотя вы можете продемонстрировать это в отладчике, он не подходит для добавления в автоматизированный набор тестов. BTDT-ГТЦ.
Дэн Нили

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

27

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

Но ... Это не всегда возможно или даже физически возможно. Особенно с программным обеспечением типа «предприятие», где каждая установка уникальна. Там также оценка затрат / выгод. Несколько часов на просмотр кода и несколько образованных предположений о некритической проблеме могут стоить гораздо меньше, чем если бы команда технической поддержки потратила недели, пытаясь настроить и продублировать среду клиента именно в надежде на возможность дублировать проблема. Когда я работал в мире «Enterprise», мы часто просто выкладывали кодировщиков и заставляли их исправлять ошибки на месте, потому что не было возможности дублировать настройки заказчика.

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


11

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

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

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


5
«Однако не выпускайте реальное исправление без проверки.» Как? Если он не может воспроизвести условия, вызвавшие ошибку, как он воспроизведет их, чтобы проверить исправление? Кроме того, я не думаю, что OP не делал все возможное.
Тулаинс Кордова

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

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

4
@MichaelK: кажется, ваш ответ конфликтует сам с собой. Если вы не определили, что нужно сделать, чтобы воспроизвести ошибку, как вы узнаете, какими должны быть ваши тесты? Возможно, вам не всегда нужно воспроизводить ошибки самостоятельно, но большинство из этих случаев произойдет, когда шаги по воспроизведению уже известны. Если все, что у вас есть, это файл журнала без известных шагов, то у вас нет тестов для проверки.
Эллеседил

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

9

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

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

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

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

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

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


8

Разумно ли настаивать на воспроизведении каждого дефекта и отладке перед диагностикой и исправлением?

Я говорю да, с некоторыми оговорками.

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

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

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

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


6

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

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

Чаще всего то, что изначально выглядит как случайная ошибка, в конечном итоге имеет детерминированную причину, которая приводит к детерминированной воспроизводимости ошибки, когда вы знаете, как это сделать. Те, кто не поддается этому, истинные гейзенгики (кажущиеся случайными ошибки, которые исчезают при попытке проверить их в стерильной контролируемой среде), на 99,9% связаны со временем, и как только вы это поймете, ваш путь вперед станет более ясным; просмотрите вещи, которые могут потерпеть неудачу, если что-то еще может ввести слово по краям во время выполнения кода, и когда вы обнаружите такую ​​уязвимость, попытайтесь использовать ее в тесте, чтобы увидеть, демонстрирует ли оно поведение, которое вы пытаетесь воспроизвести.

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


4

Разумно ли настаивать на воспроизведении каждого дефекта и отладке перед диагностикой и исправлением?

Нет, это определенно не так. Это было бы глупой политикой.

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

  • отчеты об ошибках
  • сбои ( ошибки )
  • ошибки (также иногда называемые ошибками )

Отчет об ошибке - это сообщение об ошибке. Он говорит вам, что кто-то думает, что что-то не так. Это может или не может быть определенным о том, что должно быть неправильно.

Сообщение об ошибке свидетельствует о сбое.

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

Ошибка может быть вызвана ошибкой.

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

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

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

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


4
Если воспроизвести ошибку нецелесообразно, как вы узнали, что исправили ошибку? Независимо от того, насколько сложен способ воспроизвести ошибку.
BЈовић

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

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

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

3

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

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

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

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

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


3

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

Кроме того, как вы докажете им, что ошибка исправлена, если вы не можете повторить шаги?

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

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

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

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


3

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

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

Это исправило ошибку, которая вызвала сообщение об ошибке? Вы не можете быть на 100% уверены (возможно, две ошибки вызывали одну и ту же вещь), но это, вероятно, так и было.

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

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

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

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


Вы предполагаете, что код был моим с самого начала?
амфибия

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

1

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

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

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

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

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

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

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


1

Похоже, мне нужно более подробное ведение журнала.

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

Особенно в сложных / многопоточных ситуациях или в тех случаях, когда вы не можете использовать отладчик, использование «debug by printf ()» может быть вашим единственным выходом. В этом случае регистрируйте столько, сколько сможете (больше, чем вы ожидаете), и используйте несколько хороших инструментов для фильтрации пшеницы от соломы.


1

Разумно ли настаивать на воспроизведении каждого дефекта и отладке перед диагностикой и исправлением?

Так как никто еще не сказал это в ясных терминах: Абсолютно нет!

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

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

И, конечно, есть ошибки, когда, если вы их ошибаетесь, клиент потеряет более 100 000 долларов США. И ошибки, когда клиент будет терять $ 100'000 за каждый час, ошибка не исправлена. Вам нужно посмотреть на ошибку и принять решение. Общие заявления, чтобы рассматривать все ошибки одинаково, не работают.


0

Очень хороший вопрос! Мое мнение таково: если вы не можете воспроизвести проблему, вы не можете на 100% сказать, что исправление, которое вы сделали, не будет:

а) на самом деле решить проблему. б) создать еще одну ошибку

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

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

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


Предположим, например, что кто-то получает отчет о том, что программа иногда неправильно форматирует некоторые десятичные числа при установке на французскую версию Windows; поиск кода с настройками культуры обнаруживает, что обнаруживаются методы, которые сохраняют текущую культуру потоков и устанавливают ее InvariantCultureв CompareExchangeцикле, но сбрасывают ее позже [так, что если CompareExchangeв первый раз происходит сбой, «сохраненная» переменная культуры будет перезаписана] , Воспроизвести обстоятельства сбоя будет сложно, но код явно неверен и может вызвать указанную проблему.
суперкат

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

Ну, вот и все, "это зависит" от аргумента ситуации. Если это была критическая система жизни или смерти или клиент ожидал такого рода тестирования, тогда да, приложите максимум усилий для воспроизведения проблемы и тестирования. Мне пришлось загружать код на компьютер клиента, чтобы можно было отлаживать, потому что мы не могли воспроизвести проблему на наших тестовых серверах. Это была какая-то проблема с безопасностью окон. Создано исправление, и все счастливы. Это сложно, если настроить тестовую среду сложнее, чем исправить ошибку. Тогда вы можете спросить клиента. Большую часть времени они в порядке с тестированием это сами.
Джейдел Глуки

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

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

0

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

Разумно ли настаивать на воспроизведении каждого дефекта и отладке перед диагностикой и исправлением?

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

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


0

Оба действия (проверка кода и тестирование) необходимы, но ни одного не достаточно.

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.