Этот пост я начинала писать еще давно, начала с системы контроля версий и в итоге сделала про них отдельный пост - уж больно много получилось. Сейчас я хочу закончить начатое.
Система контроля версий + багтракинговая система + wiki с документацией - это минимальный набор инструментов, необходимый для эффективной работы над проектом. Эта информация обычно не является ни для кого откровением. Все и так об этом знают. Это те самые "все", которых очень мало и которых можно встретить только по большим праздникам. Потому что если у вас в компании все и так активно пользуются этими инструментами, то у вас вызовут недоумение люди, которые ими пренебрегают. На самом деле проектов, в которых нет вообще даже системы контроля версий - полно. Большие проекты при этом разрабатываются. Отговорок почему не используется что-либо из вышеперечисленного полно.
Целей у этого поста две. Рассказать новичкам зачем все это нужно и переубедить сомневающихся. Ибо отказ от этих полезных инструментов ведет к потере времени и денег.
Системы контроля версий
Про системы контроля версий, как я уже сказала, у меня есть отдельный пост, поэтому кратко. Сейчас в моду входят распределенные системы контроля версий, я чаще всего слышу названия Bazaar, Mercurial, git. На самом деле неважно какую систему контроля версий использовать, главное, чтобы она нравилась разработчикам. Основное правило работы - частые небольшие атомарные коммиты, по одному коммиту на одно логически законченное изменение кода. Не получается так - неприятно, но не критично. Главное, чтобы система контроля версий была в принципе. Отсутствие системы контрля версий приводит к зоопарку бэкапов.
Варианты, которые мне встречались в реальных проектах
MyProject.backup
MyProject.backup.old
MyProject.backup.older
MyProject.backup.oldest
Или
_MyProject.backup
__MyProject.backup
Для Windows разработчиков характерна такая картина
Copy of MyProject
Copy (2) of MyProject
Ну и вот еще вариация на тему
MyProject.oo1
MyProject.oo2
MyProject.oo3
Вспомнить в каком бэкапе какие изменения были сделаны уже никто не может.
Багтракинговая система
Наиболее известные
BugZilla - пожалуй самая популярная. Не очень юзабельный интерфейс, а так ничего
JIRA - тяжелая бюрократическая система
TaCo - не очень известная, но я ей пользовалась, потому решила про нее вспомнить
Вместо багтракинговой системы периодически используются
- Excel или .doc файл (sic!)
- текстовый файлик (sic!)
- мятые бумажки со следами от кружек (sic!)
- и "я запомню" (все рыдают)
Я работала со всеми этими вариантами. Любая багтракинговая система лучше любого из этих вариантов.
Но с багтарком есть один момент. Багтракинговую систему важно использовать правильно. Иногда она начинает использоваться как мерило эффективности труда программистов. К примеру, начинают наказывать за долго открытые баги. Или считают количество закрытых багов в течение, скажем, месяца. После таких начинаний багтрак незамедлительно превращается в веселую профанацию.
Документация в wiki
Я в восторге от wiki и считаю ее лучшим помощником в написании документации. wiki буквально провоцирует программиста писать документацию.
Да, тут речь идет именно о программерской документации, но доки для пользователя там тоже удобно вести.
Частой заменой документации в wiki служат
- отсутствие документации как таковой.
Самый распространенный вариант. Причем есть такое мнение, что по коду все можно восстановить. Нифига. Код отвечает на вопрос "как это работает", но не отвечает на вопрос "почему". Я вижу странное и неочевидное решение в коде. Почему было принятно именно оно? Ошиблись? Спешили? Для этого были неизвестные мне причины? Иногда спасают комментарии. Иногда комментариев нет.
Иногда есть некий программист, который владеет Тайной Кода. Самое веселье начинается, когда он увольняется, уходит в отпуск или заболевает.
- .doc файлы, вообще любые текстовые файлы.
Программистов, в принципе, можно заставить вести там документацию. Но именно заставить, потому что это жутко неудобно. wiki удобна для редактирования несколькими людьми - доки нет. Правка в вики выглядит так: залез - поправил. Поскольку вики старается доку структурировать по мере написания, главы вставлять и т.п., то поиск нужного куска текста не занимает много времени. С доками правка выглядит так - скачать док, открыть, отмотать на нужно место, поправить, залить обратно. В доках нет контроля версий, которые есть в wiki. Только если док в систему контроля версий не залит, но это уже непонятная имитация wiki начинается.
Итог всего этого - доки плодятся, потому что их все ленятся скачивать каждый раз. И все бегают в поисках актуальной версии. Пока не поймут, что актуальной версии на самом деле ни у кого нет.
Мораль: source control + bugtrack + wiki ускоряют работу и искореняют бардак.
Updated 17.02.2008
Ссылки по теме:
Управление знаниями. C чего начать
Trac 0.11 beta
Quaternions and spherical trigonometry
2 дня назад
Atom feed
70 коммент.:
В доках вместо diff-а и контроля версий иногда пытаются вести вручную лог изменений или использовать микрософтоофисные "инструменты совместной работы" - комментарии, правки и иже с ними. Мое мнение - вики-подобные системы для описаний проектов быстрее и удобнее.
Кстати, есть такая штука, как Trac (http://trac.edgewall.org/) — интегрированные wiki, багтрэкер и веб-интерфейс к SVN.
Хороший пост, надо своим показать :)
P.S. Между делом, JIRA фигурирует в Звёздных Войнах: это такие летающие шары, которые рогатый негр Дарт Мол посылал на поиски Квай-Гона и Оби-Вана на Татуине в первой части.
И еще: есть такой багтракер, называется Дихлофос. Простой и удобный.
А Trac - конечно, здорово, что там всё интегрировано, но блин до чего же он не юзабельный...
1. К списку баг-трекеров могу добавить Mantis, мы им пользуемся уже давно, и для 5-8 проектов он вполне удобен.
2. TortoiseSVN умеет показывать diff-ы для OpenOffice'овских ODF, а Word умеет вести учет версий одного документа, что впрочем wiki не заменяет. Но на wiki надо всех еще пересадить, и к сожалению не только программистов, но и гораздо более "трудных" менеджеров.
В Trac напрягает то, что он не понимает разные кодировки файлов в репозитории, из-за чего в юникодной, или наоборот, неюникодной половине исходников комментарии пишутся кракозябрами. Зато в Trac есть плагин для code review.
И в конце так и хочется добавить - А все вместе это Trac.
Лично мне нравится вести документацию в TeX, исходники докумментации можно хранить в том же репозитории, что исходные тексты программы, кроме того TeX позволяет разносить документ на несколько файлов (разбивка на главы/разделы), ну и еще много положительных моментов...
Отрицательный момент вижу только один - TeX, весьма сложная система, ее надо изучать.
Еще TrackStudio посмотрите, на сайте много на тему сравнения с Jira и вообще.
> А Trac - конечно, здорово, что там всё интегрировано, но блин до чего же он не юзабельный...
А что не так с Trac? Как по мне, так все очень удобно, особенно для малых и средних проектов.
Предыдущий комментарий от "blog" должен был быть от "Not a kernel guy". Понятия не имею почему так получается.
А у гугля нет какого-нибудь такого, что можно испоьзовать как Вики?
Возможно, Google Docs, там можно одновременно редактировать один и тот же документ (если память не изменяет, то и версии там есть), однако ИМХО это не будет удобно.
Еще есть wiki на code.google.com, для созданных там проектов. Но я его не смотрел.
попробуйте HP QC. Не реклама :)
/Удивительно/ А почему забыли Mantis для бактрекинга? Очень популярная бесплатная система.
> Я вижу странное и неочевидное решение в коде. Почему было принятно именно оно? Ошиблись? Спешили? Для этого были неизвестные мне причины?
А вот это пять! Например, у нас ведутся доки в wiki, но только для пользователей и клиентов. Никакой програмной документации нет. Но когда я намекаю на это, и именно из-за озвученной вами проблемы, то встречаю только удивление. Типа: а нафига? Ниукого времени нет. А если чё, то подойди и спроси у Васи..
Самое главное и интересное в том, что и Вася через три месяца, уже перключившись на другой проект нихрена-то не помнит!
Алена, есть небольшая просьба - если Вас не затруднит, конечно...
Дело в том, что, как я подозреваю, у нас несколько другой подход к проектированию и разработке, а также написанию и ведению документации. Поэтому удобство использования wiki для нас не очевидно. Мало того, я в принципе плохо представляю кто и как (имеются в виду разработчики) вносят туда записи.
Если появится возможность - напишите, как именно у вас ведется документирование в Wiki, хорошо бы с конкретными примерами.
Больше всего интересуют такие вопросы:
1. Кто и в каких случаях вносит записи в wiki?
2. Какая используется структура статей (даже если особой структуры нет, то все равно есть некие сложившиеся правила)?
3. Кто и как в дальнейшем пользуется этими записями.
Буду крайне признателен за такую статью и буду с нетерпением ждать ее появления.
К сожалению на cvs все забили и путёвого тракера к ней нет :/
Укажите используемые wiki-движки плиз.
Коль примеры wiki-движков вы не привели - посоветую Confluence чисто программерский wiki, продукт от Atlassian - разработчиков JIRA.
... и в догонку
Для тех кому JIRA (и Java в принципе) - не мИлы, как баг-текер ещё стоит глянуть на MySQL Eventum.
В нем же есть и базовая система документации, но он почти не "юзабельна"
Укажите используемые wiki-движки плиз.
mediawiki например
К сожалению на cvs все забили и путёвого тракера к ней нет :/
скрипт cvs2svn еще никто не отменил ;-)
А вообще, иногда коллеги-разработчики бывают настолько консервативны, что никаких нововведений принимать не хотят...
Очень животрепещущая тема, особенно с комментами про "Васю" ))
У нас в офисе положение очень странное. Самые "перспективные" работники, средних лет, не ведут доков в принципе, и комментариев в коде - на 1500 строк - 2-3 (именно 2-3), а те, кто помоложе, стараются.. но их ценность от этого все равно не возрастает :( непонятно, почему :)
я кстати, тоже могу порекомендовать Trac - система расширяемая, из коробки есть все перечисленное в статье, по умолчанию - поддержка Subversion. А другие системы контроля версий добавляются плугинами.
А документацию в вики удобно вести только касающуюся архитектуры системы, оставляя документирование кода на долю Doxygen используя Doxygen Plugin
Зря никто не сказал про doxygen, классная штука если есть привычка писать комментарии документирующие код.. ну там параметры для функций, описания для классов и пр..
CVS-JIRA-Confluence-Bamboo отличная связка для структурирования бардаков )
Господа, не забывайте о планировании и гибкости методологии. Крайне много полезного отсутствует в Trac/JIRA, но может быть найдено в DEVPROM (http://www.devprom.net)
2lexx: я упомянул про doxygen ;-)
я правда в последнее время все чаще задумываюсь про использование literate programming, но это будет скорее всего только в моих личных проектах - в работе такую вещь применить просто не дадут :-(
2RedChrom: а CVS правильно забыли - слишком он старый, и отсутствует много полезного функционала.
Сила Trac в его простоте (minimalistic approach). Trac использует компонентную архитектуру, которая еще и полностью переработана в 0.11 dev ветке. Вики движок по синтаксису аналогичен MoinMoin (w3c использует MoinMoin, и вообще google: powered by MoinMoin, а потом и Google: powered by Trac, это позволит сделать выводы о популярности продукта).
to devprom:
> Господа, не забывайте о планировании и гибкости методологии.
Посмотрите http://trac-hacks.org/wiki/TimingAndEstimationPlugin, и далее по ссылкам дойдите до SCRUM...
Под Trac очень много плагинов и макросов, см. trac-hacks.org.
И кстати, Trac подходит не только для разработчиков, а еще хорош как Project Management Tool общего назначения. Проектный подход, процессный подход, ECM, BPMS - все это темный лес для 90% компаний (а экономика и держится на таких вот компаниях малого и среднего бизнеса), и использование Trac как хранилища файлов с поддержкой версий + инструмент workflow - будет хорошим стартом.
P.S. Кстати, Trac победитель UK Linux & Open Source Awards 2006 в категории the Best Linux/OSS Developer Tool ;-)
Мы пользуемся гугловскими доками/конференциями - на определенном этапе и до определенного кол-ва человек - вполне удобно. И никакх инфраструктурных головняков.
2Алена: я в свое время пользовался еще tutos - система багтрекинга и ведения проектов.
Для меня освноное удобство было в том, что можно было вносить инсталяции продуктов у клиента, включая информацию по оборудованию, версиям софта и контактные данные от клиента. Ну и конечно можно было определять любое кол-во продуктов, и версий этих продуктов.
Ошибки можно было вешать как на весь проект, так и на конкретную версию или инсталяцию.
Плюс к тому же можно было настраивать разные оповещения, вести календарь задач для разработчика, а менеджер проекта может планировать/смотреть временные затраты по проектам, багам и загрузке разработчиков.
Это все замечательно, а кто чем пользуется из Ticket-систем для обслуживание обращений пользователей?
Посоветуйте пжлст, я обыскался, не могу найти достойное решение.
2Андрей Валяев:
Лично мне нравится вести документацию в TeX
А как тогда с совместной правкой одного и того же документа?
2Andrey:
Никакой програмной документации нет. Но когда я намекаю на это, и именно из-за озвученной вами проблемы, то встречаю только удивление. Типа: а нафига? Ниукого времени нет.
Угу, это обычная проблема. Причем, наоборот, такой подход - это разбазаривание времени.
2МихпилР
Алена, есть небольшая просьба - если Вас не затруднит, конечно...
Дело в том, что, как я подозреваю, у нас несколько другой подход к проектированию и разработке, а также написанию и ведению документации. Поэтому удобство использования wiki для нас не очевидно. Мало того, я в принципе плохо представляю кто и как (имеются в виду разработчики) вносят туда записи.
Если появится возможность - напишите, как именно у вас ведется документирование в Wiki, хорошо бы с конкретными примерами.
Я не могу приводить конкретные примеры с моей текущей работы, ибо NDA. Но на самом деле они и не нужны...
Больше всего интересуют такие вопросы:
1. Кто и в каких случаях вносит записи в wiki?
Я работала как с wiki, так и до того как wiki широко распространились - с обычными как-то структурированными веб-страничками. Wiki, конечно, удобнее.
История всегда повторялась. Человек, Которому Больше Всех Надо, начинает где-то вести программерскую документацию, например, поднимает wiki для этого. Рассказывает об этом коллегам, которые тоже начинают ею пользоваться и вносить правки. С какими-либо ограничениями доступа я не работала, потому что той проблемы, что в открытых wiki есть: вандализм и прочее, корпоративные wiki не сталкиваются, секретов внутри компании не было.
2. Какая используется структура статей (даже если особой структуры нет, то все равно есть некие сложившиеся правила)?
Никогда не требовалось никакой утвержденной структуры. Ну разве что разбивка по командам, чтобы особого бардака не было. Разработчики самоорганизовывались, Человек, Которому Больше Всех Надо, за всем приглядывал.
Более того, как только в дело вмешиваются Процедуры, Правила, Регламенты и прочее, народ к написанию документации охладевает.
Ну и документы - не код, их всегда легко перетасовать.
3. Кто и как в дальнейшем пользуется этими записями.
Сами программисты, когда что-то забывают, чего-то не знают.
Самое основное - это значительно уменьшает время вхождения новичков в ход работы. Когда новый человек приходит, не всегда есть время его за руку водить и все показывать. Сажаем его читать wiki, все. И при этом он не отвлекает дорогостоящих разработчиков от работы.
Может быть полезно для code reuse - разработчики будут знать что творится в соседних командах.
Буду крайне признателен за такую статью и буду с нетерпением ждать ее появления.
Я все же не хочу затеваться со статьей, потому что не думаю, что это будет интересно большому количеству народа. Но я без проблем могу пообщаться по e-mail. Адрес есть в профиле, пишите.
2Анонимный:
Укажите используемые wiki-движки плиз.
Я пользовалась dokuwiki, мне понравилось. Эпизодически пользовалась и другими wiki - все они похожи, это больше дело вкуса, какую выбрать.
2Alex Ott:
я правда в последнее время все чаще задумываюсь про использование literate programming
Почитала, я так понимаю это что-то из серии самодокументируемого кода или это он сам и есть.
Все-таки в коде всю информацию не поместишь. Вот есть у меня структура некоторого xml документа, который используется в нескольких проектах компании. Где его описывать? К коду каждого из проектов добавлять?
Плюс к тому же можно было настраивать разные оповещения, вести календарь задач для разработчика, а менеджер проекта может планировать/смотреть временные затраты по проектам, багам и загрузке разработчиков.
Когда я слышу про временные затраты, я всегда напрягаюсь. Если с их оценкой обращаться неаккуратно, то народ отвлекается от разрабоки проекта и начинает подгонять статистику.
Спольски, я помню, когда про FogBugz говорит, все время подчеркивает, что там никакой статистики нет и не будет.
По поводу literate programming - это не писание документации внутри кода, это писание кода внутри документа, его описывающего. После того, как документ готов, одной утилитой из него генерят документацию, а второй утилитой - извлекают код, и компилируют.
По поводу статистики и т.п. - это часто требуется, как бы этого не хотелось :-)
по поводу документации - наверное выход будет в скрещивании нескольких подходов = использовать и wiki и утилиты типа doxygen. В вики вести концептуальную документацию, описание архитектуры системы и т.п., а доксигеновой документацией пользоваться как справочником.
Достаточно часто требуется передача документации внешним людям, поэтому может потребоваться чтобы wiki умел экспортировать в другие форматы, допускающие автоматическую обработку данных.
У меня знакомые из одной томской фирмы, вели концептуальную документацию в docbook, а документация по интерфейсам и т.п. была в doxygen, и xml output от него, они трансформировали в docbook, и автоматически вставляли в результирующий документ. Получалось очень хорошо - после первоначальной настройки, документация генерилась совершенно автоматически
Лично мне нравится вести документацию в TeX
А как тогда с совместной правкой одного и того же документа?
В плане совместной правки - тут у wiki конечно конкурентов нету...
Но с другой стороны удается же в репозитории хранить исходные тексты программ, и совместно работать с ними. Аналогично можно использовать и TeX.
Совместная работа над проектом вовсе не обязательно предполагает совместное редактирование одного предложения.
PS: А докумментацию в исходных текстах не люблю... наверное это все придумали от программистской лени на ведение нормальной документации.
PPS: Да я и сам ленивый тоже :)
2Алёна:
Правильные мысли :)
Могу ко всему приведенному добавить TFS, на который мы перешли из связки DevTrack (багтрекинг) и SourceSafe (контроль версий + хранилище документов).
Благодаря полноте решения (в котором есть и wiki) и продуманной интеграции с VS 2008, никаких дополнительных средств попросту не нужно :) Ну, разве что с Exchange нужно не забыть интегрировать, и кое-где подрихтовать базовые настройки :)
Все тут рекомендуют Trac, но поддерживать одновременно несколько проектов в нем трудно (по крайней мере, так было в версиях до 0.11, которые я несколько раз пытался попробовать)
Недавно в википедии набрел на Redmine
Overview
* Multiple projects support
* Flexible role based access control.
* Flexible issue tracking system
* Gantt chart and calendar
* News, documents & files management
* Feeds & email notifications.
* Per project wiki
* Per project forums
* Simple time tracking functionality
* Custom fields for issues, projects and users
* SCM integration (SVN, CVS, Mercurial, Bazaar and Darcs)
* Multiple LDAP authentication support
* User self-registration support
* Multilanguage support
* Multiple databases support
Активно используем в команде разработчиков и тестеров (~10 человек) уже 4 месяца, пока серьезных проблем не обнаружено.
> Все тут рекомендуют Trac, но поддерживать одновременно несколько проектов в нем трудно
Верно,по умолчанию каждая инстанция Trac'a обслуживает один проект, в чем есть как плюсы, так и минусы. Трудно говорите? Ну все относительно же относительно :-)
Trac исповедует minimalistic approach, и это отпугивает новичков, желающих out-of-the box мега функциональность. Всем не угодить, и твоя функциональность может вообще не нужна мне.
Вот смотрю я демо redmine...
- Activity сильно похоже на слизанный с Trac Timelime, в том же месте, в таком же виде :-)
- Roadmap = Roadmap и также слизан один-в-один.
- Issues = Tickets
- News - ну вот, выделили отдельные документы в отдельный тип. А можно ведь использовать тэги, или NewsFlashMacro, или иерархию. Ведь News это обычный документ с типовым содержанием и назначением.
- Wiki = Wiki :-)
- Forum = плагин TracDiscussion
- Gantt диаграммы - пожалуйста, вот Вам TracGantt плагин.
- Spent Time - пожалуйста, вот Вам
http://trac.edgewall.org/wiki/TimeTracking
Вообще ощущение такое, что продукт inspired by Trac :-) Тут и расположение, и цвета diff, и timeline, и roadmap... Похоже, что любители Ruby поглядели Trac & Mantissa и сделали свой продукт, но на Ruby :-)
Trac несет в себе строгую концепцию, архитектурную философию. Это видно по тому, в каких муках идет идет рождение 0.11. Это инструмент для профессионалов, который расширяется в соотв. с требованиями. Хотя имхо, не мешало бы сделать Trac for newbies, куда запихнуть пару сотен плагинов, все макросы, и написать feature list на 3-х страницах :-).
ИМХО надо как минимум включить в ядро гибкую систему прав и конструктор workflow.
В заключение. Trac - хорошая отрытая расширяемая система, с минимумом базового функционала из коробки (svn, wiki, tickets). Не лучшая - а только хорошая, которая к тому же не каждому подойдет и не каждому "по зубам" :-)
Но попробовать, особенно после выхода 0.11 стоит!
И совсем забыли о таком субъективном факторе, как личные предпочтения. Любители JAVA скорее всего выберут JIRA, Python - Trac, PHP - Mantissa, Ruby - Redmine.
Хоте не так уж это и субъективно, так как компании, в основе IT инфраструктуры которох находится J2EE, наврядли захотят дать даже шанс Redmine или Trac.
"Система контроля версий, багтрак и wiki" в одном экзешнике это http://fossil-scm.hwaci.com. Правда оно пока бета.
Вместо багтракинговой системы периодически используются
- Excel или .doc файл (sic!)
- текстовый файлик (sic!)
а в чём конкретно "sic"? и чем хуже doc с комментариями, какого нибудь mantis?
2Arkadiy:
а в чём конкретно "sic"? и чем хуже doc с комментариями, какого нибудь mantis?
doc, текстовый файл - это фактически имитация багтракинговой системы человеком вручную. Что во-первых, затратно по времени, а во-вторых - человек будет часто ошибаться.
Какие проблемы возникнут по ходу дела:
Несколько копий файла с багами, среди которых сложно будет найти актуальную. Это основная проблема, которая вообще весь процесс ведения багов превращает в полный бардак. Все остальное - это неприятности, которые дальше усугубляют ситуацию.
Поскольку закрытые баги тоже хорошо бы оставлять, файл будет пухнуть. Если закрытые баги оттуда удалять - то при их повторном возникновении их будет сложнее править.
Очень сложно или невозможно пользоваться такими приятными фичами багтаркинговых систем как метки, установка взаимозависимостей между багами, оповещение мылом всех заинтересованных в данном баге.
Сложнее расставить баги по приоритетам.
спасибо, пошол выбирать между the Track и Redmine :)
вынесло меня на этот пост поиском по достаточно неудачному запросу "Trac DevTrack сравнение", он вроде был единственным результатом.
спасибо за пост.
уже некоторое время копаю эту тему.
(из вчерашних находок http://nat.naumen.ru/new/Main/OpenResearch, по запросу "таблица продукт функциональность starteam svn", токо он счас лежит, читал из кэша гугла)
Подумал тут насчет докумментации, что докумментация докумментации рознь конечно.
Релизную докумментацию (или как это лучше сказать), различные мануалы, спецификации лучше всетаки держать не в wiki а в более принтабельном варианте. doc имхо и здесь sic, не знаю как на нем работают бедные наши писатели, TeX - на порядок лучше.
Кроме того в проекте может существовать большое количество окончательной или не очень рабочей докумментаци. Это могут быть не только описания программных модулей, но так же обсуждения взаимодействия, протоколы совещаний, всякие графики и схемы... Для этого wiki подходит как нельзя лучше.
Кстати сказать, релизную докумментацию проекта тоже резонно хранить в системе контроля версий и так же регистрировать в системе багтракинга. Ибо в текстах тоже бывают ошибки!
А все знают, как неудобно хранить в СКВ бинарные файлы, поэтому doc со всех сторон sic! :)
2Андрей Валяев:
Если изучить функции Office так же, как, скажем, функции любимого IDE, подобное мнение становится смешным для самого автора :)
Советую изучить интеграцию Word с SharePoint, а также узнать, как можно генерить (и оперативно обновлять) разделы docx-файла из различных источников данных. В том числе из того же набора статей в Wiki, или из списка багов/требований в TFS. Для сравнения docx-файлов существует много инструментов (которые можно и для merge использовать).
А вот с возможностями верстки (стили, таблицы, указатели) Word надеюсь никто спорить не будет? :)
2артур: возможности верстки ворда не идут ни в какое сравнение с возможностями верстки, которые можно использовать в latex, особенно, если должна происходить автоматическая генерация документов, что часто нужно при подготовке описаний программных интерфейсов.
к тому же, для сравнения и слияния документов необходимо использовать внешние инструменты, которые тоже не идеальны и сильно затрудняют одновременную работу над документом
2Андрей Валяев:
Релизную докумментацию (или как это лучше сказать), различные мануалы, спецификации лучше всетаки держать не в wiki а в более принтабельном варианте. doc имхо и здесь sic, не знаю как на нем работают бедные наши писатели, TeX - на порядок лучше.
Все это не очень удобно, если нужна совместная правка документов. Совместная правка doc'ов - то еще приключение.
Для пользовательской документации, думаю, удобен следующий подход: вести ее в wiki, а потом конвертить в doc или еще куда.
По поводу выбора wiki:
www.wikimatrix.org
Там можно сравнить характеристики практически всех существующих wiki-движков
Дополнение к Система контроля версий, багтрак и wiki (http://galiulin.blogspot.com/)- очень не большая подборка wiki, если интересно
Дополнение к Система контроля версий, багтрак и wiki (http://galiulin.blogspot.com/)- очень не большая подборка wiki, если интересно
Реальный опыт использования всгда интересен... Я только уточню ссылку:
http://galiulin.blogspot.com/2008/03/wiki.html
Озадачился выбором багтрека, но в этом деле пока полный профан.
Набрел на софтину Axosoft OnTime (www.axosoft.com). Внешне очень понравилась, может кто пользовался? Какие впечатления? Из минусов пока обнаружил только отсутствие кряка :).
В качестве bug треккера не плохо прижился Jtrac.
Просто ставится, восстанавливается из резервной копии, минималистичен, крайне мало времени на первоначальное изучение.
Просто локализуется, а это важно, если туда пускать заказчиков.
Рекомендую.
Тема набирает обороты с каждым днем.
Полгода назад эта статья дала еще один толчок для использования в нашей компании MediaWiki.
Большое вам спасибо за это! В своем блоге я уже писала о первых вопросах с привыканием к разметке и кое-каких решениях. По мере накопления опыта буду стараться рассказывать что из этого выходит и далее..
2omega:
Большое вам спасибо за это!
пожалуйста :-)
В своем блоге я уже писала о первых вопросах с привыканием к разметке и кое-каких решениях. По мере накопления опыта буду стараться рассказывать что из этого выходит и далее..
интересно, почитаем
простая вики в файлах, которые хранятся в git: http://atonie.org/2008/02/git-wiki
к этой минимальной вики в файлах, вроде gitwiki (которую удобно редактировать в том же emacs с соотв. расширением, например, muse) хорошо прикручивается такой же минималистичный багтрекинг (в вики), например, gitshelve http://www.newartisans.com/blog_files/git.versioned.data.store.php или hgshelve http://piranha.org.ua/blog/2008/05/19/hgshelve/
А как же DocBook для документации? Исходники хранятся в системе контроля, проблем с совместной работой не возникает...
Отличная статья, спасибо.
Надеюсь, что если таких статей будет больше, то мышление у наших СНГ-шных программистов сдвинется наконец-то к продуктивным технологиям разработки софта.
Этому же нигде не учат, кроме как в крупных компаниях.
Пользуюсь trac + graph + svn-1.5 + revtree + inspection plugin + more plugins + my plugins :)
Я доволен, хочется чтобы в плагине инспекций все таки разницу версий показывали а не приходилось полностью самому все готовить, хотя подвижки уже были сделаны вроде как.
И чтобы в тикетах можно было оставлять заметки, для которых можно было бы позднее поставить метку выполнена и коментарий, но не хочется из одной задачи плодить другую подзадачу, так как ей по моему мнению как бы не является.
Ну раз этот пост превратился в место культурного паломничества, где все исповедуются, какие тулы используют, добавим и нашу строчку.
Вообще, к такому набору (VCS/Wiki/Tracker) мы пришли давно, сначала этого несколько стыдились, потом осознали, что это оптимум.
А набор таков:
CVS (для legacy code) + SVN + ViewVC (раньше был Bonsai) + Bugzilla (с доработками) + Mediawiki (с доработками).
Более подробно по теме делали пару докладов на SECRах.
http://team.custis.ru/2007/11/secr-2007.html
http://team.custis.ru/2008/12/mediawiki.html
Ну и с Новым Годом всех!
Доброго времени суток, блог очень интересный, здорово, что такие девушки есть у нас (=
Из собственной практики - полгода назад у нас начался крупный проект. А про контроль версий и трекинг на фирме никто кроме меня даже не читал.
Сейчас по прошествии времени можно говорить о том, что Трак для нас был лучшим выбором.
Багзилла тяжела и нет вики. Джиру даже смотреть не стал, мантис - без интеграции с контролем версии.
Однозначно трак.
Алёна, а, что Вы используете? или NDA?
2Свердловский:
Доброго времени суток, блог очень интересный, здорово, что такие девушки есть у нас (=
:-)
Алёна, а, что Вы используете?
Контроль версий - SVN
Багтрак - JIRA
Вики - Confluence
Вася:
Привет .
Ребят подскажите вообще есть ли wiki которые интегрируютсья с Devtrak-ом?
Уже пробывал это настроить и в Jira и Redmine но они не связываються с ними.
Так же надо интеграцию с SOURCESAFE. Это уже менее важно...
Может кто подскажит хотябы как плагин написать под это дело? или в какую сторону капать?
Для организации работ по управлению большими проектами разработки ПО мы используем Jira + MS Project + Ceptah Dredge для их синхронизации. Имеем полный набор - и баги, и билды, и Гант, и распределение и планирование ресурсов и календарное планирование...
> Любители JAVA скорее всего выберут JIRA, Python - Trac, PHP - Mantissa, Ruby - Redmine.
Все относительно. Любители Java выбирают redmine не реже JIRA. В опенсорсных проектах дороговато JIRA использовать. Насчет wiki - неплохи mediaWiki и xWiki. Насчет системы контроля версий - git.
мятые бумажки со следами от кружек... может и не функционально, но это добавляет офису домашнего уюта... может, делая записи багзиллу - все же дублировать их на бумажки? )
Отправить комментарий