Отслеживание ошибок в устаревших физических моделях

Question

Я единственный инженер-программист в команде, которая разрабатывает физические модели (около 30 000 строк кода).Остальная часть команды состоит из ученых, которые разрабатывают свои кодовые базы около 20 лет.Мой рабочий процесс выглядит примерно так:

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

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

• Невероятно прост в использовании
• Интеграция с программным обеспечением контроля версий (мы используем Subversion)

Есть много сообщений, которые предлагают какой багтрекер «лучший»...но я полагаю, что меня больше интересует:

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

Answer 1

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

Answer 2

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

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

ХТХ.

Answer 3

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

При этом, даже если я единственный пользователь (что часто случается), я все равно устанавливаю трекер ошибок (обычно trac).Если вы используете его неукоснительно (указываете все, что приходит разными способами, как ошибку и ВСЕГДА ссылаетесь на номер ошибки в своих ответах), команда, как правило, со временем обнаруживает ее.

Введите вехи (или как их называет ваш трекер) и свяжите с ними ошибки.Всякий раз, когда кто-то спрашивает, как продвигается какое-либо дело, вызовите отчет о промежуточных этапах или его эквивалент и ПОКАЖИТЕ ИМ.Это помогает людям перестать воспринимать систему отслеживания ошибок как помеху и осознать, что она может быть источником бесценной информации.

Answer 4

Даже если вы единственный пользователь (со мной это однажды случилось), оно того стоит.Вы можете начать говорить что-то вроде: «Ошибка 1002 блокирует.Кто может мне в этом помочь, чтобы мы могли перейти к той или иной функции».

Answer 5

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

Answer 6

Это аналогичный вопрос.

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

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

Answer 7

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

В общем, вот Сравнение систем отслеживания проблем.