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

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

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

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

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

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

Или же:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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