Персональные инструменты
 

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

Материал из CustisWiki

Перейти к: навигация, поиск
м (1 версия)
м
 
(не показано 10 промежуточных версий 3 участников)
Строка 1: Строка 1:
Выступление [http://belonesox.moikrug.ru Стаса Фомина] на конференции «[http://ritconf.ru/abstracts/565.html РИТ-2010]».
+
Выступление [[:Категория:Стас Фомин|Стаса Фомина]] на конференции «[http://ritconf.ru/abstracts/565.html РИТ-2010]».
  
 
== Видеопрезентация ==
 
== Видеопрезентация ==
<html>
 
<center>
 
<object height="360" width="640"><param name="allowfullscreen" value="true"><param name="allowscriptaccess" value="always"><param name="movie" value="http://vimeo.com/moogaloop.swf?clip_id=10909721&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=0&amp;show_portrait=0&amp;color=00ADEF&amp;fullscreen=1"><embed src="http://vimeo.com/moogaloop.swf?clip_id=10909721&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=0&amp;show_portrait=0&amp;color=00ADEF&amp;fullscreen=1" type="application/x-shockwave-flash" allowfullscreen="true" allowscriptaccess="always" height="360" width="640"></object>
 
  
</center>
+
{{vimeoembed|10909721|720|404}}
</html>
+
 
+
Скачать видео: [[Видеотека#2010-04-14 РИТ-2010: «Свободные системы,  спасающие разработчиков»]]
+
  
 
== Тезисы ==
 
== Тезисы ==
Строка 26: Строка 20:
 
; «Ничего» : Подход небольших или анархичных команд, часто не использующих даже контроль версий. Проблемы такого подхода очевидны.
 
; «Ничего» : Подход небольших или анархичных команд, часто не использующих даже контроль версий. Проблемы такого подхода очевидны.
 
; «Свой велосипед» : Эффективные фреймворки сделали вебразработку достаточно легкой и быстрой, и многие увлекаются переизобретением велосипедов — реализацией собственных систем, например, учета задач и ошибок или вики-систем. Проблемы начинают проявлятся спустя время, когда обнаруживается, что приходится тратить немало времени на поддержку и развитие этих систем и обучение персонала использованию этих «самоделок», малоизвестных за пределами компании.
 
; «Свой велосипед» : Эффективные фреймворки сделали вебразработку достаточно легкой и быстрой, и многие увлекаются переизобретением велосипедов — реализацией собственных систем, например, учета задач и ошибок или вики-систем. Проблемы начинают проявлятся спустя время, когда обнаруживается, что приходится тратить немало времени на поддержку и развитие этих систем и обучение персонала использованию этих «самоделок», малоизвестных за пределами компании.
; «Ящик Вендоров» : Использование интегрированного закрытого платного инструментария. Общая очевидная проблема — платность, причем могущей быть достаточно существенной, например, стоимость лицензий может быть больше стоимости добротного железа для разработчика. Плюс, как правило, такие систем закрыты, отсутствует возможность модификации системы и при этом, в систему жестко зашита интеграция с выбранным производителем (а не пользователем) стеком инструментов, закодированы какие-нибудь методологии и прочие «''best practices''», часто устаревшие на десяток лет, или слабоприменимые в ситуации пользователя, от которых никак нельзя избавится. Несмотря на платность, в большинстве случаев нельзя повлиять на линию развития софта, уговорить производителя сделать нужные пользователю доработки, а платная «многоуровневая» поддержка, только изолирует разработчика системы от проблем пользователей, и зачастую неэффективна.
+
; «Ящик Вендоров» : Использование интегрированного закрытого платного инструментария. Общая очевидная проблема — платность, причем могущей быть достаточно существенной, например, стоимость лицензий может быть больше стоимости добротного железа для разработчика. Плюс, как правило, такие систем закрыты, отсутствует возможность модификации системы и при этом, в систему жестко зашита интеграция с выбранным производителем (а не пользователем) стеком инструментов, закодированы какие-нибудь методологии и прочие «''best practices''», часто устаревшие на десяток лет, или слабоприменимые в ситуации пользователя, от которых никак нельзя избавится. Несмотря на платность, в большинстве случаев нельзя повлиять на линию развития софта, уговорить производителя сделать нужные пользователю доработки, а платная «многоуровневая» поддержка, только изолирует разработчика системы от проблем пользователей, и зачастую неэффективна. А упования на то, что платные системы де, не ломаются, и всегда удовлетворяют пользователя ''as-is'' напоминают классику:
 +
<blockquote>
 +
ОСНОВНОЕ  РАЗЛИЧИЕ  МЕЖДУ  ПРЕДМЕТОМ,  КОТОРЫЙ  МОЖЕТ  ИСПОРТИТЬСЯ,  И ПРЕДМЕТОМ КОТОРЫЙ ИСПОРТИТЬСЯ  НЕ  МОЖЕТ,  СОСТОИТ  В  ТОМ,  ЧТО  ПРЕДМЕТ, КОТОРЫЙ НЕ  МОЖЕТ  ИСПОРТИТЬСЯ,  НЕВОЗМОЖНО  ПОЧИНИТЬ.  ЕСЛИ  ОН  ВСЕ-ТАКИ ИСПОРТИЛСЯ... ©[http://lib.ru/ADAMS/hitch_5.txt Дуглас Адамс. В основном безвредна]
 +
</blockquote>
  
 
С другой стороны, в мире ''open-source'' уже завелся целый зоопарк различных, конкурирующих между собой систем, решающих эти проблемы по отдельности. Возможно по отдельности они выглядят часто ''unsexy ''— неказисто, даже забавно, в общем, как «герои типичного американского комикса про героев» (такая вот тавтология, да). Если удастся собрать эффективную команду — то есть выбрать правильные, не конфликтующие между собой инструменты, грамотно их построить, то эти системы совершенно бесплатно спасут разработчиков от вышеперечисленных проблем, то есть один раз выбрав и разобравшись в этих системах, можно будет наращивать команду, открывать дополнительные филиалы, в общем, масштабировать компанию, не неся дополнительных затрат. Причем эти открытость кода «спасателей» и большая пользовательская база, всегда дают вам гибкий выбор — насколько вы готовы тратить свои силы, чтобы подогнать эти системы под ваши процессы, и насколько вы готовы менять свои процессы, чтобы бесплатно использовать растущий функционал этих систем, развиваемых внешним сообществом.
 
С другой стороны, в мире ''open-source'' уже завелся целый зоопарк различных, конкурирующих между собой систем, решающих эти проблемы по отдельности. Возможно по отдельности они выглядят часто ''unsexy ''— неказисто, даже забавно, в общем, как «герои типичного американского комикса про героев» (такая вот тавтология, да). Если удастся собрать эффективную команду — то есть выбрать правильные, не конфликтующие между собой инструменты, грамотно их построить, то эти системы совершенно бесплатно спасут разработчиков от вышеперечисленных проблем, то есть один раз выбрав и разобравшись в этих системах, можно будет наращивать команду, открывать дополнительные филиалы, в общем, масштабировать компанию, не неся дополнительных затрат. Причем эти открытость кода «спасателей» и большая пользовательская база, всегда дают вам гибкий выбор — насколько вы готовы тратить свои силы, чтобы подогнать эти системы под ваши процессы, и насколько вы готовы менять свои процессы, чтобы бесплатно использовать растущий функционал этих систем, развиваемых внешним сообществом.
Строка 54: Строка 51:
 
Изложенный опыт можно легко повторить, ибо мы рассказываем только об общедоступных и бесплатных системах, более того, мы собираемся публиковать все наши разработки в open-source, так что слушатели смогут мгновенно инсталлировать и внедрить все, о чем мы расскажем.
 
Изложенный опыт можно легко повторить, ибо мы рассказываем только об общедоступных и бесплатных системах, более того, мы собираемся публиковать все наши разработки в open-source, так что слушатели смогут мгновенно инсталлировать и внедрить все, о чем мы расскажем.
  
 +
{{ActualBanner}}
 
{{replicate-from-custiswiki-to-lib}}
 
{{replicate-from-custiswiki-to-lib}}
 
[[Категория:Открытые Семинары]]
 
[[Категория:Открытые Семинары]]
 +
[[Категория: Менеджмент (доклады)]]
 +
[[Категория:Инструменты разработки (доклады)]]
 +
[[Категория:Стас Фомин]]

Текущая версия на 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, так что слушатели смогут мгновенно инсталлировать и внедрить все, о чем мы расскажем.



Репликация: База Знаний «Заказных Информ Систем» → «Свободные системы, спасающие разработчиков (РИТ-2010)»

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