Wiki-Way

From Wiki4Intranet
Jump to: navigation, search
Author

Виталий Филиппов
Subfooter

Виталий Филиппов, 15:13, 26 December 2011

Эволюция Wiki-Way командной разработки

Виталий Филиппов, Стас Фомин

CUSTIS

Мы хотим кратко рассказать историю развития open-source систем поддержки разработки в нашем корпоративном интранете, которая чудесным образом совпала с мировой тенденцией развития командной разработки.

У нас она начиналась с идей:

Open-Source
нет жестких ограничений — гибкость и опыт масс в одном флаконе.
Wiki + баг-трекер + система контроля версий
достаточно для всего.
Правильная вики ⇒ MediaWiki
мэйнстрим + расширяемость.

Кроме того, мы (в конце 2010г) наконец-то выполнили обещание выйти в Open-Source и теперь существует проект 4intra.net («фор интранет», то есть, «для интранета»), который вы можете попробовать своими руками.

Например, расширяемость превращает MediaWiki не просто в базу знаний или инструмент документирования, а даёт возможность сделать такие нетривиальные «плюшки», как

  • система информационных потоков (читай — форумов и блогов),
  • презентаций,
  • опросов и экзаменов,
  • личный «кэш» сетевых закладок

и так далее.

Не говоря уже о расширенных медиа-возможностях — вставке изображений и видео, графов и графиков, UML и MindMap’ов, TeX и прочих «фичах».

О том, как мы пришли к своему выбору, почему он всё больше совпадает с мировой практикой, что представляют из себя все эти, а также многие другие вкусности, реализуемые с помощью MediaWiki, Bugzilla, SVN, ViewVC, FeedOnFeeds и так далее, и о том, куда двигаться дальше, и будет доклад.

Wiki-Way и выбор систем

Парадигма проектирования нового

Blueprint.png Инженерная
Джамшут-Лестница.png

Парадигма проектирования нового

Файл:ParaWiki.jpg

Wiki-Way

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

Wiki-Way мы называем именно натуральный эволюционный подход с максимально упрощёнными концепциями. Вообще говоря, кто-то другой мог назвать его ещё как-нибудь — хоть «Web 2.0», хоть «гибкий», хоть «Agile», но мы выбрали термин «Wiki-Way» — Wiki являются его апогеем.

Ещё частично это напоминает классификацию из книги «lib:Культуры программных проектов (Энтони Лаудер)» — там автор приводит 4 культуры: научная, заводская, дизайнерская и сервисная.

Выбор систем ⌘⌘

  • Ящик Вендора
    • Закрытый, сильносвязанный, платный
  • Велосипед
    • Быстро создать, тяжело поддерживать

Ящик Вендора

BlackBox.jpg

Interlinked.gif

LockedLock.jpg

Handcuffs.jpg

Ящик Вендора: Плюсы? Минусы? ⌘⌘

  • Платный, вендорский
    • «☺ Наверное, качественный?»
    • ☹ Vendor lock-in !
    • ☹ Может быть и недёшев !
  • Сильносвязанный
    • «☺ Отлично, всё интегрировано?»
    • ☹ Шаг в сторону — считается побег !
    • ☹ Меньше думать может оказаться вредно
  • Закрытый
    • «☺ Кому в нём копаться?»
    • ☹ Недостатки не исправить !

Велосипед

Велосипед

Файл:Bicycle.gif

Пользователи: *FACEPALM*

Админы: *FACEPALM*
Программист: (сбежал)

CLOC ⌘⌘

  • MediaWiki: 185000 PHP, 577000 локализация
  • Bugzilla 3.6: 72000 Perl, 35000 TT
    • 4.0: +10000 Perl, +3000 TT

И в них ведь есть какой-то смысл (!)

Может, не стоит писать заново ?

Всё это .

А как ?

MainStream!

Сочетание систем

Идея родилась у нас ещё N (≈ 7) лет назад[1], а в последнее время, похоже, распространяется всё больше и больше, возьмите хотя бы Google Code или любой GitHub / Bitbucket / Launchpad.

Идея заключается в том, что почти все объекты, с которыми приходится иметь дело разработчику, можно разделить на три части:

Ответственность
то, что нужно сделать или исправить, в каком состоянии какие задачи, проблемы и ошибки, кто за них ответственный и т.п.
Артефакты
всё то, что является результатом разработки. Код, дистрибутивы, отгружаемая документация.
Знания
то, благодаря чему разработка становится возможна. Аналитика, крупные постановки задач, функциональные и нефункциональные требования, документация (внутренняя и внешняя и т.п.).

В этой троице каждому из типов соответствует (одна!) своя система, что и даёт такое удобство. Wiki для знаний, VCS для артефактов, issue-трекер для задач и багов.

Частично они могут пересекаться. На самом деле, набор этих систем столь мощный, что можно «отрубить» одну или даже две, и оставшиеся всё равно будут пытаться «покрывать» большую часть процессов. И при этом они будут конкурировать, и вытеснять более специализированные системы[2]. Ну и мы знаем несколько неудачных случаев попытки интеграции большего числа более специализированных систем (подобранных по принципу «футбол Хоттабыча» — «для каждого типа объекта в разработке пусть будет самая лучшая специализированная система его учета»)[3]

Wiki + трекер + VCS ⌘⌘

Сочетание используется всё чаще:

Trac

GitHub, Bitbucket, Google Code, Launchpad

Github.png Bitbucket.png GoogleCode.jpg

С чем имеет дело разработчик? ⌘⌘

  • Код, тесты
  • Баги, задачи, постановки
  • Документация
  • Новости, обсуждения
Файл:DevCircles-NoCircles.svg
  1. Ну вообще-то, эволюция к этому метастабильному состоянию, была примерно такой:
    • 1996: CVS
    • 2001-2002: Bugzilla
    • 2003: MediaWiki

    но при этом мы таки немного комплексовали, перед «профессионалами» с крутыми системами «поддержки полного жизненного цикла разработки», и только в 2007 году, мы вылезли с этой темой на конференцию, где внезапно обнаружили, что мы не одиноки, и почти также живут все, включая (!) самих разработчиков этих самых «крутых систем»

  2. Например, мы пытались понять, почему непопулярны testmanagement-системы
  3. Мы случайно сохранили типичную презентацию такого подхода, который пыталась реализовать очень сильная команда разработчиков. 256px|right Мы предлагаем взглянуть на слегка обфускированную версию, где мы, чтобы не бросить тень на уважаемую нами компанию, убрали упоминания названия этой компании, а также брендов и торговых марок.

Файл:Subversion logo.png

На данный момент вершина эволюции CVCS :)

Файл:March-hare-2.jpg

Ещё жив CVS(nt)

* А зря nt

ViewVC

ViewVC[1].

Кстати, в это трудно поверить, но надо признаться, что у нас в компании до сих пор есть проекты использующие CVS. А бешеный заяц на слайде выше - это Мартовский заяц из Диснеевской Алисы в Стране чудес, иллюстрирующий CVSnt, очень сомнительного качества доработанный CVS, произведённый на свет компанией March Hare Software.

Использование CVS обусловлено накопленным legacy-опытом (специальные утилиты deploy и testing, завязанные на CVS), плюс legacy-технологии таковы, что переход на SVN или DVCS почти ничего не дает (ветвится вокруг неизменной терабайтной базы бессмысленно, переименования серверных пакетов чрезвычайно редки и т.п.). В общем, CVS у нас работает, как до сих пор работают паровозы в Китае, и мы рассчитываем, что он отомрет естественно, вместе со сменой legacy-технологий.

ViewVC ⌘⌘

right ViewVC → web-интерфейс к CVS & SVN

  • Его можно считать частью VCS.
    • У git и hg веб-интерфейс вообще в стоке.
  • Тоже чуть докручен Hackwrench.jpg

Трекер и вики

Трекер: Bugzilla*

* при всех недостатках. Самый большой →→→

→ Сложность расширения!

(… кривость объектного движка)
  1. Более подробно о нем можно почитать или посмотреть наше выступление на конференции.

Epic Win’ы MediaWiki ⌘⌘

Альтернативы

Далее мы рассмотрим некоторые альтернативы своему выбору - может быть, не до конца оптимальному, но выросшему эволюционно и используемому успешно.

VCS

VCS*

Централизованные и распределённые

CVS, SVNGit, Mercurial, Bazaar (, Monotone, Darcs)


* известно почти всем

Что такое 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 %.

Caution.svg Bazaar, правда, потерял полпроцента (а я говорил! И не только я).

Так или иначе, производимые артефакты хранятся в системе контроля версий, этим уже никого не удивишь, запомним это.

Статистика ⌘⌘

Файл:Habrastat_VCS_2010-10-26.svg

DVCS в моде ⌘⌘

За год:

  • Git, Hg5.5 %, 3 %
  • SVN, CVS 3 %, 5 %
  • Bazaar0.5 % (hate and hate)

Недостатки DVCS — текст

Но есть у них и недостатки

  • Размер репозитория растёт:
    Собрать Android recovery ⇒ качаем >4.8 Гб :(
  • 80 % и 20 % разработчиков:
    Синдром кодовой бомбы
  • Несколько проектов в репозитории
  • Мы тоже внесли некоторый вклад в «пропаганду VCS», сериями статей и переводов, а также выступлениями на конференциях
  • Есть у DVCS и некоторые недостатки: например, то, что размер репозитория со временем сильно растёт, не очень удобно. Хороший пример — это исходники Андроида, хранящиеся в Git. Чтобы попытаться собрать хотя бы recovery (образ «консоли восстановления» для телефона), нужно выкачать 4.8 Гб исходников! Также, говорят, бывает, что разработчики начинают много коммитить локально, а потом «сбрасывают кодовые бомбы» на остальных. Как к этому относиться — личное дело каждого, можно считать, что виноваты всё-таки разработчики, а не DVCS (те самые «80 %» разработчиков — наверное, быдлокодеров). Также менеджеры негодуэ, потому что невозможен контроль доступа к частям репозитория. Но если это жмёт, нужно просто разбить репозитории на несколько и немного упростить выдачу прав. Ну, а «корпоративный народ» может отнестись к этим системам, пришедшим из мира Opensource, не очень хорошо. В общем и целом, все недостатки решаемые.

    Bug Tracker

    Учёт задач

    Файл:Habrastat_tasks.svg

    Статистика с хабра, сильно неточная, но даёт повод для размышлений

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

    Казалось бы, и баг-трекером уже никого не удивишь, но оказывается, и это не так. Часто для разных задач используется всё что угодно, но только не баг-трекер. Причиной для этого может являться чрезмерная «специфичность» используемой системы, когда менеджерским взглядом в неё вкручены диаграммы Ганта и прочие радости (один из разработчиков Luxproject’а использует для разных задач всё что угодно, только не Luxproject[1]).


    Bug Tracker ⌘⌘

    • «Bug» != «Ошибка» ! ! !
    • «Bug» = ∀ (любая) задача:
      • Ошибка, запрос фичи, вопрос поддержке

    Хотя различать любят:

    …I define a bug as behavior in a «Done» story that violates valid expectations…
    Примеры
    1. Пруфлинк, см. lib:KISS or my own time-management best practice (Антон Зотин, Stratoplan World, 2011-05-17), начиная с 23:00. См. также lib:Time Management для программиста (Михаил Гедзберг, ADD-2011), где опять-таки менеджер из LuxSофта пользуется исключительно Outlookом.

    Minimalistic

    GraphvizBugs1.pngGraphvizBugs.pngGraphvizBugs2.png

    (баги в Graphviz)

    Trac *

    Файл:TracBugForm.png

    * Не только Bug Tracker

    Баги на Google Code *

    Файл:GoogleCodeBugForm.png

    * Посимпатичнее, но и возможностей мало

    А так — все похожи, все монстроваты

    Note.svg Как ни странно, даже Minimalistic

    И Jira — хотели переписать багзиллу, а вышло страшнее :)

    Wiki

    Wiki

    • Первая Wiki — 1995 («WikiWikiWeb»).
    • В честь автобусов «Wiki Wiki Shuttle» в аэропорту Гонолулу, вместо «Quick Web»
    • Принципы Wiki:
      • ☺ Быстрая правка
      • ☺ Plaintext разметка
      • ☺ Версионность

    Сейчас на дворе уже третье тысячелетие, через пару лет, то ли конец света будет, то ли Великая Сингулярность, то ли нефть кончится, и рассказывать что такое вики-системы и чем они хороши, вроде как страшный баян. И все же, если вдруг будет время, то у нас (опять-таки!), есть статья и выступление на конференции по этой теме[1].

    Вики-движки ⌘⌘

    http://wikimatrix.org/ - вики-движков > 130!

    Популярные:

    MediaWiki
    MediaWiki-notext.svgTemplate:Localimage:MediaWiki-notext.svg" width="64" />
    (Wikipedia)
    MoinMoin
    Moinmoin.svgTemplate:Localimage:Moinmoin.svg" width="64" />
    DokuWiki
    Dokuwiki-128.pngTemplate:Localimage:Dokuwiki-128.png" width="64" />

    Win / Fail ⌘⌘

    Win: гипертекств абсолюте !

    Fail: плохо с атрибутикой

    • Однако, гипертекст rules, если есть поиск*
    • Есть Semantic MediaWiki

    * Goo… Guess who?

    Wikipedia

    Файл:RupediaMain.png
    1. См. lib:MediaWiki — Серебряная пуля или швейцарский нож? — почему вики-системы стали так популярны, и чем хороша именно MediaWiki.

    MoinMoin

    DebianWikiMain.png

    DokuWiki

    DokuwikiMain.png

    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, и поэтому в будущем не умрут, как это обычно случается с «велосипедами», а останутся рабочими и доступными для сообщества.

    4intra.net ⌘⌘

    Opensource с декабря 2010

    Медиавозможности ⌘⌘

    Wiki-плюшки ⌘⌘

    • Презентации
    • Блоги/форумы*
    • Календарь
    • Опросы, экзамены
    • ВикиЗакладки
    • Развесистые права
    • Импорт/экспорт
    • ...

    * что почти одно и то же

    Презентации S5*

    HTML+JS, порождаемый из Plaintext

    * такую вы смотрите сейчас
    1. Тут мы очень рекомендуем вам взглянуть на наши доклады lib:Knowledge Management: От Склада к Потоку (Software People-2010), lib:Все блюда для интранета из MediaWiki: ВикиБлоги, ВикиПрезентации, ВикиЭкзамены и ВикиЗакладки (Виталий Филиппов на ADD-2010) и статью lib:Оранжерея знаний с MediaWiki.
    2. Рекомендуем взглянуть на lib:Свободные системы, спасающие разработчиков (РИТ-2010)
    3. См. lib:PHP-разгон: серебряная пуля из автомата Комменца-Вальтера (Commentz-Walter)
    4. "Счастье всем, даром, и пусть никто не уйдет обиженным!" ©

    Блоги/форумы*

    * Разница лишь в способе отображения

    Календарь

    Резервирование переговорки и т.п…

    Файл:WikiCalendar.png

    IntraACL (Сильно развесистые права)

    Файл:IntraACL rights targets.svg

    Файл:IntraACL inherit.svg

    Примеры фич Bugzilla4Intranet:

    * При в целом том же внешнем виде

    Excel-импорт/экспорт

    BugsXLSImport.png

    Массовая загрузка вложений

    BugzillaAddMultiple.png

    «Excuse-me» (ошибка с котёнком)

    KittenErrorNew.jpg

    Email-управление, поиск с морфологией, HTML-почта, улучшения Custom полей

    И так далее

    Куда двигаться дальше? ⌘⌘

    • Правильная Bugzilla
      • ??? а стоит ли?
    • Тесты, code review → Wiki
    • Semantic Wiki

    Правильная Bugzilla ⌘⌘

    • С одной стороны, Bugzilla отстаёт от bleeding-edge
      • Usability + Refactoring
    • Зато пока остальные делают Bicycle.gifBicycle.gifBicycle.gifBicycle.gif, она сохраняет HTML-простоту
    • А потом нагонит на стандартах

    LOR, Debian vs Ubuntu ⌘⌘

    > этих хомячков в сотни раз больше и именно на них ориентируюся производители ОС

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

    Ну будет Debian делать всё, как убунта, получится две убунты и ни одного дебиана, и, как следствие, ни одной убунты.

    Не учите отцов, как им делать. Особенно, если вообще ничего не понимаете и ничего не решаете, а просто плывёте в потоке, ведь это единственные, кто думают о вашем завтра, чтобы не оказалось, что завтра вы уже не контролируете ровным счётом ничего.

    Usability ⌘⌘

    Rugby_scrum.jpg
    • JS grid
    • «Форум-функционал»
    • Agile
      • (вкрутить разумный минимум)

    Refactoring ⌘⌘

    • Переделать систему прав*
      • * кто-то понимает MANDATORY/SHOWN/DEFAULT/NA ?
    • Pistol-icon.png убить YAHOO UI → jQuery
    • Pistol-icon.png копипасту → прокачать объектный движок
    • Pistol-icon.png CGI.pm (детище 90-х…)
    • Pistol-icon.png Template Toolkit
      • или хотя бы Pistol-icon.png обратную связь из шаблонов

    Semantic Wiki ⌘⌘

    • «Семантическая Wiki»,
    • Она же Wiki с атрибутикой - http://semantic-mediawiki.org/
    • Semantic Tracker
      • В пень Custom Fields!

    Примечания



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


    Статья отреплицирована из внутренней базы знаний компании.