|
Персональные инструменты |
![]() |
||
|
![]() |
![]() Золотая середина. Открытые системы поддержки разработки (Стас Фомин, ADD-2010)Материал из CustisWiki(перенаправлено с «2010-09-22-oss-golden-mean-fomin»)
Короткая ссылка: 2010-09-22-oss-golden-mean-fomin СодержаниеАннотация
Расширенная аннотацияЛюбая коллективная разработка программного обеспечения сталкивается с одними и теми же проблемами:
Да, эффективные фреймворки сделали вебразработку достаточно легкой и быстрой, и многие увлекаются переизобретением велосипедов — реализацией собственных систем, например, учета задач и ошибок или вики-систем. Проблемы начинают проявлятся спустя время, когда обнаруживается, что приходится тратить немало времени на поддержку и развитие этих систем и обучение персонала использованию этих «самоделок», малоизвестных за пределами компании. Поэтому дальше мы рассмотрим только разумный подход выбора, интеграции и доработки, ведь «свято поле пусто не бывает» и существуют сотни, если не тысячи, систем для решения этих проблем. Да, полно разных классификаций функциональности, которую должны обеспечивать эти системы 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». |
![]() |
![]() |
![]() |