Zachowanie historii zatwierdzeń kontroli wersji a refaktoryzacja i dokumentacja

Korzystanie z historii zatwierdzeń obsługiwanej przez system kontroli wersji kosztuje prawie nic. Jednak podczas dużego projektu refaktoryzacji (lub reorganizacji / czyszczenia) zostaną przeniesione funkcje i klasy, a nawet przestrzenie nazw; czasami kilka plików zostanie połączonych ze sobą, a inne pliki zostaną podzielone. Zmiany te często prowadzą do utraty oryginalnej historii zatwierdzeń kilku plików.

Moim osobistym zdaniem utrzymanie organizacji projektu jest ważniejsze niż przechowywanie historii kodu źródłowego. Dobra organizacja projektu pozwala na ciągłe dodawanie nowych funkcji przy rozsądnym wysiłku, a wartość historii kodu źródłowego wydaje się wątpliwa.

Ponadto przy użyciu testów jednostkowych problemy z regresją są szybko identyfikowane. Tak długo, jak najnowsza wersja nadal spełnia wszystkie wymagania dotyczące oprogramowania, czy faktycznie musimy zachować historię kodu źródłowego?

Rozumiem, że każdy dostarczony kod źródłowy musi zostać zachowany z powodu potrzeby zapewnienia wsparcia klientom bez konieczności przeprowadzania aktualizacji głównej wersji. Ale poza tym, czy jest jakaś wartość w utrzymywaniu historii zatwierdzeń kodu źródłowego?

Czy historia zatwierdzania kodu źródłowego odgrywa jakąkolwiek rolę w komunikacji między członkami zespołu? Co się stanie, jeśli zniesiemy historię zatwierdzeń, ale zamiast tego polegamy na „kodzie źródłowym” + „jednostkowym kodzie testowym” do komunikacji?

Czy istnienie historii zatwierdzeń powoduje, że ktoś popada w długofalową dokumentację ważnych informacji o projekcie, takich jak główne zmiany w projekcie / wymaganiach i strumienie myśli, które doprowadziły do ​​tych zmian?

Aby użyć historii zatwierdzania do komentarzy typu „więcej niż dokonane zmiany” lub „naprawiony błąd”, należy połączyć ją z systemem śledzenia problemów. Z każdą zmianą, każdym zatwierdzeniem powinien być związany jakiś problem, abyś wiedział, co się zmieniło, przez kogo i dlaczego.

Tak długo, jak najnowsza wersja nadal spełnia wszystkie wymagania dotyczące oprogramowania, czy faktycznie musimy zachować historię kodu źródłowego?

Wystarczająco złożone oprogramowanie rzadko ma zaimplementowane wszystkie wymagania i wszystkie błędy naprawione z wielu powodów, więc myślę, że twoje twierdzenie jest, powiedzmy, optymistyczne.

Załóżmy, że korzystasz z wersji 7.8 swojego programu. Ale wspierasz w terenie 12 różnych aktywnych wersji, takich jak 1.6, 2.2, 2.8 i tak dalej. Każda z nich nie będzie aktualizowana do najnowszej wersji z różnych powodów, więc obsługujecie wszystkie poprawki błędów. Klient znajduje błąd w najnowszej wersji 7.8. Naprawiasz to w 7.8. Skąd wiesz, ile innych wydań wymaga naprawy? Bez historii źródeł i śledzenia problemów nie masz.

wartość historii kodu źródłowego wydaje się wątpliwa.

Od kilku lat inżynierowie sięgają po kod źródłowy, szukając odpowiedzi na pytanie, dlaczego tak jest. Czasami sposób, w jaki rzeczy ewoluowały w czasie, jest ważny dla zrozumienia błędu, ale nie jest to coś, o czym zwykle myśli się podczas dokumentowania rzeczy (a nawet niekoniecznie dokumentowalne).

Ponadto mogą istnieć bardzo dobre prawne podstawy do przechowywania historii kodu źródłowego. Większość nurkowań w kodzie źródłowym, które musiałem wykonać (jako inżynier kompilacji / SCM), było na prośbę działu prawnego mojej firmy.

Tak długo, jak najnowsza wersja nadal spełnia wszystkie wymagania dotyczące oprogramowania, czy faktycznie musimy zachować historię kodu źródłowego?

Ale poza tym, czy jest jakaś wartość w utrzymywaniu historii zatwierdzeń kodu źródłowego?

Tak dla obu. Warto wiedzieć, kiedy coś zostało zmienione, przez kogo i dlaczego. Jeśli stracisz historię, wpłynie to na twoją zdolność do tego.

Czy historia zatwierdzania kodu źródłowego odgrywa jakąkolwiek rolę w komunikacji między członkami zespołu? Co się stanie, jeśli zniesiemy historię zatwierdzeń, ale zamiast tego polegamy na „kodzie źródłowym” + „jednostkowym kodzie testowym” do komunikacji?

Tak. Podejście „tylko kod źródłowy” + „test jednostkowy” nie mówi, kto / kiedy / dlaczego.

Czy istnienie historii zatwierdzeń powoduje, że ktoś popada w długofalową dokumentację ważnych informacji o projekcie, takich jak główne zmiany w projekcie / wymaganiach i strumienie myśli, które doprowadziły do ​​tych zmian?

Przypuszczam, że można tak powiedzieć. Ale niewielu programistów kiedykolwiek dokładnie dokumentuje zmiany wymagań / projektu. I na pewno prawie nikt nie rejestruje strumienia myśli, który napędzał początkowy rozwój lub kolejne modyfikacje. Posiadanie historii zatwierdzeń (a zwłaszcza komunikatów w dzienniku zatwierdzeń) oraz odsyłaczy do systemu śledzenia problemów / błędów zapewnia przynajmniej coś, od czego można przejść. A to lepsze niż nic lub zestaw migawek wersji.