Збереження історії фіксування контролю версій проти рефакторингу та документації

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

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

Крім того, із застосуванням одиничного тестування швидко визначаються проблеми регресії. Поки остання версія продовжує задовольняти всі вимоги до програмного забезпечення, чи насправді нам потрібно зберігати історію вихідного коду?

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

Чи грає історія фіксації вихідного коду якусь роль у спілкуванні між членами команди? Що робити, якщо ми скасуємо історію комісій, але замість цього покладаємось на "вихідний код" + "код тестування блоку" для зв'язку?

Чи існування історії комісій змушує когось скаржитися на довгострокове документування важливої ​​інформації про проект, наприклад, про основні зміни дизайну / вимог та потоки думок, які спричинили ці зміни?

Щоб використовувати історію фіксації для коментарів типу «внесених змін» або «виправлених помилок», її слід пов’язати з вашою системою відстеження проблем. Кожна зміна, кожне зобов’язання повинно мати певну проблему, пов’язану з нею, щоб ви знали, що змінилося, ким і чому.

Поки остання версія продовжує задовольняти всі вимоги до програмного забезпечення, чи насправді нам потрібно зберігати історію вихідного коду?

Досить складне програмне забезпечення рідко має всі вимоги, і всі помилки виправлені з безлічі причин, тому я вважаю, що ваше твердження тут, скажімо, оптимістичне.

Припустимо, ви переглядаєте версію 7.8 своєї програми. Але ви підтримуєте 12 різних активних версій, таких як 1.6, 2.2, 2.8 тощо. Кожне з них не буде оновлено до останньої версії з різних причин, тому ви підтримуєте всі виправлення помилок. Клієнт виявляє помилку в останній версії 7.8. Ви виправляєте це в 7.8. Як ви знаєте, скільки інших релізів потрібно виправити? Без історії джерела та відстеження проблем ви не обійдетесь.

значення історії вихідного коду видається сумнівним.

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

Крім того, для збереження історії вихідного коду можуть бути дуже хороші юридичні причини. Більшість дайвінгових дайвінг-кодів, які мені довелося зробити (як інженер-будівельник / SCM), були на прохання юридичного відділу моєї компанії.

Поки остання версія продовжує задовольняти всі вимоги до програмного забезпечення, чи насправді нам потрібно зберігати історію вихідного коду?

Але окрім цього, чи є якесь значення у збереженні історії вчинених кодів?

Так обом. Це може бути корисно знати, коли щось змінилося, ким і чому. Якщо ви втратите свою історію, на вашу здатність це впливатиме.

Чи грає історія фіксації вихідного коду якусь роль у спілкуванні між членами команди? Що робити, якщо ми скасуємо історію комісій, але замість цього покладаємось на "вихідний код" + "код тестування блоку" для зв'язку?

Так. Підхід "вихідний код" + "код тестування одиниці" не підказує, хто / коли / чому.

Чи існування історії комісій змушує когось скаржитися на довгострокове документування важливої ​​інформації про проект, наприклад, про основні зміни дизайну / вимог та потоки думок, які спричинили ці зміни?

Я думаю, ви могли б сказати, що це так. Але мало хто з розробників все-таки ретельно документує зміни вимог / дизайну. І, звичайно, майже ніхто не записує потік думок, який спонукав початкову розробку, або наступні модифікації. Маючи історію фіксації (і особливо повідомлення журналу фіксації) та перехресні посилання на систему відстеження проблем / помилок, принаймні забезпечують вам щось із чого. І це краще, ніж нічого, або набір знімків випуску.