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

Текущая версия на 18:32, 10 января 2012

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

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

Тезисы

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

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

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

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

«Ничего» 

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

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

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

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

Использование интегрированного закрытого платного инструментария. Общая очевидная проблема — платность, причем могущей быть достаточно существенной, например, стоимость лицензий может быть больше стоимости добротного железа для разработчика. Плюс, как правило, такие систем закрыты, отсутствует возможность модификации системы и при этом, в систему жестко зашита интеграция с выбранным производителем (а не пользователем) стеком инструментов, закодированы какие-нибудь методологии и прочие «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, так что слушатели смогут мгновенно инсталлировать и внедрить все, о чем мы расскажем.

Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».