Большую часть своей профессиональной карьеры программиста я занимаюсь багтракерами (bugtracking, SCM, ALM, etc). На каждой своей работе я внедрял VCS и bugtracking или работал с имеющимся. Видел практически все из достойных, три из них разбирал по винтику: Trac, Scarab, JIRA. Есдинственное, что упустил в этой жизни, так это так называемые SaS системы, но не велика беда. Это весьма специфичные и нишевые продукты.
А сегодня под утро, когда не мог заснуть, мне в голову пришла идея того, как можно реализовать ядро багтракера.
Наибольшее впечатление на меня произвел Scarab своей моделью данных. Она почти близка к тому, что я считаю идеалом для унифицированной системы issue tracking. Но Scarab брослили разработчики (я об этом неоднократно писал). И я тоже (sic!). И теперь не смотря на всю его идиологическую правильность, он прозябает в безвестности.
Но, что же в нем было такого уникального, спросите вы? В Scarab можно было определить тип Issue на корневом уровне, а при конфигурации проекта, его можно было подтюнить (значения полей, обязательность полей, workflow). Плюс к этому на уровне проекта можно было определять шаблоны issue, то есть предварительно заполнять поля.
Те кто администрировал JIRA на более менее большем объеме данных (например >100 проектов, >1000 пользователей, >700 групп, >300 кастомных полей, etc) знает, насколько это тяжело. Например в компании Polycom администрированием JIRA занимается 12(!!!) человек.
А в чем проьблема? В том, что разные сущности, над которомы выполняются административные задачи, связаны между собой не самым логичным образом. Часть из них привязана к проекту, часть к issue, а часть и к тому и другому (на самом деле связей гораздо больше). А как должно быть? Мне кажется, что ключевой элемент всетаки issue и все параметры должны привязываться к нему.
Собственно идея. Существует концепция прототипирования объектов, которая нашла отражение в ряде языков программирования (JavaScript, Self, Io, Lua, etc) и в нескольких фреймворках (на ум приходит только Squeak Morphic). Суть в том, что для создания нового объекта, вы клонируете уже существующий и видо изменяете его, а затем на основе получившегося можете клонировать новые. Каждый объект знает свой прототип, и изменение поведения прототипа изменяет поведение клонов, если они не переопределяли сами данный аспект.
Приведу пример того, как это может выглядеть:
Собственно можно нафантазировать любую иерархию. Самое главное, что при такой схеме появляется возможность индивидуально модифицировать отдельные Issue (например добавить поле, или поменять workflow) и очень гибко влиять на поведение объекта. В тоже время остается возможность управлять всей иерархией и осуществлять замену прототипов для выбранных issues.
Конечно тут есть побочные действия: со временем иерархия разрастается и ей становится практически невозможно управлять, но это может быть решено при помощи удобного и интуитивного интерфейса.
UPD: маленькое пояснение. Я имел ввиду не то, что надо реализовывыть архитектуру на Prototype-based языке, а то, что объекты, с которыми работает пользователь и администратор (issues, issue types, schemes), можно декомпозировать в иерархию прототипов.
А сегодня под утро, когда не мог заснуть, мне в голову пришла идея того, как можно реализовать ядро багтракера.
Наибольшее впечатление на меня произвел Scarab своей моделью данных. Она почти близка к тому, что я считаю идеалом для унифицированной системы issue tracking. Но Scarab брослили разработчики (я об этом неоднократно писал). И я тоже (sic!). И теперь не смотря на всю его идиологическую правильность, он прозябает в безвестности.
Но, что же в нем было такого уникального, спросите вы? В Scarab можно было определить тип Issue на корневом уровне, а при конфигурации проекта, его можно было подтюнить (значения полей, обязательность полей, workflow). Плюс к этому на уровне проекта можно было определять шаблоны issue, то есть предварительно заполнять поля.
Те кто администрировал JIRA на более менее большем объеме данных (например >100 проектов, >1000 пользователей, >700 групп, >300 кастомных полей, etc) знает, насколько это тяжело. Например в компании Polycom администрированием JIRA занимается 12(!!!) человек.
А в чем проьблема? В том, что разные сущности, над которомы выполняются административные задачи, связаны между собой не самым логичным образом. Часть из них привязана к проекту, часть к issue, а часть и к тому и другому (на самом деле связей гораздо больше). А как должно быть? Мне кажется, что ключевой элемент всетаки issue и все параметры должны привязываться к нему.
Собственно идея. Существует концепция прототипирования объектов, которая нашла отражение в ряде языков программирования (JavaScript, Self, Io, Lua, etc) и в нескольких фреймворках (на ум приходит только Squeak Morphic). Суть в том, что для создания нового объекта, вы клонируете уже существующий и видо изменяете его, а затем на основе получившегося можете клонировать новые. Каждый объект знает свой прототип, и изменение поведения прототипа изменяет поведение клонов, если они не переопределяли сами данный аспект.
Приведу пример того, как это может выглядеть:
Issue-------------------|
| |
Bug---------| Fetaure
| |
Bug in Bug in---------|
desktop web-app |
app | |
| | |
Template Template Template
for app1 for for
webapp1 webapp2
Собственно можно нафантазировать любую иерархию. Самое главное, что при такой схеме появляется возможность индивидуально модифицировать отдельные Issue (например добавить поле, или поменять workflow) и очень гибко влиять на поведение объекта. В тоже время остается возможность управлять всей иерархией и осуществлять замену прототипов для выбранных issues.
Конечно тут есть побочные действия: со временем иерархия разрастается и ей становится практически невозможно управлять, но это может быть решено при помощи удобного и интуитивного интерфейса.
UPD: маленькое пояснение. Я имел ввиду не то, что надо реализовывыть архитектуру на Prototype-based языке, а то, что объекты, с которыми работает пользователь и администратор (issues, issue types, schemes), можно декомпозировать в иерархию прототипов.
