Difference between revisions of "Wiki-Way"
(→Выбор систем) |
|||
(One intermediate revision by the same user not shown) | |||
Line 2: | Line 2: | ||
big { font-size: 200%; } | big { font-size: 200%; } | ||
</slidecss> | </slidecss> | ||
− | <slideshow title="Эволюция Wiki-Way командной разработки" author="Виталий Филиппов, Стас Фомин, [http://custis.ru/ CUSTIS]" style="devconf" scaled="true" font="Calibri, Segoe Print, cursive" footer="" headingmark="⌘⌘" /> | + | <slideshow title="Эволюция Wiki-Way командной разработки" author="Виталий Филиппов, Стас Фомин, [http://custis.ru/ CUSTIS]" style="devconf" scaled="true" font="Calibri, Segoe Print, cursive" footer="" subfooter="Виталий Филиппов, Стас Фомин, [http://custis.ru/ CUSTIS]" headingmark="⌘⌘" /> |
Мы хотим кратко рассказать историю развития open-source систем поддержки разработки в нашем корпоративном интранете, которая чудесным образом совпала с мировой тенденцией развития командной разработки. | Мы хотим кратко рассказать историю развития open-source систем поддержки разработки в нашем корпоративном интранете, которая чудесным образом совпала с мировой тенденцией развития командной разработки. | ||
Line 55: | Line 55: | ||
== Выбор систем == | == Выбор систем == | ||
− | <slides | + | <slides title="Выбор систем" float="right" width="400"> |
− | + | ||
;Ящик Вендора: {{c|#a00|Закрытый, сильносвязанный, платный}} | ;Ящик Вендора: {{c|#a00|Закрытый, сильносвязанный, платный}} | ||
;Велосипед: {{c|#f80|Быстро создать}}, {{c|#a00|тяжело поддерживать}} | ;Велосипед: {{c|#f80|Быстро создать}}, {{c|#a00|тяжело поддерживать}} |
Latest revision as of 15:13, 26 December 2011
Мы хотим кратко рассказать историю развития open-source систем поддержки разработки в нашем корпоративном интранете, которая чудесным образом совпала с мировой тенденцией развития командной разработки.
У нас она начиналась с идей:
- Open-Source
- нет жестких ограничений — гибкость и опыт масс в одном флаконе.
- Wiki + баг-трекер + система контроля версий
- достаточно для всего.
- Правильная вики ⇒ MediaWiki
- мэйнстрим + расширяемость.
Кроме того, мы (в конце 2010г) наконец-то выполнили обещание выйти в Open-Source и теперь существует проект 4intra.net («фор интранет», то есть, «для интранета»), который вы можете попробовать своими руками.
Например, расширяемость превращает MediaWiki не просто в базу знаний или инструмент документирования, а даёт возможность сделать такие нетривиальные «плюшки», как
- система информационных потоков (читай — форумов и блогов),
- презентаций,
- опросов и экзаменов,
- личный «кэш» сетевых закладок
и так далее.
Не говоря уже о расширенных медиа-возможностях — вставке изображений и видео, графов и графиков, UML и MindMap’ов, TeX и прочих «фичах».
О том, как мы пришли к своему выбору, почему он всё больше совпадает с мировой практикой, что представляют из себя все эти, а также многие другие вкусности, реализуемые с помощью MediaWiki, Bugzilla, SVN, ViewVC, FeedOnFeeds и так далее, и о том, куда двигаться дальше, и будет доклад.
Wiki-Way и выбор систем
При начале разработки дизайн чего-то нового, доселе неизведанного, обычно либо глубоко проектируется в самом начале (инженерный подход), либо эволюционирует, начиная с заложенного изначально минимума.
Wiki-Way мы называем именно натуральный эволюционный подход с максимально упрощёнными концепциями. Вообще говоря, кто-то другой мог назвать его ещё как-нибудь — хоть «Web 2.0», хоть «гибкий», хоть «Agile», но мы выбрали термин «Wiki-Way» — Wiki являются его апогеем.
Этот конфликт, между «жестким, заданным априори» и «гибким, адаптирующимся к меняющимся потребностям пользователя и ограничениям среды» встречается повсеместно. В культуре разработке кстати тоже, рекомендуем вам взглянуть на книгу «lib:Культуры программных проектов (Энтони Лаудер)» — там этот конфликт выражен противоречием между «заводской» и «сервисной» культурой (offtopic: с очень неоднозначным положением культуры «дизайнерской»).
Выбор систем
- «Ящик Вендора»
- Закрытые платные системы крупных производителей («вендоров»).
- «Велосипед» или «Лунапарк»
- Да, то самое, что нестерпимо хочется изобрести самому, и сделать это обязательно с блекджеком и шлюхами ©.
- «Жадный интегратор» или «Футбол Хоттабыча»
- поставить все что можно (особенно если бесплатные системы) и потом пытаться все это интегрировать, а пользователей учить всем этим пользоваться.
Ящик Вендора: Плюсы? Минусы? ⌘⌘
- Платный, вендорский
-
«☺ Наверное, качественный?» - ☹ Vendor lock-in !
- ☹ Может быть и недёшев !
-
- Сильносвязанный
-
«☺ Отлично, всё интегрировано?» - ☹ Шаг в сторону — считается побег !
- ☹ Меньше думать может оказаться вредно
-
- Закрытый
-
«☺ Кому в нём копаться?» - ☹ Недостатки не исправить !
-
Велосипед
YATUP ⌘⌘
CLOC ⌘⌘
- MediaWiki: 185000 PHP, 577000 локализация
- Bugzilla 3.6: 72000 Perl, 35000 TT
- 4.0: +10000 Perl, +3000 TT
И в них ведь есть какой-то смысл (!)
Может, не стоит писать заново ?
Сочетание систем
Идея родилась у нас ещё N (≈ 8) лет назад[1], а в последнее время, похоже, распространяется всё больше и больше, возьмите хотя бы Google Code или любой GitHub / Bitbucket / Launchpad.
Логика была следующая — почти все объекты, с которыми приходится иметь дело разработчику, можно разделить на три части:
- Ответственность
- то, что нужно сделать или исправить, в каком состоянии какие задачи, проблемы и ошибки, кто за них ответственный и т.п.
- Артефакты
- всё то, что является результатом разработки. Код, дистрибутивы, отгружаемая документация.
- Знания
- то, благодаря чему разработка становится возможна. Аналитика, крупные постановки задач, функциональные и нефункциональные требования, документация (внутренняя и внешняя и т.п.).
В этой троице каждому из типов соответствует (одна!) своя система, что и даёт такое удобство. Wiki для знаний, VCS для артефактов, issue-трекер для задач и багов.
Частично они могут пересекаться. На самом деле, набор этих систем столь мощный, что можно «отрубить» одну или даже две, и оставшиеся всё равно будут пытаться «покрывать» большую часть процессов. И при этом они будут конкурировать, и вытеснять более специализированные системы[2]. Ну и мы знаем несколько неудачных случаев попытки интеграции большего числа более специализированных систем (подобранных по принципу «футбол Хоттабыча» — «для каждого типа объекта в разработке пусть будет самая лучшая специализированная система его учета»)[3]
С чем имеет дело разработчик? ⌘⌘
- Код, тесты
- Баги, задачи, постановки
- Документация
- Новости, обсуждения
- …
А бешеный заяц на слайде выше — это Мартовский заяц из Диснеевской Алисы в Стране чудес, иллюстрирующий CVSnt, очень сомнительного качества доработанный CVS, произведённый на свет компанией March Hare Software.
Кстати, в это трудно поверить, но надо признаться, что у нас в компании до сих пор есть проекты использующие CVS. Использование CVS обусловлено накопленным legacy-опытом (специальные утилиты deploy и testing, завязанные на CVS), плюс legacy-технологии таковы, что переход на SVN или DVCS почти ничего не дает (ветвится вокруг неизменной терабайтной базы бессмысленно, переименования серверных пакетов чрезвычайно редки и т.п.). В общем, CVS у нас работает, как до сих пор работают паровозы в Китае, и мы рассчитываем, что он отомрет естественно, вместе со сменой legacy-технологий.
ViewVC
Для нас большой плюс, что он поддерживает и SVN и CVS (см. выше).
ViewVC ⌘⌘
ViewVC → web-интерфейс к CVS & SVN- Его можно считать частью VCS.
- У git и hg веб-интерфейс вообще в стоке.
- Тоже чуть докручен
Трекер и вики
Epic Win’ы MediaWiki ⌘⌘
- Расширяемость:
1700 расширений и очень легко пишутся - Отсутствие суррогатных ID:
http://lib.custis.ru/Как_прекратить_писать_(Андрей_Аксенов_на_ADD-2010) - Производительность и кэши:
Ну, Wikipedia же ворочается! - Локализация:
352 локали (!)
Альтернативы
Далее мы рассмотрим некоторые альтернативы своему выбору - может быть, не до конца оптимальному, но выросшему эволюционно и используемому успешно.
VCS
Что такое VCS (система контроля версий), надеемся, известно всё-таки уже всем[1]. Для тех, кто в танке — это система, помогающая хранить не одну версию файлов продукта, а много сразу, в любой момент возвращаться к любой версии, просматривать информацию о версиях и т. п. Первой системой контроля версий был RCS, потом из него вырос CVS, а после CVS появился Subversion для «свержения» (англ. subversion) и исправления недостатков CVS’а.
CVS и Subversion — наиболее распространённые представители централизованных систем, в который репозиторий (хранилище версий) располагается на одном «центральном» сервере, а на компьютерах разработчиков размещаются только «рабочие копии», соответствующие какой-то одной версии. Модной в последнее время альтернативой этому подходу являются распределённые системы управления версиями, хранящие весь репозиторий в каждой рабочей копии.
Что важно для удобства, DVCS поддерживают расширенные возможности отслеживания ветвлений и объединения изменений, потому что без этого объединять безумные графы изменений, приходящих от разных разработчиках в OpenSource проектах, было бы невозможно.
Самые известные lib:DVCS — это Git, Mercurial (hg) и Bazaar. Возможно, вы также слышали о Darcs и Monotone. Хранение полной истории ревизий в каждой рабочей копии, кроме всего прочего, даёт ещё и «естественное резервное копирование».
DVCS сейчас действительно «в моде», это даже подтверждают данные двух одинаковых опросов от 26 октября 2009 и 2010 годов на Хабре — SVN и CVS потеряли 3 % и 5 %, а Git и Hg приобрели те же 5.5 % и 3 %.
Bazaar, правда, потерял полпроцента (а я говорил! И не только я).
Так или иначе, производимые артефакты хранятся в системе контроля версий, этим уже никого не удивишь, запомним это.
Статистика ⌘⌘
DVCS в моде ⌘⌘
За год:
- Git, Hg ↑ 5.5 %, 3 %
- SVN, CVS ↓ 3 %, 5 %
- Bazaar ↓ 0.5 % (hate and hate)
Недостатки DVCS — текст
Есть у DVCS и некоторые недостатки: например, то, что размер репозитория со временем сильно растёт, не очень удобно. Хороший пример — это исходники Андроида, хранящиеся в Git. Чтобы попытаться собрать хотя бы recovery (образ «консоли восстановления» для телефона), нужно выкачать 4.8 Гб исходников! Также, говорят, бывает, что разработчики начинают много коммитить локально, а потом «сбрасывают кодовые бомбы» на остальных. Как к этому относиться — личное дело каждого, можно считать, что виноваты всё-таки разработчики, а не DVCS (те самые «80 %» разработчиков — наверное, быдлокодеров). Также менеджеры негодуэ, потому что невозможен контроль доступа к частям репозитория. Но если это жмёт, нужно просто разбить репозитории на несколько и немного упростить выдачу прав. Ну, а «корпоративный народ» может отнестись к этим системам, пришедшим из мира Opensource, не очень хорошо. В общем и целом, все недостатки решаемые.
Bug Tracker
Bug Tracker — это система отслеживания задач (а не только ошибок). Очень часто «баг» рассматривают именно как «ошибку», хотя это вопрос терминологии — в реальности, «багом» можно назвать любую задачу, запрос и т. п. — любое нечто, исходящее от кого-то одного и требующее реакции от кого-то другого. В силу широты формулировки и наличия большого множества задач, большинство баг-трекеров устроено и выглядит монстровато.
Казалось бы, и баг-трекером уже никого не удивишь, но оказывается, и это не так. Часто для разных задач используется всё что угодно, но только не баг-трекер. Причиной для этого может являться чрезмерная «специфичность» используемой системы, когда менеджерским взглядом в неё вкручены диаграммы Ганта и прочие радости (один из разработчиков Luxproject’а использует для разных задач всё что угодно, только не Luxproject[1]).
Bug Tracker ⌘⌘
- «Bug» != «Ошибка» ! ! !
- «Bug» = ∀ (любая) задача:
- Ошибка, запрос фичи, вопрос поддержке
Хотя различать любят:
…I define a bug as behavior in a «Done» story that violates valid expectations…
Wiki
Сейчас на дворе уже третье тысячелетие, через пару лет, то ли конец света будет, то ли Великая Сингулярность, то ли нефть кончится, и рассказывать что такое вики-системы и чем они хороши, вроде как страшный баян. И все же, если вдруг будет время, то у нас (опять-таки!), есть статья и выступление на конференции по этой теме[1].
Вики-движки ⌘⌘
http://wikimatrix.org/ - вики-движков > 130!
Популярные:
MediaWiki (Wikipedia) | MoinMoin | DokuWiki |
---|
Win / Fail ⌘⌘
Win: гипертекств абсолюте ! ☺
Fail: плохо с атрибутикой ☹
- Однако, гипертекст rules, если есть поиск*
- Есть Semantic MediaWiki
* Goo… Guess who?
4intra.net и наши доработки
Однако «дикая» MediaWiki для компании-разработчика не особо хороша, и конечно при сравнении «в лоб» проигрывает «специально обученным корпоративным вики-системам».
Но если «укротить» и немного обработать напильником, MediaWiki становится фантастически удобной системой для компании-разработчика, решающая практически все проблемы управления знаниями, требованиями, тестами и т. п., которые могут возникнуть[1].
Затратив еще немного сил (как обычно, с использованием «напильника и такой-то матери»), можно эффективно «увязать» то небольшое число готовых, вышеупомянутых систем, получив шикарный интранет-разработчика «with Black Jack & Hookers»©[2].
И мы уже прошли этот путь, отобрали самые интересные расширения, доработали и переработали их, написали кучу своих, и даже решали проблемы производительности и разгона[3], управления правами (самое уязвимое место «природной MediaWiki»), научив все веб-системы не только «плеваться почтой», но и смиренно отдавать RSS-feedы, а всех сотрудников — пользоваться RSS-агрегаторами (и даже развернув корпоративный «Google Reader» — FeedOnFeeds. И все это готовое предлагаем вам совершенно свободно и даром[4].
Нет, это не было изобретением велосипедов, объем доработок по сравнению с объемом trunkа был невелик, сначала это было практически хобби (10 % времени) одного веб-любителя, но теперь этим (хотя и не на 100 %) стал заниматься настоящий веб-профессионал, и нам уже не стыдно выкладывать все это в open-source.
Кроме того, большинство доработок оформлены в виде расширений MediaWiki, и поэтому в будущем не умрут, как это обычно случается с «велосипедами», а останутся рабочими и доступными для сообщества.
FeedOnFeeds ⌘⌘
4intra.net ⌘⌘
Opensource с декабря 2010
- MediaWiki4Intranet
- ~60 расширений, ~40 патчей, установка hg clone
- Bugzilla4Intranet
- > 100 фич/изменений
Mindmap ⌘⌘
Медиавозможности ⌘⌘
- LaTeX
- Graphviz, UML, Gnuplot
- SVG, PDF, DjVu, TIFF, Flash Video, Mindmap
- подсветка синтаксиса
Wiki-плюшки ⌘⌘
|
|
* что почти одно и то же
Интеграция ⌘⌘
Ещё интеграция ⌘⌘
Куда двигаться дальше? ⌘⌘
- Правильная Bugzilla
- ??? а стоит ли?
- Тесты, code review → Wiki
- Semantic Wiki
Правильная Bugzilla ⌘⌘
- С одной стороны, Bugzilla отстаёт от bleeding-edge
- Usability + Refactoring
- Зато пока остальные делают
, она сохраняет HTML-простоту
- А потом нагонит на стандартах
LOR, Debian vs Ubuntu ⌘⌘
> этих хомячков в сотни раз больше и именно на них ориентируюся производители ОС
Когда делают операционную систему по dfsg, тогда ориентируются, прежде всего, на dfsg, а не играют в волшебников с голубыми вертолётами «хрен с ней, со свободой, главное игрушки». И благодаря этим неволшебникам, и существует, в том числе и убунта.
Ну будет Debian делать всё, как убунта, получится две убунты и ни одного дебиана, и, как следствие, ни одной убунты.
Не учите отцов, как им делать. Особенно, если вообще ничего не понимаете и ничего не решаете, а просто плывёте в потоке, ведь это единственные, кто думают о вашем завтра, чтобы не оказалось, что завтра вы уже не контролируете ровным счётом ничего.
Usability ⌘⌘
![Rugby_scrum.jpg](/images/c/ce/Rugby_scrum.jpg)
- JS grid
- «Форум-функционал»
- Agile
- (вкрутить разумный минимум)
Refactoring ⌘⌘
- Переделать систему прав*
- * кто-то понимает MANDATORY/SHOWN/DEFAULT/NA ?
-
убить YAHOO UI → jQuery
-
копипасту → прокачать объектный движок
-
CGI.pm (детище 90-х…)
-
Template Toolkit
- или хотя бы
обратную связь из шаблонов
- или хотя бы
Semantic Wiki ⌘⌘
- «Семантическая Wiki»,
- Она же Wiki с атрибутикой - http://semantic-mediawiki.org/
- Semantic Tracker
- В пень Custom Fields!
Примечания
Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.
Статья отреплицирована из внутренней базы знаний компании.