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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

НТН.

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

Это похожий вопрос.

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

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