|
 |
Персональные инструменты
Просмотры |
|
Персональные инструменты |
|
||
|
|
Золотая середина: открытые системы поддержки разработкиМатериал из CustisWikiЭто снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений. Любая коллективная разработка программного обеспечения сталкивается с одними и теми же проблемами:
Да, эффективные фреймворки сделали вебразработку достаточно легкой и быстрой, и многие увлекаются переизобретением велосипедов — реализацией собственных систем, например, учета задач и ошибок или вики-систем. Проблемы начинают проявлятся спустя время, когда обнаруживается, что приходится тратить немало времени на поддержку и развитие этих систем и обучение персонала использованию этих «самоделок», малоизвестных за пределами компании. Поэтому дальше мы рассмотрим только разумный подход выбора, интеграции и доработки, ведь «свято поле пусто не бывает» и существуют сотни, если не тысячи, систем для решения этих проблем. Да, полно разных классификаций функциональности, которую должны обеспечивать эти системы asset management, requirements management/tracking, bug management, issue management, customer support/help desk, knowledge base, XXX management — очень легко запутаться, лично мы придерживаемся очень простой классификации, разделяя системы в случае учета — по основному объекту учета:
Но почему же «тупое» сравнение систем «по функциональности» не работает? Почему разработчики с удовольствием используют на первый взгляд не очень функциональные, бесплатные системы, а если их заставлять использовать дорогие, «солидные» системы от именитых производителей — они яростно бунтуют? Мы считаем, что при выборе систем, важно смотреть на классификацию по следующим двум осям:
Важно понимать, что это «неоднозначная ось» — интегрированней, не всегда значит лучше! Что-то приобретается (юзабилити стандартных сценариев, например), но что-то выплескивается вместе с водой! Теряется гибкость и некоторые возможности, которые разработчики (или, что хуже, маркетологи) посчитали ненужными! А иногда падает и юзабилити, когда куча лишней функциональности занимает интерфейс, но не используется разработчиком. Интегрированность иногда означает «интегрированность в рамках Одной Операционной Системы и Технологического Стека Одной Компании». Особенно это печально, в случае закрытой, платной системы, когда нет никакой возможности, что-то исправить, изменить, срезать углы… И уповать на платную поддержку бессмысленно — обычно платная поддержка это аутсорсинговый колл-центр, и повлиять на функциональность продукта «в свою сторону» — практически невозможно.
Рассмотрим существующие системы поддержки разработки под этим углом. Для иллюстрации представим картинку напоминающую «магический квадрат Gartnerа», но, предупреждаем, — она не претендует на точность и полноту, и нужна только для иллюстрации представляемых идей.  Итак, в левом нижнем квадранте отдельные, неинтегрированные системы поддержки разработки — трекеры, системы управления версиями. Их использование становится все менее и менее популярным, ибо даже несмотря на добротный функционал каждой из систем, разработчики не хотят тратить свое время на сложную интеграцию. Обычно система, интегрирующую их в единое целое представляет отдельный продукт, из левого верхнего квадранта. В левом верхнем квадранте живут монструозные платные системы, обычно интегрирующие системы вокруг IDE (Visual Studio или Eclipse), или с вебинтерфейсом. Да, интеграция вокруг Visual Studio очень удобна для разработчика, работающего только в технологическом стеке Microsoft, и если в фирме вся разработка такая — выбор может быть вполне оправдан. Если же часть компании работает с стеком J2EE, часть с LAMP, часть с Microsoft, часть — серверная логика на Oracle (и т. п.) — то все плюсы сразу становятся минусами. Общая очевидная проблема — необходимость платить, причем эта проблема может стать достаточно существенной. Например, стоимость лицензий может быть больше стоимости добротного железа для разработчика. Плюс, как правило, такие систем закрыты, отсутствует возможность модификации системы и при этом, в систему жестко зашита интеграция с выбранным производителем (а не пользователем) стеком инструментов, закодированы какие-нибудь методологии и прочие «best practices», часто устаревшие на десяток лет, или слабоприменимые в ситуации пользователя, от которых никак нельзя избавиться. Несмотря на платность, в большинстве случаев нельзя повлиять на линию развития софта, уговорить производителя сделать нужные пользователю доработки, а платная «многоуровневая» поддержка, только изолирует разработчика системы от проблем пользователей, и зачастую неэффективна. Так может рассмотреть открытые (бесплатные, и с открытым исходным кодом) интегрированные системы? Такие есть, но их проблема — ограниченная функциональность, ибо в основном они ориентируются на удовлетворение основных потребностей небольших команд разработчиков, и как швейцарский нож — вроде бы умеет все, но слабо. То есть да, все интегрировано, но там — слабенький трекер, тут — слабая вики-система, где-то ещё — неразвитая система прав. (Например, у Pivotal Tracker ее вообще нет! Все имеют права на все!). Да, это удобно для небольших команд, где все друг-другу доверяют, но в коммерческой разработке, когда в компании больше 10 человек, это, вероятно, начнёт сильно жать. В правом нижнем квадранте живут «свободные и дикие» системы, развивающиеся исключительно силой сообщества, и их жизнеспособность доказывает правильность концепций и уверенное юзабилити — иначе бы они уже вымерли, как это произошло с огромным множеством систем, заброшенных разработчиками и сообществом. То есть, тут собрались очень мощные системы — с тысячами разработчиков и десятками тысяч пользователей. Например,
Также там находятся свободные системы, для которых нет свободных систем аналогов (и даже аналогов в мире платного софта):
Проблемы этих систем в несколько (а иногда и сильно) хаотичном развитии, а также в том, что разные системы развиваются независимо друг от друга, у них непересекающиеся команды разработчиков, и их обычно используют по отдельности. Например, та же Bugzilla изнутри выглядит довольно страшно, хотя при этом работает и широко используется по всему миру. А в MediaWiki парсер статей не использует грамматики и не реентерабелен. На первый взгляд это вообще незаметно, но может начать «жать», когда ваши технологические процессы потребуют доработок. Ещё пример: MediaWiki — отличная, можно сказать, ведущая вики-система, но из-за основной направленности — открытые энциклопедии, в ней не развита система прав. И более того — несмотря на то, что многие пользователи запрашивают хорошую поддержку прав в MediaWiki, её архитектура была и остаётся открытой. И более того — хорошо, если так и останется. Причина в огромном числе расширений, уже написанных, и ничего не подозревающих о системе прав, и открытом доступе к БД из любого расширения. Почему же это хорошо? Хорошо это потому, что если бы этого не было, не было бы и этого огромного числа расширений («глобально-надёжные» системы вроде неторопливой «энтерпрайз-лэвел» Java — не конёк огромных открытых сообществ разработчиков), а следовательно, и система не была бы так популярна, а следовательно, и развитие её было бы тоже замедлено. И вообще, единая система прав и авторизации, — это самое важное, когда требуется «приручать диких животных» — то есть укрощать и интегрировать дикие вебсистемы. Итак, наиболее выгодная стратегия, чтобы получить самую мощную функциональность (включая юзабилити) и масштабируемость по разработчикам (бесплатность и отсутствие архитектурных ошибок) — это взять наиболее мощные системы с открытым кодом, интегрировать, и доработать с учетом своих процессов. Да, объем таких доработок будет относительно ничтожным, по сравнению с общим объемом системы (например, в MediaWiki больше 2 миллионов строчек кода и доработка/расширение в 100—200 строчек, будет меньше сотой доли процента). И о таких подходах часто рассказывают на конференциях (как докладчики, так и участники) и в интернете. Такие рассказы весьма полезны, ведь даже подбор правильных, не конфликтующих между собой инструментов, и проверка жизнеспособности получившейся «команды» опытом собственного использования — очень ценно. Однако утверждать, что это абсолютно «бесплатное» решение — это некоторое лукавство. На самом деле — эти «проценты» интегрирующего кода стоят весьма недешево, и поэтому мало кто готов повторить чужой опыт, несмотря на его открытость. Поэтому («Talk is cheap, show me the code» © Линус Торвальдс) мы идем на большее, — мы публикуем в open-source полностью все используемые нами системы, с доработками и расширениями. Кстати, еще одна проблема использования open-source — пользоваться им любят многие, но при этом не любят делиться своими доработками[2]. В наших доработках мы «объездили» эти дикие системы, сделав из разрозненного набора сплоченную команду, удобную для разработки в различных технологических стеках, для компании размером в несколько сотен человек. Решена проблема с единой авторизацией и системой прав, сделано множество расширений для удобства разработчиков, аналитиков и тестировщиков, и все это проверено многолетним опытом использования. Теперь мы предлагаем сообществу совершенно бесплатно установить все это у себя, и возможно, присоединиться к развитию этого инструментального фреймворка, ведь у вас будет отличный, гибкий выбор — насколько вы готовы тратить свои силы, чтобы подогнать эти системы под ваши процессы, и насколько вы готовы менять свои процессы, чтобы бесплатно использовать растущий функционал этих систем, развиваемых внешним сообществом.
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
|
 |
 |
 |
Кстати, все больше распространяется мнение, что открытость софта позитивно коррелирует с качеством, надежностью и дешевизной техподдержки