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

Question

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

Аргументы, которые я слышал в favous, как правило, вдоль линий:

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

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

Answer 1

Во-первых, посмотрите на эти Ohloh метрики:

Trac: 44 KLoC, 10 Person Years, $577,003 
Bugzilla: 54 KLoC, 13 Person Years, $714,437 
Redmine: 171 KLoC, 44 Person Years, $2,400,723 
    Mantis: 182 KLoC, 47 Person Years, $2,562,978 

Что мы узнаем из этих чисел? Мы узнаем, что создание еще одного Bug Tracker - отличный способ расходовать ресурсы!

Так вот мои причины, чтобы построить свою собственную внутреннюю ошибку системы слежения:

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

В противном случае нет.

Answer 2

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

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

Answer 3

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

Answer 4

Я хотел бы задать вопрос. ПОЧЕМУ на земле вы хотели бы построить свой собственный?
Если вам нужны дополнительные поля, перейдите с существующим пакетом, который можно изменить.
Специальный отчет? Нажмите в базу данных и сделайте это.

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

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

Answer 5

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

Answer 6

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

Это все равно, что проверить новый ресторан: это может быть полезно, но это несет в себе риск. Лучше заказать пиццу снова.

Существует также большой факт принятия решений, погребенных там: всегда есть две причины сделать что-то: хорошее и правильное. Мы принимаем решение («Построим наши собственные»), затем оправдываем его («нам нужен полный контроль»). Большинство людей даже не знают об их истинной мотивации.

Чтобы изменить свое решение, вам необходимо нанести повод реальных причинам, а не оправдание.

Answer 7

Самое главное, где вы будете отправлять ошибки для своего трекера ошибок до его завершения?

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

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

Answer 8

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

Answer 9

Не изобретенный здесь синдром!

Создайте собственный трекер ошибок? Почему бы не создать свой собственный почтовый клиент, инструмент управления проектами и т. Д.

В качестве Omer van Kloeten says в другом месте оплатите сейчас или оплатите позже.

Answer 10

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

Answer 11

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

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

Первое: 1. Выберите платформу вашей системы ошибки будет работать на (Java, PHP, Windows, Linux и т.д.) 2. Попробуйте найти инструменты с открытым исходным кодом, которые доступны (по открытому исходному коду, я имею в виду как коммерческий, так и бесплатные инструменты) на платформе, которую вы выбрали 3. Проведите минимальное время, чтобы попытаться настроить в соответствии с вашими потребностями. Если возможно, не тратьте время на настройку вообще

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

Answer 12

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

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

Answer 13

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

Это почти наверняка не стоит затрат (с точки зрения разработчиков). Просто купите JIRA.

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

Answer 14

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

Там могут быть случаи, когда это имеет смысл. Вам нужно интегрироваться с существующей системой? (Отслеживание времени, оценка, требования, QA, автоматическое тестирование)? У вас есть какие-то уникальные требования в вашей организации, связанные с SOX Compliance, которые требуют конкретных элементов данных, которые трудно будет захватить?

Вы находитесь в чрезвычайно странной среде, которая ведет к значительному «простоям» между проектами?

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

Answer 15

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

Теперь мы снова изучаем системы отслеживания ошибок и серьезно рассматриваем возможность перехода на Mantis и использование Mantis Connect для добавления дополнительных пользовательских функций. Объем усилий в нашей собственной системе слишком велик.

Я думаю, мы не должны смотреть на FogBugz :-)

Answer 16

Существует третий вариант, ни покупать, ни строить. Там есть груды хороших свободных. Например:

• Bugzilla
• Trac

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

Другие ссылки:

• Three free bug-tracking tools
• Comparison of issue tracking systems

Answer 17

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

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

Answer 18

Потому что Trac существует.

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

Answer 19

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

Доступны отличные системы отслеживания ошибок, например, FogBugz.

Answer 20

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

Если вы делаете новую разработку, вы не должны делать это только для себя.

Answer 21

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

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

Людям, которые считают систему отслеживания ошибок, не сложно построить, строго следуйте за водопадом SDLC. Поднимите все требования вниз. Это, безусловно, поможет им понять сложность. Это, как правило, те же люди, которые говорят, что поисковая система не так сложно построить. Просто текстовое поле, кнопка «Поиск» и кнопка «Я чувствую себя счастливой», а кнопка «Я чувствую себя счастливой» можно сделать на этапе 2.

Answer 22

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

99% из них ошибаются.

Каковы шансы, что у вашей компании есть сотрудники в 1%?

Answer 23

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

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

Answer 24

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

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

Answer 25

Во-первых, против аргументов в пользу создания своей собственной:

Хотеть «съесть собственной собачьей еды» с точки зрения какой-то внутренне построен веб рамках

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

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

Нуждается узкоспециализированный доклад, или возможность изменить некоторые функции в некоторых якобы уникальным способом

Как уже говорили другие, захватить один из многих мелких открытым исходным кодом трекеров и настроить его.

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

Ну, я написал первую версию моей BugTracker.NET всего за пару недель, начиная без предварительного C# знания. Но теперь, через 6 лет и через пару тысяч часов, есть еще большой список отмененных запросов функций, поэтому все зависит от того, что вы хотите, чтобы система отслеживания ошибок выполняла. Сколько интеграция электронной почты, интеграция управления версиями, разрешения, рабочий процесс, отслеживание времени, оценка расписания и т. Д. Отслеживание ошибок может быть основным основным приложением.

Какие аргументы вы можете использовать для поддержки покупки существующей системы отслеживания ошибок?

Не нужно buy.Too много хороших с открытым исходным кодом: Trac, Mantis_Bug_Tracker, мой собственный BugTracker.NET, чтобы назвать несколько.

В частности, какие функции звучат легко, но трудно реализовать или сложны и важны, но часто упускаются из виду?

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

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

Answer 26

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

До тех пор, пока существует реальная потребность в специальной системе отслеживания ошибок, и на такие вопросы ответят, я бы не стал слишком беспокоиться.

Answer 27

Там так много отличных, зачем тратить время на повторное создание колеса?

Просто используйте FogBugz.

Answer 28

Я был по обе стороны этих дебатов, поэтому позвольте мне быть немного два здесь.

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

Теперь, когда я старше и снова столкнулся с тем же вопросом, я просто решил пойти с FogBugz. Это 99% того, что нам нужно, а затраты в основном равны 0. Кроме того, Джоэл отправит вам личные письма, которые сделают вас особенными. И в конце концов, разве не проблема, ваши разработчики думают, что это сделает их особенными?

Answer 29

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

Answer 30

Я думаю, что причина, почему люди пишут свои собственные системы слежения ошибки (по моему опыту) являются

1. Они не хотят платить за систему, они видят как относительно легко построить.
2. Программист ego
3. Общее недовольство опытом и решением, предоставляемым существующими системами.
4. Они продают его как продукт :)

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

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

Answer 31

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

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

Answer 32

Я согласен со всеми причинами НЕ. Некоторое время мы пытались использовать то, что там, и все равно начинали писать. Зачем? Главным образом потому, что большинство из них слишком громоздки, чтобы привлечь кого-то, кроме технических людей. Мы даже попробовали basecamp (который, конечно, не предназначен для этого и не прошел в этом отношении).

Мы также придумали уникальную функциональность, которая отлично поработала с нашими клиентами: кнопка «Сообщить об ошибке», которую мы ввели в код с одной строкой javascript. Это позволяет нашим клиентам открывать небольшое окно, быстро записывать информацию и отправлять в базу данных.

Но, конечно, потребовалось много часов, чтобы закодировать; стал BIG любимым проектом; много выходных.

Если вы хотите, чтобы проверить это: http://www.archerfishonline.com

Любил бы некоторую обратную связь.

Answer 33

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

Что касается нас, мы решили сделать наше приложение доступным для других разработчиков. Проверьте это на http://www.myintervals.com

Answer 34

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

Answer 35

Я создал собственные системы отслеживания ошибок. Я тоже подумал: «Как сильно это может быть, это просто система отслеживания ошибок» ERR - WRONG * - потребовалось шесть месяцев, чтобы закодировать его.

Основная причина, по которой я испекла свою, заключалась в том, чтобы понять, как я ее хотел. Другая причина была как хобби проекта.

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

Мое программное обеспечение называется Bugweb.