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

99% из них неправы.

, Каковы возможности, что Ваша компания имеет сотрудников в 1%?

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

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

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

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

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

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

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

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

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

Как , Omer van Kloeten говорит в другом месте, плата теперь, или заплатите позже.

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

• Bugzilla
• Trac

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

я предполагаю, что мы должны также смотреть на FogBugz:-)

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

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

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

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

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

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

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

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

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

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

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

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

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

Иначе, при попытке продемонстрировать платформу, ее всю пользу. Просто удостоверьтесь, что вставили соответствующие правовые оговорки.

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

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

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

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

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

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

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

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

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

, Но, конечно, потребовалось много часов для кодирования; стал БОЛЬШИМ любимым проектом; много времени выходных дней.

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

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

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

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

Поскольку Trac существует.

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

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

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

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

, Если бы ответ - да к этим типам вопросов - тогда любой ценой, "покупка" по сравнению со сборкой arguement сказала бы сборку.

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

существуют совершенно хорошие доступные системы отслеживания ошибок, например, FogBugz.

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

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

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

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

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

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

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

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