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

<p>несколько раз я сталкивался с планами команды, которая хочет создать собственную систему отслеживания ошибок - не как продукт, а как внутренний инструмент.</p><p>аргументы, которые я услышал в пользу, обычно звучат так:</p><ul> <li>желая "съесть собственную собачью еду" с точки зрения какой-то внутренней веб-инфраструктуры</li> <li>требуется какой-то узкоспециализированный отчет или возможность настраивать некоторые функции каким-то якобы уникальным способом</li> <li>полагая, что не сложно построить систему отслеживания ошибок</li> </ul><p>какие аргументы вы могли бы использовать для поддержки покупки существующей системы отслеживания ошибок? в частности, какие функции кажутся простыми, но трудно реализуемыми или сложными и важными, но часто упускаются из виду?</p>

<p>сначала посмотрите на эти <a href="http://ohloh.net">ohloh</a> показатели:</p><pre><code> 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 </code></pre><p>что мы узнаем из этих чисел? мы узнаем, что создание еще одного отслеживателя ошибок - отличный способ тратить ресурсы!</p><p>вот мои причины для создания собственной внутренней системы отслеживания ошибок:</p><ol> <li>вы должны нейтрализовать все бозокодеры в течение десяти или двух лет.</li> <li>чтобы избежать сокращения бюджета в следующем году, вам необходимо собрать немного денег.</li> </ol><p>в противном случае нет.</p>

<p>я хотел бы перевернуть вопрос. почему на земле вы хотите построить свой собственный?<br> если вам нужны дополнительные поля, используйте существующий пакет, который можно изменить.<br> специальный репортаж? нажмите на базу данных и сделайте это.</p><p>полагая, что это не сложно? попробуй тогда. уточните это, и вы увидите список возможностей и часов. затем, после того как список заполнен, попробуйте найти существующий пакет, который можно изменить, прежде чем реализовывать свой собственный.</p><p>короче говоря, не изобретайте велосипед, когда другому просто нужно немного подстроиться.</p>

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

<h1>не придуманный здесь синдром!</h1><p>создать свой собственный баг-трекер? почему бы не создать свой собственный почтовый клиент, инструмент управления проектами и т.д.</p><p>как <a href="https://stackoverflow.com/questions/62153/reasons-not-to-build-your-own-bug-tracking-system/62163#62163">омер ван клоэтен говорит</a> в другом месте, заплати сейчас или заплати позже.</p>

<p>есть третий вариант, ни купить, ни построить. там куча хороших бесплатных. например:</p><ul> <li> <a href="http://en.wikipedia.org/wiki/bugzilla">bugzilla</a> </li> <li> <a href="http://en.wikipedia.org/wiki/trac">trac</a> </li> </ul><p>использование собственного трекера ошибок для любого использования, кроме обучения, не является хорошим расходом времени.</p><p>другие ссылки:</p><ul> <li><em> <a href="https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878\_11-1049951.html">три бесплатных инструмента отслеживания ошибок</a> </em></li> <li><em> <a href="http://en.wikipedia.org/wiki/comparison\_of\_issue\_tracking\_systems">сравнение систем отслеживания проблем</a> </em></li> </ul>

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

<p>во-первых, против аргументов в пользу построения собственного:</p><blockquote> <p>желая "съесть собственную собачью еду" с точки зрения какой-то внутренней веб-инфраструктуры</p> </blockquote><p>это, конечно, поднимает вопрос, зачем создавать свой собственный веб-фреймворк. так же, как есть много достойных бесплатных баг-трекеров, есть также много достойных фреймворков. интересно, у ваших разработчиков четкие приоритеты? кто выполняет работу, которая приносит вашей компании реальные деньги?</p><p>хорошо, если они должны построить структуру, пусть она будет органично развиваться из процесса создания фактического программного обеспечения, которое ваш бизнес использует, чтобы зарабатывать деньги.</p><blockquote> <p>требуется какой-то узкоспециализированный отчет или возможность настраивать некоторые функции каким-то якобы уникальным способом</p> </blockquote><p>как уже говорили другие, возьмите один из множества прекрасных трекеров с открытым исходным кодом и настройте его.</p><blockquote> <p>полагая, что не сложно построить систему отслеживания ошибок</p> </blockquote><p>итак, я написал первую версию своего <a href="http://ifdefined.com/bugtrackernet.html">bugtracker.net</a> всего за пару недель, не имея предварительных знаний c #. но сейчас, спустя 6 лет и пару тысяч часов, все еще есть большой список отмененных запросов на функции, поэтому все зависит от того, что вы хотите, чтобы система отслеживания ошибок делала. сколько стоит интеграция с электронной почтой, контроль исходного кода, разрешения, рабочий процесс, отслеживание времени, оценка расписания и т.д. отслеживание ошибок может быть основным, основным приложением.</p><blockquote> <p>какие аргументы вы могли бы использовать для поддержки покупки существующей системы отслеживания ошибок?</p> </blockquote><p>не нужно покупать. слишком много хороших программ с открытым исходным кодом: <a href="http://en.wikipedia.org/wiki/trac">trac</a> , <a href="http://en.wikipedia.org/wiki/mantis\_bug\_tracker">mantis\_bug\_tracker</a> , мой собственный bugtracker.net, чтобы назвать несколько.</p><blockquote> <p>в частности, какие функции кажутся простыми, но трудно реализуемыми или сложными и важными, но часто упускаются из виду?</p> </blockquote><p>если вы создаете это только для себя, то вы можете использовать множество ярлыков, потому что вы можете делать жесткие выводы. если вы создаете его для большого количества разных пользователей, в разных сценариях, то поддержка конфигурации очень сложна. настраиваемый рабочий процесс, настраиваемые поля и разрешения.</p><p>я думаю, что две функции, которые должен иметь <em> хороший </em> баг-трекер, и обе ( <a href="http://en.wikipedia.org/wiki/fogbugz">fogbugz</a> и bugtracker.net имеют) 1) интеграция как входящей, так и исходящей электронной почты, так что весь разговор об ошибке связан с ошибкой, а не с отдельной веткой электронной почты, и 2) утилита для превращения скриншота в сообщение об ошибке всего за пару кликов.</p>

<p>самым основным аргументом для меня будет потеря времени. я сомневаюсь, что это может быть завершено менее чем через месяц или два. зачем тратить время, когда есть так много хороших систем отслеживания ошибок? дайте мне пример функции, которую вы должны настроить, и которая недоступна.</p><p>я думаю, что хорошая система отслеживания ошибок должна отражать ваш процесс разработки. весьма нестандартный процесс разработки по своей сути вреден для компании/команды. большинство гибких практик предпочитают <a href="http://en.wikipedia.org/wiki/scrum\_%28development%29">scrum</a> или подобные вещи, и большинство систем отслеживания ошибок соответствуют таким предложениям и методам. не слишком бюрократизируйся по этому поводу.</p>

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

<p>мы сделали это здесь. мы написали наш первый более 10 лет назад. затем мы модернизировали его, чтобы использовать веб-сервисы, скорее как способ изучения технологии. первоначально основной причиной, по которой мы сделали это, было то, что нам нужна система отслеживания ошибок, которая также создавала отчеты об истории версий и некоторые другие функции, которые мы не могли найти в коммерческих продуктах.</p><p>сейчас мы снова рассматриваем системы отслеживания ошибок и серьезно подумываем о переходе на mantis и использовании mantis connect для добавления собственных собственных дополнительных функций. количество усилий при развертывании нашей собственной системы слишком велико.</p><p>я думаю, что мы также должны смотреть на fogbugz :-)</p>

<p>самое главное, где вы будете отправлять сообщения об ошибках для вашего баг-трекера до его завершения?</p><p>но серьезно. инструменты уже существуют, нет необходимости изобретать велосипед. модификация инструментов отслеживания для добавления определенных специфических функций - это одно (я уже модифицировал <a href="http://en.wikipedia.org/wiki/trac">trac</a> ) ... переписывать один просто глупо.</p><p>самая важная вещь, на которую вы можете обратить внимание, это то, что если все, что они хотят сделать, это добавить пару специализированных отчетов, то для этого не требуется базового решения. и, кроме того, последнее место, в котором "ваше домашнее решение" имеет значение, предназначено для внутренних инструментов. кого волнует, что вы используете внутри, если оно выполняет работу так, как вам нужно?</p>

<p>будучи программистом, работающим над и без того критической (или, по меньшей мере, важной) задачей, не следует позволять себе отклоняться, пытаясь разработать что-то, что уже доступно на рынке (открытый или коммерческий).</p><p>теперь вы попытаетесь создать систему отслеживания ошибок, чтобы отслеживать систему отслеживания ошибок, которую вы используете для отслеживания ошибок в разработке ядра.</p><p>сначала: 1. выберите платформу, на которой будет работать ваша система ошибок (java, php, windows, linux и т.д.) 2. попробуйте найти инструменты с открытым исходным кодом, которые доступны (под открытым исходным кодом, я имею в виду как коммерческие, так и бесплатные инструменты) на платформе вы выбрали 3. потратьте минимальное время, чтобы попытаться настроить в соответствии с вашими потребностями. если возможно, не тратьте время на настройку</p><p>для команды разработчиков предприятия мы начали использовать <a href="http://en.wikipedia.org/wiki/jira">jira</a> . нам нужны были дополнительные отчеты, вход в систему единого входа и т.д. jira была способна на это, и мы могли расширить его, используя уже доступный плагин. поскольку код был частью платной поддержки, мы потратили минимальное время на написание пользовательского плагина для входа в систему.</p>

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

<p>я был на обеих сторонах этой дискуссии, поэтому позвольте мне быть немного двое здесь.</p><p>когда я был моложе, я начал создавать собственную систему отслеживания ошибок. я просто выдвинул на первый план все вещи, которые не могли сделать готовые вещи, и у меня было руководство, чтобы пойти на это. кого они выбрали, чтобы возглавить команду? мне! это был мой первый шанс стать руководителем команды и иметь право голоса во всем, от дизайна до инструментов и персонала. я был в восторге. поэтому я рекомендую проверить мотивацию людей, продвигающих этот проект.</p><p>теперь, когда я стал старше и снова столкнулся с тем же вопросом, я просто решил пойти с fogbugz. это делает 99% от того, что нам нужно, и затраты в основном равны 0. кроме того, джоэл отправит вам личные письма, чтобы вы чувствовали себя особенным. и в конце концов, разве не проблема, ваши разработчики думают, что это сделает их особенными?</p>

<p>большинство разработчиков считают, что у них есть уникальные возможности, которых нет ни у кого, и поэтому они могут создать систему, которая в некотором роде уникальна.</p><p>99% из них не правы.</p><p>каковы шансы, что в вашей компании есть сотрудники в 1%?</p>

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

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

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

<p>если "требуется какой-то узкоспециализированный отчет или возможность настраивать некоторые функции каким-то якобы уникальным способом", лучший и самый дешевый способ сделать это - поговорить с разработчиками существующих систем отслеживания ошибок. платите им, чтобы они добавили эту функцию в свое приложение и сделали его доступным для всего мира. вместо того, чтобы изобретать велосипед, просто платите производителям колес за то, чтобы они вставляли спицы в форме пружин.</p><p>в противном случае, если вы пытаетесь продемонстрировать рамки, все хорошо. просто убедитесь, что вставили соответствующие оговорки.</p><p>людям, которые считают, что систему отслеживания ошибок несложно построить, строго соблюдайте sdlc. получить все требования заранее. это, безусловно, поможет им понять сложность. как правило, это те же люди, которые говорят, что поисковую систему не так сложно построить. просто текстовое поле, кнопка "поиск" и кнопка "мне повезет", а кнопка "мне повезет" можно выполнить на втором этапе.</p>

<p>каждый разработчик программного обеспечения хочет создать свою собственную систему отслеживания ошибок. это потому, что мы можем <em> очевидно </em> улучшить то, что уже есть, поскольку мы являемся экспертами в области.</p><p>это почти наверняка не стоит затрат (с точки зрения времени разработчика). просто купите <a href="http://www.atlassian.com/software/jira/">jira</a> .</p><p>если вам нужны дополнительные отчеты для вашей системы отслеживания ошибок, вы можете добавить их, даже если вам придется делать это, напрямую обращаясь к основной базе данных.</p>

<p>вопрос в том, что ваша компания платит вам? это писать программы, которые будут использовать только вы? очевидно нет. таким образом, единственный способ оправдать затраты времени и средств на создание системы отслеживания ошибок, если она стоит меньше затрат, связанных с использованием даже бесплатной системы отслеживания ошибок.</p><p>там вполне могут быть случаи, когда это имеет смысл. вам нужно интегрироваться с существующей системой? (отслеживание времени, оценка, требования, qa, автоматизированное тестирование)? у вас есть какие-то уникальные требования в вашей организации, связанные с соответствием sox, которые требуют определенных элементов данных, которые было бы трудно собрать?</p><p>вы находитесь в крайне мрачной обстановке, которая приводит к значительному простою между проектами?</p><p>если ответ на эти типы вопросов положительный, то во всех отношениях аргумент "купить" против построения скажет "построить".</p>

<p>потому что <a href="http://en.wikipedia.org/wiki/trac">trac</a> существует.</p><p>и потому, что вам придется обучать новых сотрудников на вашем заказном программном обеспечении, когда они, скорее всего, будут иметь опыт работы с другими системами, которые вы можете построить, а не выбрасывать.</p>

<p>потому что это не оплачиваемое время или даже очень полезное, если вы не собираетесь его продавать.</p><p>есть совершенно хорошие системы отслеживания ошибок, например, <a href="http://en.wikipedia.org/wiki/fogbugz">fogbugz</a> .</p>

<p>я работал в стартапе в течение нескольких лет, когда мы начали с <a href="http://en.wikipedia.org/wiki/gnats">gnats</a> , инструмента с открытым исходным кодом, и по сути построили нашу собственную сложную систему отслеживания ошибок. аргумент состоял в том, что мы избежим тратить много денег на коммерческую систему, и мы получим систему отслеживания ошибок, точно соответствующую нашим потребностям.</p><p>конечно, это оказалось намного сложнее, чем ожидалось, и это сильно отвлекало разработчиков - им также пришлось поддерживать систему отслеживания ошибок в дополнение к нашему коду. это было одним из факторов, способствующих гибели нашей компании.</p>

<p><strong>используйте программное обеспечение с открытым исходным кодом как есть</strong>. наверняка есть ошибки, и вам понадобится то, чего еще нет или ожидается исправление ошибки. это происходит все время. :)</p><p>если вы расширяете/настраиваете версию с открытым исходным кодом, вы должны поддерживать ее. теперь приложение, которое должно помочь вам в тестировании <strong>приложения для зарабатывания денег</strong>, станет бременем для поддержки.</p>

<p>мы сделали это ... несколько раз. единственная причина, по которой мы построили нашу собственную, состоит в том, что это было пять лет назад, и не было очень много хороших альтернатив. но сейчас есть множество альтернатив. главное, что мы узнали при создании нашего собственного инструмента, это то, что вы потратите много времени на его работу. и это время, которое вы могли бы выставлять счета за свое время. как малый бизнес, гораздо разумнее платить ежемесячную плату, которую вы можете легко окупить за один или два оплачиваемых часа, чем тратить все это время на свои собственные. конечно, вам придется пойти на некоторые уступки, но в конечном итоге вам будет намного лучше.</p><p>что касается нас, мы решили сделать наше приложение доступным для других разработчиков. проверьте это на <a href="http://www.myintervals.com">http://www.myintervals.com</a> </p>

<p>я думаю, что причина, по которой люди пишут свои собственные системы отслеживания ошибок (по моему опыту):</p><ol> <li>они не хотят платить за систему, которую, по их мнению, относительно легко построить.</li> <li>программист эго</li> <li>общее недовольство опытом и решениями существующих систем.</li> <li>они продают это как продукт :)</li> </ol><p>на мой взгляд, главная причина, по которой большинство систем отслеживания ошибок не работали, заключалась в том, что они не обеспечивали оптимального взаимодействия с пользователем, и работа с системой, в которой вы используете lot, может быть очень болезненной, если она не оптимизирована для удобства использования.</p><p>я думаю, что другая причина такая же, как и то, почему почти каждый из нас (программистов) когда-то создавал свои собственные cms или cms-фреймворки (виновные по обвинению). просто потому что ты можешь!</p>

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

<p>не пишите свое собственное программное обеспечение только для того, чтобы вы могли "есть свой собственный корм для собак" вы просто создаете больше работы, когда вы, вероятно, можете купить программное обеспечение, которое делает то же самое (и лучше) за меньшее время и потраченные деньги.</p>

<p>я построил свои собственные системы отслеживания ошибок. я тоже подумал: "как это может быть сложно, это просто система отслеживания ошибок" <strong> err - неправильно * </strong> - потребовалось шесть месяцев, чтобы ее кодировать.</p><p>основная причина, по которой я испекла свою собственную, состояла в том, чтобы получить именно то, что я хотел. другая причина была в хобби-проекте.</p><p>я бы сказал, что это единственный раз, когда оправданно создавать свой собственный, если это хобби-проект. ни одна компания не должна тратить свое время на это.</p><p>мое программное обеспечение называется <a href="http://www.bugweb.com.au">bugweb</a> кстати.</p>

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

<p>там уже так много великих, зачем тратить время на то, чтобы заново изобрести колесо?</p><p>просто используйте <a href="http://en.wikipedia.org/wiki/fogbugz">fogbugz</a> .</p>

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

<p>скажите им, <em>это здорово, компания могла бы сэкономить немного времени и будет рада предоставить инструменты разработки, пока вы работаете в этом неоплачиваемом творческом отпуске. любой, кто хочет взять свой ежегодный отпуск вместо того, чтобы работать над проект свободен в этом.</em></p>