|
Свободные системы, спасающие разработчиков (РИТ-2010) — различия между версиями
Материал из CustisWiki
|
|
| (не показано 8 промежуточных версий 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&server=vimeo.com&show_title=1&show_byline=0&show_portrait=0&color=00ADEF&fullscreen=1"><embed src="http://vimeo.com/moogaloop.swf?clip_id=10909721&server=vimeo.com&show_title=1&show_byline=0&show_portrait=0&color=00ADEF&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 ''— неказисто, даже забавно, в общем, как «герои типичного американского комикса про героев» (такая вот тавтология, да). Если удастся собрать эффективную команду — то есть выбрать правильные, не конфликтующие между собой инструменты, грамотно их построить, то эти системы совершенно бесплатно спасут разработчиков от вышеперечисленных проблем, то есть один раз выбрав и разобравшись в этих системах, можно будет наращивать команду, открывать дополнительные филиалы, в общем, масштабировать компанию, не неся дополнительных затрат. Причем эти открытость кода «спасателей» и большая пользовательская база, всегда дают вам гибкий выбор — насколько вы готовы тратить свои силы, чтобы подогнать эти системы под ваши процессы, и насколько вы готовы менять свои процессы, чтобы бесплатно использовать растущий функционал этих систем, развиваемых внешним сообществом. |
| Строка 57: |
Строка 54: |
| | {{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».
|
 |
