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

Question

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

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

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

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

Есть много сообщений, которые предлагают which bugtracker is "best" ... но я полагаю, что Я больше заинтересован в:

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

Answer 1

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

Answer 2

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

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

HTH.

Answer 3

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

Answer 4

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

What's the Most Effective Workflow Between People Who Develop Algorithsm and Developers?

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

Answer 5

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

Answer 6

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

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

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

Answer 7

Использование подрывной деятельности? Вот /. сообщение, что полезно:
Best Integrated Issue-Tracker For Subversion?

Ап в общем, вот Comparison of Issue Tracking Systems.