Свободные системы, спасающие разработчиков (РИТ-2010)

Короткая ссылка: OpenSourceSystemsRIT2010

Ссылки сюда (8) →

Выступление Стаса Фомина на конференции «РИТ-2010».

Видеопрезентация

Видео в HD-качестве, смотрите в полноэкранном режиме.

HTML-код включения <iframe src="http://player.vimeo.com/video/10909721?byline=0&portrait=0" width="720" height="404" frameborder="0"></iframe>

Тезисы

Постановка проблемы, которой посвящён доклад:

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

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

Несмотря на то, что проблемы для всех достаточно общие, каждый решает эти проблемы по-разному, на наш вгляд, часто впадая в следующие крайности:

«Ничего» 

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

«Свой велосипед» 

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

«Ящик Вендоров» 

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

ОСНОВНОЕ РАЗЛИЧИЕ МЕЖДУ ПРЕДМЕТОМ, КОТОРЫЙ МОЖЕТ ИСПОРТИТЬСЯ, И ПРЕДМЕТОМ КОТОРЫЙ ИСПОРТИТЬСЯ НЕ МОЖЕТ, СОСТОИТ В ТОМ, ЧТО ПРЕДМЕТ, КОТОРЫЙ НЕ МОЖЕТ ИСПОРТИТЬСЯ, НЕВОЗМОЖНО ПОЧИНИТЬ. ЕСЛИ ОН ВСЕ-ТАКИ ИСПОРТИЛСЯ... ©Дуглас Адамс. В основном безвредна

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

Краткое перечисление основных вопросов, освещённых в докладах:

Мы расскажем о нашей «команде Хранителей» — то есть выбранном нами наборе бесплатных open-source систем:

Bugzilla

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

MediaWiki

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

Subversion

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

ViewVC

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

SVNSearch

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

Testopia

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

FeedOnFeeds

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

и некоторых других.

Мы объясним, почему был сделан именно этот выбор, и покажем, как накрыть этими системами проблемы разработки и связать эти системы друг с другом.

Оценка значимости и области применимости излагаемой в докладе информации:

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

Область применимости — абсолютно любая разработка ПО, если разумеется, есть возможность выбирать системы поддержки (то есть они не навязаны заказчиком). Изложенный опыт можно легко повторить, ибо мы рассказываем только об общедоступных и бесплатных системах, более того, мы собираемся публиковать все наши разработки в open-source, так что слушатели смогут мгновенно инсталлировать и внедрить все, о чем мы расскажем.

---

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