03.07.2008 19:36:57
Вторым действительно необходимым инструментом, без которого нельзя заниматься разработкой программ, является средство отслеживания ошибок aka багтрекер.
Программисты всегда допускают ошибки. Это проистекает из самой сущности программирования. Все это давно знают, и все с этим соглашаются, включая даже самых упёртых менеджеров. Но вот удивительнейшая вещь: до сих пор огромное количество менеджеров почему-то считает, что ошибки будут совершать какие-то другие, абстрактные программисты, а не те, с которыми работают лично они.
Ещё более удивительно, что так считают и сами программисты. Впрочем, Фредерик Брукс уже больше тридцати лет назад заявил, что оптимизм - это профессиональная болезнь программистов.
Этот оптимизм, в частности, является источником следующих безапелляционных утверждений:
Что интересно, эти заявления повторяются от версии к версии. Оптимизм программистов неизлечим.
Багтрекер
Так зачем же необходим багтрекер? А необходим он для того, чтобы наше представление о состоянии программы было ближе к реальности. Я беру на себя смелость утверждать: если вы не используете багтрекер, то популяция критических багов, пожирающих изнутри вашу программу, будет непрерывно расти, пока не убьёт её окончательно.
Назначение багтрекера, в общем-то, простое. После регистрации ошибки появляется шанс, что вы о ней уже не забудете, и в этом состоит его главная функция.
Если в описании ошибки вы укажете, как её воспроизвести, то сэкономите программисту значительное время при поиске бага. Это, пожалуй, самая важная из дополнительных функций.
Но этим список возможностей багтрекера, конечно, не ограничивается. По мере его использования у вас будет появляться всё больше и больше идей о том, как извлекать пользу из накапливаемой в его базе информации.
Я перечислил только те способы, которые использую сам. У вас наверняка появится множество других идей. Главное, чтобы ваш багтрекер позволял их реализовать.
И вот здесь во весь рост встаёт вопрос: какой же багтрекер выбрать? Я не буду оригинальным и опять отвечу вам: не знаю. И тем самым соригинальничаю, потому что все остальные хором скажут: BugZilla. Хотя некоторые, возможно, порекомендуют Mantis.
Я бы, может, присоединился к большинству, если бы смог установить эту багзиллу пять лет назад, когда вопрос выбора багтрекера стоял и передо мной. Но я смог сделать это только на прошлой неделе, уже просто из принципа.
Дело в том, что багзилла требует предварительной установки некоторых других приложений, принципы работы которых описаны в замечательной книге Алана Купера "Психбольница в руках пациентов". То есть вам нужно запастись трёхкилграммовым брикетом кофе, шаманским бубном и толстым каналом в интернет, чтобы быть в состоянии шарить по десяткам форумов в поисках ответов на неизбежные вопросы, возникающие в процессе установки, в то время как Perl качает бесконечный поток компонентов, без которых багзилла отказывается работать.
Хорошо, если у вас есть свой серверный чулан, в котором живёт собственный ручной системный администратор. Тогда эту работу можно поручить ему. У меня такого чулана не было, и мне пришлось пойти по самому простому пути. А именно, написать свой собственный движок багтрекера. (Кстати, на нём работает и этот сайт.)
Движок с самого начала обеспечивал только две функции: регистрация бага и добавление комментариев к его описанию. Довольно много времени я потратил на выбор необходимых атрибутов, взяв в качестве образцов скриншоты популярных багтрекеров и силясь разобраться в различиях между всеми этими priority и severity, assigned to и belongs to и т. п. В конце концов плюнул и реализовал единственный атрибут "Статус". С двумя значениями: "Open" и "Closed". Но оставив при этом возможность добавления новых атрибутов по мере необходимости и руководствуясь принципом "прежде чем добавить информацию, подумай о том, кому и зачем она нужна".
Этот подход полностью себя оправдал. Пару лет вообще не возникало необходимости в каких-то дополнительных атрибутах. Но когда число проектов и, соответственно, багов, выросло, стал вопрос о приоритетах исправления ошибок. Тогда я добавил атрибут "Важность".
Потом мы приняли более формализованный подход к выпуску релизов, и в трекере появились поля "Принято к исправлению" и "Исправлено в версии".
Самая свежая идея, которую я уже упоминал, - это классификация причин ошибок, анализ которых поможет выявить узкие места в разработке. На сегодняшний день эта классификация выглядит так:
А вот и пример записи из нашего багтрекера.

Конечно, программисты норовят не регистрировать ошибки в багтрекере. По той же причине, по которой они не любят помещать исходники в репозиторий: это не является программированием.
Они, в общем-то, и не должны этого делать. Плохо, если они втягивают в это преступление тестировщиков или техническую поддержку, то есть тех, кто первым в команде узнаёт о баге, и для кого регистрация ошибки является прямой обязанностью. "Да чего там регистрировать, я уже всё исправил", - эта фраза звучит намного чаще, чем можно предположить. И наивные (или ленивые) суппортеры на неё часто ведутся. Вот за это нужно бить по рукам. Линейкой. Металлической. Вот такой.
Бить по рукам нужно, конечно, тестировщиков и техническую поддержку, а не программиста. Руки программиста - это его главное орудие труда. Поэтому программиста нужно бить по голове. Шютка. (Мне можно, я сам программист.)
Ваш комментарий
Добавил(а): Squisher
Григорий, зашел из дома. Прямой доступ (на работе прокся стоит), куки включены, проблем с другими сайтами относительно их нет. Хеллоу робат!
Добавил(а): Greesha
Hello robot выдаётся (по крайней мере, должно выдаваться) в том случае, если отключены cookies.
С помощью дампа базы можно снять слепок текущей модели, при этом пропадает главное преимущество движка - гибкость. В общем, я пока не готов выкладывать его в публичный доступ.
Но если интересны какие-то подробности - пишите на greesha@mail.ru.
Добавил(а): Squisher
Выдавалась ошибка при попытке подписаться на РСС рассылку, а вот какая точно ошибка выдавалась уже не помню, потому как сейчас даже ссылки не осталось (вместо нее вроде бы написано "привет робот").
>требуется масса ручной работы с базой MySQL
Не совсем понятно какого рода работы, непосредственно специфическая настройка MySQL (производительность, доп-модули) или просто работа с данными (в последнем случае дамп базы вроде должен решать все проблемы)?
Добавил(а): Greesha
Squisher, этот движок написал я сам, и он не очень удобен для сопровождения: чтобы настроить его, требуется масса ручной работы с базой MySQL. Пока он не соответствует минимальным требованиям ни OpenSource, ни тем более коммерческого продукта.
Но я над ним постоянно работаю, сейчас он разросся до системы управления проектами, и мысль "довести его до ума и выложить" меня уже, конечно, посещала.
А что не так с RSS? Я получаю извещения в ленту каждый раз, когда что-то сюда выкладываю. Только на комментарии RSS не распространяется (хотя можно прикрутить, но я не видел в этом необходимости).
Добавил(а): Squisher
Григорий, а не было у Вас в планах выложить данный багтреккер для страждущщих?
зы. подписка рсс как то не очень работает :(
Добавил(а): Илья
"То есть вам нужно запастись трёхкилграммовым брикетом кофе, шаманским бубном и толстым каналом в интернет, чтобы быть в состоянии шарить по десяткам форумов в поисках ответов на неизбежные вопросы, возникающие в процессе установки, в то время как Perl качает бесконечный поток компонентов, без которых багзилла отказывается работать."
ахаха, в точку. :) Очень знакомо. :)) Тоже из-за этого не смог поставить. :)
Добавил(а): Greesha
Спасибо за спасибо. :)
Движок, кстати, не дотестирован: не сохранял имя автора комментария. :(
Тестирую исправление этим постом.
Добавил(а):
Читаю и наслаждаюсь! ДА! Так оно и есть на самом деле! (у нас только статусов больше у багов)
Отдельное спасибо за лаконичный дизайн и юмор :-)

Greesha.ru - Все мои журналы в Сети