Причины, по которым не стоит создавать свою собственную систему отслеживания ошибок [закрыто]
https://stackoverflow.com/questions/62153
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Уже несколько раз я сталкивался с планами команды, которая хочет создать свою собственную систему отслеживания ошибок - не как продукт, а как внутренний инструмент.
Аргументы, которые я слышал в favous, обычно звучат примерно так :
- Желание "есть наш собственный собачий корм" с точки зрения какого-то внутреннего веб-фреймворка
- Нужен какой-то узкоспециализированный отчет или возможность настроить какую-то функцию каким-то якобы уникальным способом
- Полагая, что создать систему отслеживания ошибок несложно
Какие аргументы вы могли бы привести в поддержку покупки существующей системы отслеживания ошибок?В частности, какие функции кажутся простыми, но на самом деле их трудно реализовать, или они сложны и важны, но часто упускаются из виду?
Решение
Во-первых, взгляните на эти Олох показатели:
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
Что мы узнаем из этих цифр?Мы узнаем, что создание еще одного Багтрекера - отличный способ напрасно тратить ресурсы!
Итак, вот мои причины для создания вашей собственной внутренней системы отслеживания ошибок:
- Вам нужно нейтрализовать всех бозокодеров на десятилетие или два.
- Вам нужно потратить немного денег, чтобы избежать сокращения бюджета в следующем году.
В противном случае не делайте этого.
Другие советы
Я бы хотел перевернуть вопрос с другой стороны.С какой стати вам понадобилось создавать свой собственный?
Если вам нужны какие-то дополнительные поля, используйте существующий пакет, который можно изменить.
Специальный репортаж?Зайдите в базу данных и создайте ее.
Верите, что это не сложно?Тогда попробуй.Уточните это и увидите, как растет список функций и часов работы.Затем, после того как список будет завершен, попробуйте найти существующий пакет, который можно изменить, прежде чем внедрять свой собственный.
Короче говоря, не изобретайте велосипед заново, когда другой просто нуждается в некоторой доработке.
Программистам нравится создавать свою собственную систему тикетов, потому что, увидев и использовав десятки из них, они знают о ней все.Таким образом, они могут оставаться в зоне комфорта.
Это все равно что заглянуть в новый ресторан:это может быть полезно, но сопряжено с риском.Лучше заказать пиццу еще раз.
Там также скрыт важный факт принятия решений:всегда есть две причины что-то делать:хороший и правильный вариант.Мы принимаем решение ("Создаем свое собственное"), затем обосновываем его ("нам нужен полный контроль").Большинство людей даже не осознают своей истинной мотивации.
Чтобы изменить их мнение, вы должны атаковать реальный причина, а не оправдание.
Не изобретенный здесь синдром!
Создать свой собственный багтрекер?Почему бы не создать свой собственный почтовый клиент, инструмент управления проектами и т.д.
Как Омер ван Клотен говорит в другом месте заплатите сейчас или позже.
Есть и третий вариант - ни покупать, ни строить.Там есть куча хороших бесплатных игр.Например:
Создание собственного багтрекера для любых целей, кроме обучения, - не самое лучшее использование времени.
Другие ссылки:
Я бы просто сказал, что это вопрос денег - покупать готовый продукт, который, как вы знаете, полезен для вас (и иногда даже не покупать, если он бесплатный), лучше, чем идти и разрабатывать его самостоятельно.Это простая игра в заплати сейчас против. заплатишь позже.
Во-первых, против аргументов в пользу создания своего собственного:
Желание "есть наш собственный собачий корм" с точки зрения какого-то внутреннего веб-фреймворка
Это, конечно, поднимает вопрос, зачем создавать свой собственный веб-фреймворк.Точно так же, как существует множество достойных бесплатных багтрекеров, существует и множество достойных фреймворков.Интересно, правильно ли расставляют приоритеты ваши разработчики?Кто выполняет работу, которая приносит вашей компании реальные деньги?
Хорошо, если им нужно создать фреймворк, позвольте ему органично развиваться из процесса создания реального программного обеспечения, которое ваш бизнес использует для зарабатывания денег.
Нужен какой-то узкоспециализированный отчет или возможность настроить какую-то функцию каким-то якобы уникальным способом
Как уже говорили другие, возьмите один из множества прекрасных трекеров с открытым исходным кодом и настройте его.
Полагая, что создать систему отслеживания ошибок несложно
Что ж, я написал первую версию своего BugTracker.NET всего за пару недель, начав без каких-либо предварительных знаний C #.Но сейчас, спустя 6 лет и пару тысяч часов, по-прежнему остается большой список отмененных запросов функций, так что все зависит от того, что вы хотите, чтобы делала система отслеживания ошибок.Насколько важна интеграция электронной почты, интеграция с системой управления версиями, разрешения, рабочий процесс, отслеживание времени, оценка расписания и т.д.Багтрекер может быть крупным приложением.
Какие аргументы вы могли бы привести в поддержку покупки существующей системы отслеживания ошибок?
Не нужно покупать.Слишком много хороших с открытым исходным кодом: Трасса, Mantis_Bug_Tracker - отслеживатель насекомых - богомолов, мой собственный багтрекер.NET, и это лишь некоторые из них.
В частности, какие функции кажутся простыми, но на самом деле их трудно реализовать, или они сложны и важны, но часто упускаются из виду?
Если вы создаете это только для себя, тогда вы можете использовать множество коротких путей, потому что вы можете жестко настраивать вещи.Если вы создаете его для множества разных пользователей, во множестве разных сценариев, то сложность заключается в поддержке конфигурируемости.Настраиваемый рабочий процесс, пользовательские поля и разрешения.
Я думаю, что есть две особенности, которые хорошо багтрекер должен иметь, что оба Туманный жук и багтрекер.NET have, это 1) интеграция как входящей, так и исходящей электронной почты, так что весь разговор об ошибке живет вместе с ошибкой, а не в отдельной ветке электронной почты, и 2) утилита для превращения скриншота в сообщение об ошибке всего парой кликов.
Самым основным аргументом для меня была бы потеря времени.Я сомневаюсь, что это может быть завершено менее чем за месяц или два.Зачем тратить время, когда доступно ооочень много хороших систем отслеживания ошибок?Приведите мне пример функции, которую вам нужно настроить и которая недоступна.
Я думаю, что хорошая система отслеживания ошибок должна отражать ваш процесс разработки.Очень нестандартный процесс разработки по своей сути вреден для компании / команды.Большинство гибких практик благоприятствуют Схватка или что-то в этом роде, и большинство систем отслеживания ошибок соответствуют таким предложениям и методам.Не будьте слишком бюрократичны по этому поводу.
Система отслеживания ошибок может стать отличным проектом для начинающих разработчиков.Это довольно простая система, которую вы можете использовать, чтобы обучить их вашим соглашениям о кодировании и так далее.Привлечение младших разработчиков к созданию такой системы обходится относительно дешево, и они могут допустить свои ошибки в том, чего клиент не увидит.
Если это мусор, вы можете просто выбросить его, но вы можете дать им почувствовать, что их работа уже важна для компании, если ею пользуются.Вы не можете возлагать большие надежды на то, что младший разработчик сможет пройти полный жизненный цикл и все возможности для передачи знаний, которые принесет такой проект.
Мы сделали это здесь.Мы написали наш первый альбом более 10 лет назад.Затем мы обновили его для использования веб-сервисов, скорее как способ изучить технологию.Основная причина, по которой мы изначально это сделали, заключалась в том, что нам нужна была система отслеживания ошибок, которая также создавала отчеты об истории версий и несколько других функций, которые мы не смогли найти в коммерческих продуктах.
Сейчас мы снова изучаем системы отслеживания ошибок и серьезно рассматриваем возможность перехода на Mantis и использования Mantis Connect для добавления наших собственных пользовательских функций.Количество усилий, затрачиваемых на внедрение нашей собственной системы, просто слишком велико.
Я думаю, нам также следует обратить внимание на FogBugz :-)
Самое главное, куда вы будете отправлять ошибки для своего багтрекера до того, как он будет завершен?
Но серьезно.Инструменты уже существуют, нет необходимости изобретать велосипед.Изменение инструментов отслеживания для добавления определенных функций - это одно (я изменил Трасса раньше)...переписывать один из них просто глупо.
Самая важная вещь, на которую вы можете обратить внимание, - это то, что если все, что они хотят сделать, это добавить пару специализированных отчетов, для этого не требуется готового решения.И, кроме того, ПОСЛЕДНЕЕ, что имеет значение для "вашего домашнего решения", - это внутренние инструменты.Кого волнует, что вы используете внутри компании, если это позволяет выполнять работу так, как вам нужно?
Будучи программистом, работающим над уже критической (или наименее важной) задачей, не следует позволять себе отклоняться от курса, пытаясь разработать что-то, что уже доступно на рынке (с открытым исходным кодом или коммерческое).
Теперь вы попытаетесь создать систему отслеживания ошибок, чтобы отслеживать систему отслеживания ошибок, которую вы используете для отслеживания ошибок в вашей основной разработке.
Первый:1.Выберите платформу, на которой будет работать ваша баг-система (Java, PHP, Windows, Linux и т.д.). 2.Попробуйте найти инструменты с открытым исходным кодом, которые доступны (под открытым исходным кодом я подразумеваю как коммерческие, так и бесплатные инструменты) на выбранной вами платформе 3.Потратьте минимум времени на то, чтобы попытаться настроить его в соответствии с вашими потребностями.Если возможно, вообще не тратьте время на настройку
Для команды корпоративного развития мы начали использовать ДЖИРА.Нам нужны были дополнительные отчеты, вход в систему единого входа и т.д.JIRA была способна на это, и мы могли бы расширить ее, используя уже доступный плагин.Поскольку код был предоставлен в рамках платной поддержки, мы потратили минимум времени на написание пользовательского плагина для входа в систему.
Основываясь на том, что сказали другие люди, а не просто скачивая бесплатную версию с открытым исходным кодом.Как насчет того, чтобы загрузить его, а затем полностью модифицировать под свои нужды?Я знаю, что от меня требовали этого в прошлом.Я установил Bugzilla, а затем изменил ее для поддержки регрессионного тестирования и отчетов о тестировании (это было много лет назад).
Не изобретайте велосипед заново, если вы не уверены, что сможете создать колесо более круглой формы.
Я бы сказал, что одним из самых больших камней преткновения была бы агония из-за модели данных / рабочего процесса.Я предсказываю, что это займет некоторое время. длинный время и влечет за собой множество споров о том, что должно произойти с ошибкой при определенных обстоятельствах, что на самом деле представляет собой ошибку и т.д.Вместо того чтобы тратить месяцы на споры туда-сюда, если бы вы просто внедрили готовую систему, большинство людей научились бы пользоваться ею и извлекать из нее максимум пользы, независимо от того, какие решения уже приняты.Выберите что-нибудь с открытым исходным кодом, и вы всегда сможете настроить это позже, если понадобится - это будет многое быстрее, чем создавать свой собственный с нуля.
На данный момент, без масштабного нового направления в отслеживании ошибок / оформлении билетов, это было бы просто повторным изобретением колеса.Похоже, именно так, как обычно думают все остальные.
Ваши обсуждения начнутся с того, что представляет собой ошибку, перерастут в то, какой рабочий процесс применить, и закончатся массовым спором о том, как управлять проектами разработки программного обеспечения.Ты действительно этого хочешь?:-) Не-а, не думал - иди и купи один!
Большинство разработчиков думают, что они обладают какими-то уникальными способностями, которых нет ни у кого другого, и поэтому они могут создать систему, которая в некотором роде уникальна.
99% из них ошибочны.
Каковы шансы, что в вашей компании есть сотрудники, составляющие 1%?
Я был по обе стороны баррикад в этом споре, так что позвольте мне быть здесь немного двуличным.
Когда я был моложе, я настаивал на создании нашей собственной системы отслеживания ошибок.Я просто выделил все то, чего не могли сделать готовые продукты, и попросил руководство взяться за это.Кого они выбрали во главе команды?Я!Это был мой первый шанс стать руководителем команды и иметь право голоса во всем - от дизайна до инструментов и персонала.Я был в восторге.Поэтому моя рекомендация состояла бы в том, чтобы проверить мотивы людей, продвигающих этот проект.
Теперь, когда я стал старше и снова столкнулся с тем же вопросом, я просто решил использовать FogBugz.Это делает 99% того, что нам нужно, а затраты практически равны 0.Кроме того, Джоэл будет присылать вам личные электронные письма, благодаря которым вы почувствуете себя особенной.И, в конце концов, разве не в этом проблема, что ваши разработчики думают, что это сделает их особенными?
Каждый разработчик программного обеспечения хочет создать свою собственную систему отслеживания ошибок.Это потому, что мы можем очевидно улучшайте то, что уже есть, поскольку мы являемся экспертами в предметной области.
Это почти наверняка не стоит таких затрат (с точки зрения часов разработчика).Просто купи ДЖИРА.
Если вам нужны дополнительные отчеты для вашей системы отслеживания ошибок, вы можете добавить их, даже если вам придется сделать это, обратившись напрямую к базовой базе данных.
Вопрос в том, за что ваша компания вам платит?Это для того, чтобы написать программное обеспечение, которым будете пользоваться только вы?Очевидно, что нет.Таким образом, единственный способ оправдать время и затраты на создание системы отслеживания ошибок - это если она стоит меньше, чем затраты, связанные с использованием даже бесплатной системы отслеживания ошибок.
Вполне могут быть случаи, когда это имеет смысл.Вам нужно интегрироваться с существующей системой?(Отслеживание времени, оценка, требования, контроль качества, автоматизированное тестирование)?Есть ли в вашей организации какие-то уникальные требования, связанные с соблюдением требований say SOX, которые требуют определенных элементов данных, которые было бы трудно зафиксировать?
Находитесь ли вы в чрезвычайно красивой среде, которая приводит к значительным "простоям" между проектами?
Если ответ "да" на вопросы такого типа, то, безусловно, в аргументе "купить" против "построить" будет сказано "построить".
Если "вам нужен какой-то узкоспециализированный отчет или возможность настроить какую-то функцию каким-то якобы уникальным способом", лучший и дешевый способ сделать это - обратиться к разработчикам существующих систем отслеживания ошибок.Заплатите им, чтобы они внедрили эту функцию в свое приложение, сделали ее доступной для всего мира.Вместо того чтобы изобретать велосипед заново, просто заплатите производителям колес, чтобы они вставили спицы в форме пружин.
В противном случае, если вы пытаетесь продемонстрировать фреймворк, все в порядке.Просто не забудьте указать соответствующие заявления об отказе от ответственности.
Для людей, которые считают, что создать систему отслеживания ошибок несложно, строго следуйте SDLC waterfall.Заранее опишите все требования.Это, несомненно, поможет им понять всю сложность.Как правило, это те же самые люди, которые говорят, что создать поисковую систему не так уж сложно.Просто текстовое поле, кнопка "поиск" и кнопка "мне повезло", а кнопку "мне повезло" можно создать на этапе 2.
Используйте какое-нибудь программное обеспечение с открытым исходным кодом как есть.Наверняка есть ошибки, и вам понадобится то, чего еще нет или ожидает исправления.Это происходит постоянно.:)
Если вы расширяете / настраиваете версию с открытым исходным кодом, вы должны поддерживать ее.Теперь приложение, которое, как предполагается, поможет вам с тестированием приложения для зарабатывания денег станет обузой для поддержки.
Я думаю, что причиной, по которой люди пишут свои собственные системы отслеживания ошибок (по моему опыту), являются,
- Они не хотят платить за систему, которую, по их мнению, относительно легко создать.
- Эго программиста
- Общая неудовлетворенность опытом и решениями, предоставляемыми существующими системами.
- Они продают это как продукт :)
На мой взгляд, главная причина, по которой большинство багтрекеров терпели неудачу, заключалась в том, что они не обеспечивали оптимального взаимодействия с пользователем, и это может быть очень болезненно - работать с системой, которой вы часто пользуетесь, когда она не оптимизирована для удобства использования.
Я думаю, что другая причина та же, по которой почти каждый из нас (программистов) когда-нибудь создавал свою собственную CMS или фреймворк CMS (виновен по всем статьям).Просто потому, что ты можешь!
Я согласен со всеми причинами, по которым ЭТОГО НЕ следует делать.Некоторое время мы пытались использовать то, что есть, и в итоге все равно написали свое собственное.Почему?Главным образом потому, что большинство из них слишком громоздки, чтобы привлекать к ним кого-либо, кроме технических специалистов.Мы даже попробовали basecamp (который, конечно, не предназначен для этого и потерпел неудачу в этом отношении).
Мы также разработали несколько уникальных функций, которые отлично работали с нашими клиентами:кнопка "сообщить об ошибке", которую мы встроили в код с помощью одной строки javascript.Это позволяет нашим клиентам открывать небольшое окно, быстро набрасывать информацию и отправлять в базу данных.
Но, конечно, на кодирование ушло много часов;стал БОЛЬШИМ любимым проектом;уйма времени на выходные.
Если вы хотите это проверить: http://www.archerfishonline.com
Был бы рад получить обратную связь.
Мы сделали это...несколько раз.Единственная причина, по которой мы построили наш собственный, заключается в том, что это было пять лет назад и хороших альтернатив было не так уж много.но сейчас есть масса альтернатив.Главное, чему мы научились, создавая наш собственный инструмент, - это тому, что вы потратите много времени на работу с ним.И это время, за которое вы могли бы выставлять счет за свое время.Для малого бизнеса гораздо разумнее платить ежемесячную плату, которую вы можете легко окупить одним или двумя оплачиваемыми часами, чем тратить все это время на свои собственные.Конечно, вам придется пойти на некоторые уступки, но в долгосрочной перспективе вам будет намного лучше.
Что касается нас, то мы решили сделать наше приложение доступным для других разработчиков.Проверьте это по адресу http://www.myintervals.com
Потому что Трасса существует.
И потому, что вам придется обучать новых сотрудников работе с вашим программным обеспечением, разработанным на заказ, хотя у них, скорее всего, будет опыт работы с другими системами, который вы сможете использовать, а не выбрасывать.
Потому что это не оплачиваемое время и даже не очень полезно, если только вы не собираетесь его продавать.
Существуют отличные системы отслеживания ошибок, например, Туманный жук.
Я несколько лет проработал в стартапе, где мы начинали с МОШКИ, инструмент с открытым исходным кодом, и, по сути, построили поверх него нашу собственную сложную систему отслеживания ошибок.Аргумент состоял в том, что мы избежали бы траты больших денег на коммерческую систему и получили бы систему отслеживания ошибок, точно соответствующую нашим потребностям.
Конечно, это оказалось намного сложнее, чем ожидалось, и сильно отвлекло разработчиков, которым также пришлось поддерживать систему отслеживания ошибок в дополнение к нашему коду.Это стало одним из факторов, приведших к краху нашей компании.
Не пишите свое собственное программное обеспечение только для того, чтобы "есть свой собственный собачий корм".Вы просто создаете больше работы, в то время как вы, вероятно, могли бы приобрести программное обеспечение, которое делает то же самое (и лучше) за меньшие затраты времени и денег.
Скажи им, это здорово, компании не помешало бы сэкономить немного денег на некоторое время, и она будет рада предоставить инструменты для разработки, пока вы работаете в этом неоплачиваемом творческом отпуске.Любой, кто желает вместо этого взять ежегодный отпуск для работы над проектом, может это сделать свободно.
