Ответ 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

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

Итак, вот мои причины для создания собственной системы отслеживания ошибок:

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

• Bugzilla
• Trac

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

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

• Три бесплатных инструмента отслеживания ошибок
• Сравнение систем отслеживания проблем

Ответ 6

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

Ответ 7

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

Желание "съесть нашу собственную собачью пищу" с точки зрения некоторых встроенных веб-фреймворков

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

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

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

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

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

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

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

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

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

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

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

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

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

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

Ответ 11

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

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

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

Ответ 12

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

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

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

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

Ответ 13

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

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

Ответ 14

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

Ответ 15

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

Ответ 16

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

Ответ 17

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

99% из них ошибочны.

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

Ответ 18

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

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

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

Ответ 19

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

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

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

Ответ 20

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

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

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

Если ответ "да" на эти типы вопросов - тогда, во всяком случае, "buy" vs build arguement будет сказать "build".

Ответ 21

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

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

Ответ 22

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

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

Ответ 23

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

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

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

Ответ 24

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

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

Ответ 25

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

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

Ответ 26

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

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

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

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

Ответ 27

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

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

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

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

Понравилась бы какая-то обратная связь.

Ответ 28

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

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

Ответ 29

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

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

Ответ 30

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

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