Сьогодні у мого колеги і у мене дискусія на тему "Чи варто розміщувати специфікаційні документи в системі контролю джерел, наприклад SVN?". На мою думку, так і повинно бути. Все, що стосується розробки проекту, слід ретельно контролювати з системою управління джерелами. Це неправильна концепція в процесі розробки програмного забезпечення?
Відповіді:
То що робити, якщо більшість систем управління джерелами зберігають їх лише як краплі? Більшість людей не дають зрозуміти про відмінності між документами, але якщо у вас є, ви завжди можете отримати дві версії та скористатися функцією системи створення, щоб їх відрізняти.
Оскільки на жорсткому диску розміщено копійок за гігабайт на місяць, немає вагомих причин не ставити документи в систему управління джерелами, і це, ймовірно, стане в нагоді. Мої особисті переваги - писати документи, використовуючи вбудовану розмітку, наприклад, розмітку Wiki або DocBook . Це дозволяє використовувати потужні інструменти для порівняння та перегляду документів.
Документація щодо специфікації версій - це, безумовно, гідна мета.
Однак, чи є ваші специфікаційні документи лише текстовими та у простому текстовому файлі ? Якщо це так, це може бути хорошим рішенням.
Якщо ні, то керування джерелами, ймовірно, не є правильним місцем для них - керування джерелом погано впливає на бінарні файли .
Зазвичай прості текстові файли не є настільки хорошими ні для форматування, ні для швидкого перегляду, тому вікі з версіями, мабуть, краща ідея.
Усі документи повинні бути в якомусь вигляді архіву (бажано, з контролем редагування).
Системи управління джерелами - це одне рішення. Але зазвичай ці системи розроблені для звичайних текстових документів. Таким чином, такі речі, як Word або RTF документи тощо, не так добре підходять (особливо, коли ви намагаєтеся порівнювати різні версії).
Але є й інші рішення, спеціально розроблені для документів. SharePoint спадає на думку, але я впевнений, що є й інші.
Безумовно. Проблема в тому, що документи зберігаються як бінарні файли (наприклад, текстові документи), дратує. Приємним рішенням є те, що якщо ви використовуєте один із інструментів «Черепаха» (я спробував SVN та Mercurial), ви можете вибрати «Visual Diff», який дозволяє вибрати docdiff. За допомогою docdiff ви можете побачити всі зміни кольорів та речей :-). Основним недоліком є те, що кожного разу, коли ви вносите зміни, весь документ знову вводять у дію (а не лише зміни). Але зважаючи на те, що текстові документи зазвичай не величезні, і це місце, ймовірно, не є вашою основною проблемою, це не проблема.
Я впевнений, що ви можете використовувати docdiff без черепахи, я просто не намагався.
Існує альтернативний підхід, який ви повинні обговорити: BDD
Будь ласка, врахуйте розробку, спричинену поведінкою, із виконаними характеристиками. Ваші технічні характеристики спрощуються в ряд заданих - коли - потім наборів операторів, які зберігаються у текстових файлах. Інструмент BDD, такий як Cucumber або SpecFlow, перетворює ці текстові файли у виконувані тести, які може виконувати ваш інструмент збирання.
Огірок: http://cukes.info/ - BDD для Ruby
SpecFlow: http://www.specflow.org/ - BDD для .Net
Для швидкої демонстрації робочого процесу з таким інструментом, як SpecFlow, перевірте проробку SpecFlow Rob Conery: http://tekpub.com/view/concepts/5
Тепер ви не тільки оновлюєте свій код, але і свої технічні характеристики, і ваш інструмент постійної інтеграції (думаю, TeamCity, CruiseControl, Хадсон тощо) домагається того, щоб усі технічні характеристики все ще були дійсні для КОЖНОГО складання ... Це для вас цінне?