Чи справді вікі доцільно зберігати документи для розробки програмного забезпечення? [зачинено]


18

Всім відомо, що добре задокументована розробка програмного забезпечення веде до успіху. Однак зазвичай це означає, що в документі буде задіяний не лише звичайний текст, а й двійковий вміст, наприклад діаграма UML. І я чув, як багато людей це говорять. Система управління версіями не є відповідним місцем для бінарних файлів. Я цілком розумію і погоджуюся з цим питанням. Я запитав декількох досвідчених розробників, де найкраще місце для зберігання документів, і я отримав відповідь «вікі». Wiki хороший, але я розглядав ще одне потенційне питання. Як вихідний код, який зберігається в системі управління версіями, може з'єднуватися з відповідним документом у вікі? Скажімо, хтось клонує сховище git або mercurial. Як він / вона може легко знайти документ? Або я просто щось пропустив?

Я знаю, що деякі системи wiki мають можливість інтегруватися з системами управління джерелами. Але моя стурбованість не полягає у здатності інтеграції. Якщо ви клонували вихідний код із сховища git і через деякий час ви сідаєте в поїзд і хочете продовжувати працювати в режимі офлайн у поїзді (що є великою особливістю DVCS). Тоді ви раптом зрозумієте, що у вас немає доступу до документа, оскільки ви працюєте в автономному режимі в поїзді. З іншого боку, якби документ зберігався у сховищі git, ви мали б доступ до документа із клонованим сховищем.


3
FYI: Wiki не є абревіатурою, це гавайське слово, що означає "швидкий".
Йорг W Міттаг

Той факт, що документація включає в себе двійкові файли, насправді не є вагомою причиною уникати її зберігання у вашій системі контролю версій. VCS можуть легко працювати з двійковими файлами. І якщо ви зберігаєте його у VCS вашого проекту, ви маєте перевагу в тому, що зможете розгалужувати свою документацію, коли ви розгалужуєте проект.
JW01

Що стосується роботи в режимі офлайн: Рішення грубої сили полягає в тому, щоб просто завантажити сторінки, які ви хочете, використовуючи деякі офлайн-читалки. Більш елегантним є те, щоб якось клонувати весь вікі, якщо це практично (наприклад, скопіюйте базову базу даних та власну установку вікі). Вікі на основі VCS - ще більш елегантне рішення. Я часто працюю в режимі офлайн, і зазвичай достатньо просто завантажувати потрібні мені сторінки.
sleske

Відповіді:


16

Чи дійсно WIKI підходить для зберігання документів для розробки програмного забезпечення?

Замість того, щоб писати документи, pdfs та інші види файлів, чому б вам не розкрити весь потенціал WIKI як інструмент співпраці? Ви можете там написати свої документи, приєднати діаграми і ще краще: якщо ви використовуєте Fitnesse , ви можете перетворити свої вікі-сторінки в дійсно корисну і живу документацію, оскільки вони можуть стати виконуваною специфікацією.

Всім відомо, що добре задокументована розробка програмного забезпечення веде до успіху

Слідкуйте за цим. Документи НЕ приведуть до успіху, оскільки вони не перетворять лайний код у хороший. Але документи є частиною шляху до успішного програмного забезпечення. Але лише частина, і вони не зможуть замінити добрі практики та хороших людей.


8

Оскільки багато відповідей вказують на Trac як пропозицію, я хотів би запропонувати подібну, але, на мій погляд, альтернативну альтернативу: Redmine .

Redmine - це рішення для управління проектами, включаючи Wiki, сховище документів та інтеграцію контролю версій. Це також написано в Ruby on Rails, і, на мій досвід, простіше розширити і зламати, ніж Trac.

Більше всього це дуже просто у використанні, і легко отримати команду, яка ним користується.

Особливості:

  • Підтримка декількох проектів
  • Гнучкий контроль доступу на основі ролі
  • Гнучка система відстеження випусків
  • Діаграма та календар Ганта
  • Управління новинами, документами та файлами
  • Стрічки та сповіщення електронною поштою
  • За вікі проекту
  • На форумах проектів
  • Відстеження часу
  • Спеціальні поля для питань, часових записів, проектів та користувачів
  • Інтеграція SCM (SVN, CVS, Git, Mercurial, Bazaar та Darcs)
  • Створення проблеми електронною поштою
  • Підтримка декількох LDAP аутентифікації
  • Підтримка самореєстрації користувача
  • Багатомовна підтримка
  • Підтримка декількох баз даних

Для ваших потреб в режимі офлайн мені не подобається ідея захаращувати контроль версій документами дизайну. Я впевнений, що у вас є свої причини запитати це, але дійсно, як часто ви перебуваєте в режимі офлайн і вам потрібен доступ до проектних документів? Швидше за все, це справді кутовий випадок.


+1 Я використовую Redmine на роботі, і це дійсно чудова система.
Луїз Дамім

5

Деякі вікі (наприклад, Ikiwiki ) мають можливість зберігати свої дані в Git, як ви вже згадували. Враховуючи це, ви можете зв'язати документацію як підмодуль Git у вашому звичайному сховищі джерел.

З наведеними вище налаштуваннями витягнення джерела та оновлення підмодулів дозволить отримати останню копію документації. Офлайн, ви можете редагувати кожного за бажанням. Повернувшись до мережі, обидва можуть бути відтіснені назад до будь-якого спільного місця, яке ви використовуєте.

Незручна частина цього полягає в тому, що щоразу, коли документація оновлюється (навіть через веб-інтерфейс Ikiwiki), вам також потрібно буде оновити відповідний підмодуль у сховищі джерел Git. Однак це можна було легко автоматизувати.


Цікаво. Чи є різниця між тим, як помістити документ у сховище git та зберігати документ через ikiwiki?
Едісон Чуанг

1
@Edison Chuang: Ні, немає. Насправді, даючи клон сховища ikiwiki, ви можете редагувати сторінки за допомогою редактора тексту за власним вибором (вам не потрібно використовувати байдуже поле для введення тексту на основі браузера). Ви навіть можете мати різні гілки вікі для зберігання знімків старої документації чи будь-чого іншого.
Грег Хьюгілл

Це здається, що документ можна зберігати в системі контролю версій без жодних проблем, навіть незважаючи на те, що двійкові файли. Розробник може просто використовувати такі інструменти, як ikiwiki, щоб конвертувати сторінки вікі на HTML-сторінки за потребою.
Едісон Чуанг

+1 для вікі-двигуна Ikiwiki; вики - движок Хатта аналогічна ідея для Mercurial сховищ.
Девід Кері

ISTR Fitnesse також зберігає свої вікі-сторінки як текстові файли, тому їх також можна зберігати у вашій системі управління версіями. Хоча його основні цілі - тестування, немає причин не використовувати його як систему вікі загального призначення для вашої документації.
Жюль

4

Має сенс зберігати документацію в тому ж сховищі, що і вихідний код. Сфінкс мені здається хорошим варіантом.


2

Trac пропонує інтерфейс Subversion, інтегровану Wiki та зручні засоби звітування. http://trac.edgewall.org/
Але я не знаю про ваш встановлений стек.


І приємний інтерфейс до Mercurial. І це виразно руйнується.
Френк Ширар

0

Я б не намагався відповідати роботі в автономному режимі. Я би використовував той ресурс, з яким найпростіше працювати з усіма. Наприклад, якщо ви пишете код PHP, я б запропонував використовувати вбудовану документацію, яку можна згенерувати PHPDocumentor . Його можна генерувати будь-де і є плагін для Trac . Тоді в режимі он-лайн або вимкнення, у вас є доступ до документації, досить швидко теж.

Головне - у юзабіліті. Якщо її важко підтримувати, вона почне страждати. Коли вона починає страждати, якість документації знижується. Коли це відбувається, люди починають скаржитися і тоді все йде вниз.


-1

Використання вікі для зберігання документації має для мене багато сенсу.

Вірогідність - приклад DVCS, який дозволяє більш тісно інтегрувати вміст wiki та вихідний код.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.