Золотая середина: открытые системы поддержки разработки

Подстраницы (1) →

Любая коллективная разработка программного обеспечения сталкивается с одними и теми же проблемами:

• групповая работа над кодом, документами;
• учет проблем, ошибок, требований;
• документирование, накопление и циркуляция (поиск, трансляция, агрегация) знаний компании;
• организация правильного тестирования.

Да, эффективные фреймворки сделали вебразработку достаточно легкой и быстрой, и многие увлекаются переизобретением велосипедов — реализацией собственных систем, например, учета задач и ошибок или вики-систем. Проблемы начинают проявлятся спустя время, когда обнаруживается, что приходится тратить немало времени на поддержку и развитие этих систем и обучение персонала использованию этих «самоделок», малоизвестных за пределами компании.

Поэтому дальше мы рассмотрим только разумный подход выбора, интеграции и доработки, ведь «свято поле пусто не бывает» и существуют сотни, если не тысячи, систем для решения этих проблем.

Да, полно разных классификаций функциональности, которую должны обеспечивать эти системы asset management, requirements management/tracking, bug management, issue management, customer support/help desk, knowledge base, XXX management — очень легко запутаться, лично мы придерживаемся очень простой классификации, разделяя системы в случае учета — по основному объекту учета:

Исходный код/артефакты разработки

Системы управления версиями, вебинтерфейс к репозиториями, системы полнотекстового поиска.

Проблемы/ответственность

системы трекинга проблем, системы управления задачами, системы баг-трекинга.

Знания

вики-системы, блоги-форумы, коллаборативное документирование.

Интеграция информационных потоков

RSS-агрегаторы, почта.

Но почему же «тупое» сравнение систем «по функциональности» не работает? Почему разработчики с удовольствием используют на первый взгляд не очень функциональные, бесплатные системы, а если их заставлять использовать дорогие, «солидные» системы от именитых производителей — они яростно бунтуют?

Мы считаем, что при выборе систем, важно смотреть на классификацию по следующим двум осям:

Интегрированность

Снизу этой оси системы решающие частные задачи — управление версиями, вебинтерфейс к управлению версиями, поиск, совместное редактирование текстов, учет проблем и т. п. Сверху — интегрированные «комбайны», где все связано со всем (статьи-задачи-проблемы код), и центром интеграции обычно является IDE-разработчика.

Важно понимать, что это «неоднозначная ось» — интегрированней, не всегда значит лучше! Что-то приобретается (юзабилити стандартных сценариев, например), но что-то выплескивается вместе с водой! Теряется гибкость и некоторые возможности, которые разработчики (или, что хуже, маркетологи) посчитали ненужными! А иногда падает и юзабилити, когда куча лишней функциональности занимает интерфейс, но не используется разработчиком. Интегрированность иногда означает «интегрированность в рамках Одной Операционной Системы и Технологического Стека Одной Компании». Особенно это печально, в случае закрытой, платной системы, когда нет никакой возможности, что-то исправить, изменить, срезать углы… И уповать на платную поддержку бессмысленно — обычно платная поддержка это аутсорсинговый колл-центр, и повлиять на функциональность продукта «в свою сторону» — практически невозможно.

Закрытость-Открытость

Да, имеется в виду именно закрытость или открытость исходного кода — именно этот фактор определяет, как развивается продукт, силами сообщества (в случае открытого кода), или исходя из внутренних инженерно-технологически-маркетинговых соображений. Вообще, «закрытость-открытость» очень сильно коррелирует с «платностью-бесплатностью», хотя есть и исключения (например, можно купить исходники Jira), но в любом случае, даже если исходники открыты, но продукт платный, его развитие определяется не сообществом — мало кто будет контрибъютить свои доработки, развивая чужой, платный продукт.

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

Рассмотрим существующие системы поддержки разработки под этим углом. Для иллюстрации представим картинку напоминающую «магический квадрат Gartnerа», но, предупреждаем, — она не претендует на точность и полноту, и нужна только для иллюстрации представляемых идей.

Итак, в левом нижнем квадранте отдельные, неинтегрированные системы поддержки разработки — трекеры, системы управления версиями. Их использование становится все менее и менее популярным, ибо даже несмотря на добротный функционал каждой из систем, разработчики не хотят тратить свое время на сложную интеграцию. Обычно система, интегрирующую их в единое целое представляет отдельный продукт, из левого верхнего квадранта.

В левом верхнем квадранте живут монструозные платные системы, обычно интегрирующие системы вокруг IDE (Visual Studio или Eclipse), или с вебинтерфейсом. Да, интеграция вокруг Visual Studio очень удобна для разработчика, работающего только в технологическом стеке Microsoft, и если в фирме вся разработка такая — выбор может быть вполне оправдан.

Если же часть компании работает с стеком J2EE, часть с LAMP, часть с Microsoft, часть — серверная логика на Oracle (и т. п.) — то все плюсы сразу становятся минусами.

Общая очевидная проблема — необходимость платить, причем эта проблема может стать достаточно существенной. Например, стоимость лицензий может быть больше стоимости добротного железа для разработчика. Плюс, как правило, такие систем закрыты, отсутствует возможность модификации системы и при этом, в систему жестко зашита интеграция с выбранным производителем (а не пользователем) стеком инструментов, закодированы какие-нибудь методологии и прочие «best practices», часто устаревшие на десяток лет, или слабоприменимые в ситуации пользователя, от которых никак нельзя избавиться. Несмотря на платность, в большинстве случаев нельзя повлиять на линию развития софта, уговорить производителя сделать нужные пользователю доработки, а платная «многоуровневая» поддержка, только изолирует разработчика системы от проблем пользователей, и зачастую неэффективна.

Так может рассмотреть открытые (бесплатные, и с открытым исходным кодом) интегрированные системы?

Такие есть, но их проблема — ограниченная функциональность, ибо в основном они ориентируются на удовлетворение основных потребностей небольших команд разработчиков, и как швейцарский нож — вроде бы умеет все, но слабо. То есть да, все интегрировано, но там — слабенький трекер, тут — слабая вики-система, где-то ещё — неразвитая система прав. (Например, у Pivotal Tracker ее вообще нет! Все имеют права на все!). Да, это удобно для небольших команд, где все друг-другу доверяют, но в коммерческой разработке, когда в компании больше 10 человек, это, вероятно, начнёт сильно жать.

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

То есть, тут собрались очень мощные системы — с тысячами разработчиков и десятками тысяч пользователей. Например,

Bugzilla

учет задач, ошибок, проблем, ведение журналов работ, учет оргфокуса.

Testopia

интегрированная с Bugzilla система управления тестами.

MediaWiki

документирование, постановки задач и требований, ведение базы знаний компании, и даже блогов сотрудников.

Subversion

вершина эволюции в централизованных системах контроля версий.

Также там находятся свободные системы, для которых нет свободных систем аналогов (и даже аналогов в мире платного софта):

ViewVC

веб-интерфейс к Subversion, важный «клей» между Subversion и остальными вебсистемами.

SVNSearch

полнотекстовый поиск по всей истории Subversion-репозитариев.

FeedOnFeeds

карманный «Google Reader», то есть корпоративный RSS-агрегатор с веб-интерфейсом.

Проблемы этих систем в несколько (а иногда и сильно) хаотичном развитии, а также в том, что разные системы развиваются независимо друг от друга, у них непересекающиеся команды разработчиков, и их обычно используют по отдельности. Например, та же Bugzilla изнутри выглядит довольно страшно, хотя при этом работает и широко используется по всему миру. А в MediaWiki парсер статей не использует грамматики и не реентерабелен. На первый взгляд это вообще незаметно, но может начать «жать», когда ваши технологические процессы потребуют доработок.

Ещё пример: MediaWiki — отличная, можно сказать, ведущая вики-система, но из-за основной направленности — открытые энциклопедии, в ней не развита система прав. И более того — несмотря на то, что многие пользователи запрашивают хорошую поддержку прав в MediaWiki, её архитектура была и остаётся открытой. И более того — хорошо, если так и останется. Причина в огромном числе расширений, уже написанных, и ничего не подозревающих о системе прав, и открытом доступе к БД из любого расширения. Почему же это хорошо? Хорошо это потому, что если бы этого не было, не было бы и этого огромного числа расширений («глобально-надёжные» системы вроде неторопливой «энтерпрайз-лэвел» Java — не конёк огромных открытых сообществ разработчиков), а следовательно, и система не была бы так популярна, а следовательно, и развитие её было бы тоже замедлено.

И вообще, единая система прав и авторизации, — это самое важное, когда требуется «приручать диких животных» — то есть укрощать и интегрировать дикие вебсистемы.

Итак, наиболее выгодная стратегия, чтобы получить самую мощную функциональность (включая юзабилити) и масштабируемость по разработчикам (бесплатность и отсутствие архитектурных ошибок) — это взять наиболее мощные системы с открытым кодом, интегрировать, и доработать с учетом своих процессов.

Да, объем таких доработок будет относительно ничтожным, по сравнению с общим объемом системы (например, в MediaWiki больше 2 миллионов строчек кода и доработка/расширение в 100—200 строчек, будет меньше сотой доли процента).

И о таких подходах часто рассказывают на конференциях (как докладчики, так и участники) и в интернете.

Такие рассказы весьма полезны, ведь даже подбор правильных, не конфликтующих между собой инструментов, и проверка жизнеспособности получившейся «команды» опытом собственного использования — очень ценно.

Однако утверждать, что это абсолютно «бесплатное» решение — это некоторое лукавство. На самом деле — эти «проценты» интегрирующего кода стоят весьма недешево, и поэтому мало кто готов повторить чужой опыт, несмотря на его открытость.

Поэтому («Talk is cheap, show me the code» © Линус Торвальдс) мы идем на большее, — мы публикуем в open-source полностью все используемые нами системы, с доработками и расширениями. Кстати, еще одна проблема использования open-source — пользоваться им любят многие, но при этом не любят делиться своими доработками.

В наших доработках мы «объездили» эти дикие системы, сделав из разрозненного набора сплоченную команду, удобную для разработки в различных технологических стеках, для компании размером в несколько сотен человек. Решена проблема с единой авторизацией и системой прав, сделано множество расширений для удобства разработчиков, аналитиков и тестировщиков, и все это проверено многолетним опытом использования.

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

---

---

Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.