3.2 Выбор платформы разработки.
По результатам первичного рассмотрения в качестве основных кандидатов остались системы Express Trouble Ticketing и Roundup. В пользу первой – значительно меньший объём требуемых доработок, в пользу второй – лучшая приспособленность к доработкам, отсутствие необходимости выделять деньги и переводить их за рубеж.
Было решено выбрать между двумя системами, бросив жребий. В качестве жребия мы решили использовать 5-рублёвую монету. В случае выпадения «орла» выбирался первый вариант, в случае «решки» – второй. Для обеспечения справедливости условий монету бросало незаинтересованное лицо – симпатичная девушка-второкурсница, брюнетка по имени Алёна. Выпала «решка» и нами была взята за основу система Roundup.
Наша работа будет заключаться в модификации ядра и шаблонов Roundup вплоть до построения системы, отвечающей поставленным требованиям.
3.3 Распределение обязанностей.
По соглашению между участниками работы были следующим образом распределены роли в команде:
Алергант Дмитрий – руководитель проекта и технический писатель.
Цветков Тимофей – ведущий разработчик.
Насокин Арсений – разработчик.
Естественным образом было определено следующее разделение системы на этапы:
1) Предварительный этап.
- Разработка требований к системе, составление Проектного Задания.
- Выработка технического дизайна системы, выбор платформы для разработки.
- Разработка пользовательских интерфейсов системы.
- Выработка технологии эффективного врунтрикомандного взаимодействия.
2) Этап пилотного проекта
- Непосредственно разработка, реализация минимально необходимой функциональности системы для демонстрации общей работоспособности подхода.
3) Основной этап
- Разработка всей намеченной функциональности системы.
- Внедрение системы в эксплуатацию
4) Заключительный этап
- Поддержка внедрённой системы.
- Продуктизация системы, дополнение системы необходимой документацией, предоставление системы мировому Open-Source сообществу.
3.5 Организация командного взаимодействия.
Первое время работы над проектом постоянно изменялась и совершенствовалась организация командного взаимодействия, по мере того как старая организация показывала себя неэффективной.
В самом начале работы был создан эхо-список почтовой рассылки для эффективного обмена информацией между членами команды, однако впоследствии надежды на него не вполне оправдались.
Была установлена система контроля версий SVN. Среди множества существующих систем контроля версий она на данный момент признана оптимальной, так как:
- SVN широко распространена, и потому очень хорошо отлажена и документирована.
- SVN значительно удобнее в использовании классического CVS, и в то же время очень похожа на него используемыми командами.
- Для SVN существует масса клиентов, в том числе удобных графических, подо все платформы.
В репозитарии SVN была создана структура папок проекта, до членов команды было доведено, в содержимое каких папок следует вносить изменения, а какие трогать не следует.
До членов команды были доведены правила, согласно которым каждый commit в svn должен сопровождаться подробным комментарием об изменениях на русском языке в кодировке UTF-8.
Кроме того, в репозитарии SVN был завёдён специальный текстовый файл, куда руководитель проекта (я) записываю текущие задачи участников проекта, а сами участники дописывают туда информацию о статусе выполнения ими задач. Было решено не применять для нашего проекта специализированную Bug Tracking System, так как все участники проекта не выразили желание ей пользоваться.
В начале работы команда производила встречи с отчётом о проделанной работе раз в неделю, но подобный подход оказался малоэффективным и впоследствии мы перешли на встречи два раза в неделю.
3.6 Техническая сторона предложенного решения.
3.6.1 Постановка технической проблемы.
Была поставлена задача разработать и реализовать архитектуру факультетской системы Issue tracking на базе системы Roundup.
Было необходимо изучить архитектуру данной системы с целью сделать вывод о ее гибкости и пригодности для написания необходимой системы, соответствующей требованиям к системе (2.2) и внести в нее, если необходимо, минимальные и максимально согласующиеся с ее архитектурой изменения. Архитектура системы должна отвечать свойству гибкости, а также требовать внесения минимальных изменений в логическую часть уже имеющихся в Roundup шаблонов.
В Roundup уже реализована почти вся функциональность описывающая «жизненный цикл» заявки, сопутствующая функциональность, такая как управление пользователями, система разграничения доступа (реализовано через систему ролей), фильтрация и поиск заявок, автоматическое хранения заявок в БД и т.п. Так же с Roundup поставляется набор шаблонов написанных на языке TAL демонстрирующих заложенную функциональность. После их изучения было принято решение, что, изменив верстку можно построить необходимый для нашей системы набор шаблонов.
Согласно требованиям к системе (п2.2) одним из важных ее свойств с точки зрения ее архитектуры является поддержка заявок разного типа (под типом заявки здесь и далее будем понимать совокупность полей заявки, то есть заявки с одинаковым набором полей относятся к одному типу). Однако поставляемые с Roundup шаблоны оперируют только заявками одного типа, т.е. в Roundup все операции над заявками привязаны не к абстрактной заявке вообще, а к абстрактной заявке конкретного типа. Таким образом, невозможно просто создать новый тип заявки (объект класса IssueClass с указанным набором полей), необходимо еще и интегрировать работу с ним в имеющиеся шаблоны.
3.6.2 Обзор решений данной проблемы
Было рассмотрено несколько вариантов решения данной проблемы.
Наиболее простые в реализации из них заключаются либо написание шаблонов, в которых «зашиты» все типы заявок, либо создание мета-типа инкапсулирующего в себе все возможные типы (т.е. весь набор полей) и написания к такому типу отдельных шаблонов для каждого типа заявки отображающих конкретные поля данного типа.
Очевидным недостатком обоих решений является недостаточная гибкость системы. То есть при добавлении нового типа заявки (частая операция на первом этапе работы системы) разработчику придется каждый раз менять уже имеющиеся шаблоны или добавлять новые. При этом шаблоны для каждого типа будут отличаться друга от друга лишь спецификацией полей. Такая их общность наталкивает на идею написания универсальных шаблонов работающих с произвольным типом заявок.
В данном случае можно предложить два различных решения, агрегатор типов заявок и общий мета-тип из которого в каждый конкретный момент можно сделать конкретный тип.
Рассмотрим первое решение. Backend к базе данных в Roundup не позволяет хранить произвольные объекты языка Python, поэтому все поля приходиться перед инициализацией системы указывать в специальном конфигурационном файле schema.py, по которому далее создаются соответствующие таблицы в БД. При использовании же агрегатора (объекта, который будет хранить в себе все типы заявок) в данном файле придется указывать все необходимые типы заявок, что не позволит «на лету» без остановки системы и пересоздании всех таблиц (Roundup всегда пересоздает таблицы в БД, если они соответствуют какому-то уже имеющемуся типу) создавать новые типы из уже имеющихся в других типах полей. Так же придется адаптировать систему, ориентированную на работу с заявкой конкретного типа на работу с агрегатором заявок. По этим соображениям данное решение также было отвергнуто.
Остановимся чуть подробнее на создании мета-типа, который в каждом конкретном случае принимает вид конкретного типа. Тут также можно предложить две реализации: добавить в мета-тип специальный атрибут, в котором указаны атрибуты заявки, определяющие конкретный тип или внедрить в мета-тип интерфейс, определяющий конкретный тип.
В первом случае мы имеем хорошую, но не достаточно гибкую и динамическую систему. По сути такой мета-тип является примитивным интерфейсом, в котором слишком много приходиться «делать руками». По сему предпочтительнее реализация второго подхода с интерфейсом.
Для реализации второго подхода было рассмотрено несколько frameworks реализующих интерфейсы на языке Python: система интерфейсов использующихся в системе Zope[1], модуль интерфейсов в библиотеке Twisted[2], модуль интерфейсов в библиотеке Pli[3], а также ряд frameworks предложенных на ASPN[4].
При изучении всех из них лишь библиотека Pli предоставляла наиболее динамичные и мощные интерфейсы. Интерфейсы Zope и Twisted не являются достаточно динамичными (например, отсутствует наследование конкретного атрибута, или property конкретного атрибута). Framework предложенные на ASPN не предоставляют возможности указать строго тип атрибута, права доступа к нему (разрешение на чтение, запись), выполнение handler-ф-ии при обращении к атрибуту интерфейса. В библиотеке же Pli все это реализовано. Так же помимо самих интерфейсов есть богатая библиотека для работы с ними, предоставляющая такие возможности, как автоматическая генерация интерфейса по описывающему его dict, генерация интерфейса по объекту, добавление в динамике новых атрибутов в уже имеющийся интерфейс и т.п. Так же данный framework был хорошо знаком ведущему разработчику, так как он уже применял их на практике и более того принимал участие в их разработке.