Большую часть своей профессиональной карьеры программиста я работал с системами отслеживания ошибок (bugtracking, SCM, ALM и т. д.).
На каждой своей работе я внедрял VCS и багтрекинг или работал с уже имеющимся.
Я видел почти все достойные, три из них разобрал: Trac, Scarab, JIRA. Единственное, чего мне не хватало в этой жизни, так это так называемых SaS-систем, но это не имеет большого значения.
Это очень специфичные и нишевые продукты.
А сегодня утром, когда я не мог уснуть, мне в голову пришла идея, как реализовать ядро баг-трекера.
На меня произвело самое большое впечатление Скарабей ваша модель данных.
Это почти близко к тому, что я считаю идеальным для единой системы отслеживания проблем.
А вот от Скарабея разработчики отказались (я об этом говорил не раз) написал ).
Я тоже (так!).
И теперь, несмотря на всю свою идеологическую корректность, он прозябает в безвестности.
Но что же в этом такого уникального, спросите вы? В Scarab можно было определить тип Issue на корневом уровне, а при настройке проекта его можно было настроить (значения полей, обязательные поля, рабочий процесс).
Плюс на уровне проекта появилась возможность определять шаблоны задач, то есть предварительно заполнять поля.
Те, кто администрировал JIRA для более или менее большого объема данных (например, > 100 проектов, > 1000 пользователей, > 700 групп, > 300 настраиваемых полей и т. д.), знают, насколько это сложно.
Например, в Polycom администрированием JIRA занимаются 12 (!!!) человек.
В чем проблема? Дело в том, что разные сущности, на которых выполняются административные задачи, не связаны друг с другом самым логичным образом.
Некоторые из них привязаны к проекту, некоторые к проблеме, а некоторые и к тому, и к другому (на самом деле связей гораздо больше).
Как должно быть? Мне кажется, что ключевой элемент все-таки выдающийся и все параметры должны быть привязаны к нему.
Собственно идея.
Существует концепция прототипирования объекта , что отражено в ряде языков программирования (JavaScript, Self, Io, Lua и т.д.) и в нескольких фреймворках (на ум приходит только Squeak Morphic).
Суть в том, что для создания нового объекта вы клонируете существующий и модифицируете его, а затем на основе результата можете клонировать новые.
Каждый объект знает свой прототип, и изменение поведения прототипа меняет поведение клонов, если только они сами не переопределяют этот аспект. Вот пример того, как это может выглядеть:
Issue-------------------|
| |
Bug---------| Fetaure
| |
Bug in Bug in---------|
desktop web-app |
app | |
| | |
Template Template Template
for app1 for for
webapp1 webapp2
На самом деле, можно представить любую иерархию.
Самое главное, что с помощью этой схемы становится возможным индивидуально модифицировать отдельные Issues (например, добавить поле или изменить рабочий процесс) и очень гибко влиять на поведение объекта.
При этом сохраняется возможность управлять всей иерархией и заменять прототипы для выбранных задач.
Конечно, есть побочные эффекты: со временем иерархия разрастается и управлять становится практически невозможно, но это можно решить с помощью удобного и интуитивно понятного интерфейса.
УПД: небольшое объяснение.
Я не имел в виду, что архитектуру нужно реализовать на языке, основанном на прототипах, а то, что объекты, с которыми работают пользователь и администратор (задачи, типы задач, схемы), можно разложить в иерархию прототипов.
Теги: #BugTracker #трекер ошибок #идея #на основе прототипа #Чулан
-
Reactos 0.4.11 — Еще Сотня Приложений
19 Oct, 24
