Jak uzasadnić czas refaktoryzacji kodu?

Mają bardzo duży projekt o wartości ponad 70 000 LOC.

Projekt zdecydowanie potrzebuje trochę refaktoryzacji kodu w Core Framework, a także w innych częściach. Na początku projektu nie było czasu na refaktoryzację. Z czasem jednak ponad 40 programistów dołączyło i opuściło projekt. Z mojej perspektywy jest niezbędny.

Jakie byłyby twoje kluczowe punkty w argumentowaniu i obronie właściwej zasady tworzenia oprogramowania?

Podczas pracy nad starszymi aplikacjami lub terenami poprzemysłowymi kuszące jest wykonanie „wiosennego czyszczenia” z nadzieją na przywrócenie całości kształtu do formy. Nie jest to w żaden sposób uzasadnione wykorzystanie zasobów. W końcu, w jaki sposób powstrzymanie rozwoju działającego oprogramowania (tylko działający kod może być refaktoryzowany) może być uzasadnione? Czy możesz zagwarantować, że czas poświęcony na fazę Big Refactoring zwróci się później i nie spowoduje degeneracji projektu?

Jak jesz słonia? Jeden kęs na raz. Za każdym razem, gdy trzeba wdrożyć nową funkcję lub naprawić błąd, widać, czy ta część wymaga aktualizacji. Tak jak mówi zasada harcerstwa: „Zawsze zostawiaj obozowisko czystsze, niż je znalazłeś”. Refaktoryzacja nie powinna być oddzielną fazą, jest częścią codziennego rozwoju.

Gdy ta kultura jakości zostanie wprowadzona do zespołu programistów, jakość poprawi się. Po tym nie ma już żadnego uzasadnienia dla zarządzania.

Zasadniczo należy dokonać refaktoryzacji, aby umożliwić kolejną zmianę, którą należy wprowadzić w kodzie lub jako naturalny krok czyszczenia po wprowadzeniu zmiany w kodzie. W takim przypadku nie ma nic uzasadnionego. Refaktoryzacja jest po prostu częścią procesu pracy nad projektem. Czas jest naliczany do zadania, nad którym pracowałeś podczas refaktoryzacji.

Jeśli nie robi się tego małymi krokami, to tak naprawdę nie jest to refaktoryzacja, co?

Tutaj wszystkie dobre odpowiedzi - ale mogę dodać do tego wymiar biznesowy. Pozwól, że zapytam DLACZEGO / Dlaczego? (pomyśl o swoim spiczastym szefie włosów (PHB) :)

PHB: dlaczego?
Ty: Ułatwi to naprawę
PHB: Co z tego?
Ty: Zwiększy to przepustowość - szybciej wydostaniemy nowe wersje?
PHB: Co z tego?
Ty: Err ... szczęśliwsi klienci?
PHB: WTF?
Ty: Mam na myśli większe rekomendacje, większą satysfakcję, 
     więcej zysku wcześniej ze względu na niskie obroty
PHB: Och! Brzmi nieźle. Ale to ładnie „brzmi”, czy mogę to zobaczyć?
Ty: WTF?
PHB: Pokaż mi pieniądze! (tzn. proszę o liczby)
Ty: Och! Br ...

Zasadniczo musisz zrobić uzasadnienie biznesowe - uruchomić kilka liczb, aby wyjaśnić swój proces myślowy i uzyskać liczby odzwierciedlające „korzyść” w obiektywny sposób. Dowiesz się też, ile czasu to zajmie, przybliżone koszty itp. To powinno mieć sens. Jeśli warto, dostaniesz zielony sygnał i być może przewodzisz inicjatywie :)

Jeśli myślisz, jak mogę wszystko zmierzyć, wypróbuj tę książkę

Refaktoryzacja, jak każda inna działalność, musi mieć jasno określony cel. Po osiągnięciu tego celu należy rozważyć bieżący status projektu i etap cyklu życia. W przypadku projektu deweloperskiego ukończonego w 80% i 30% w stosunku do harmonogramu należy uzasadnić wysiłek refaktoryzacji na podstawie wcześniej ustalonego celu. W tym przykładzie, jeśli fragmenty kodu zostały przetestowane jednostkowo i działają dobrze w środowisku programistycznym, trudno jest uzasadnić refaktoryzację.

Fakt, że odeszło 40 programistów, może nie być tak dramatyczny, jak się wydaje. Spodziewam się, że ci programiści dostarczyli działający kod, który został sprawdzony i przetestowany. Tak więc, o ile nie są znane problemy w tym kodzie, pozostawiłbym go takim, jaki jest. Chodzi o to, że w dużym projekcie, takim jak twój, oczekiwałbym, że istniały standardy i procedury oraz że kod nie jest kompletnym bałaganem.

Pamiętaj, że refaktoryzacja spowoduje powtórzenie wielu, jeśli nie wszystkich testów. Ponadto, ponieważ refaktoryzacja tego rozmiaru nie może być wykonana przez jednego lub dwóch starszych członków, refaktoryzacja może wprowadzić problemy, które nie istniały. Jest to ryzyko, którego nie należy lekceważyć.

Powiedziawszy to, nie jest niczym niezwykłym dodawanie zadań do projektu, gdy dzieje się nieprzewidziane. Tak więc, jeśli programiści zniknęli z jakiegoś powodu, byłoby to uważane za wydarzenie o szczególnym charakterze i należy podjąć wszelkie działania w celu zaradzenia tej sytuacji. Byłoby to traktowane jak pożar lub trzęsienie ziemi itp.

Podsumowując, nie przefakturowałbym dużego działającego kodu w dużym projekcie bez dobrego, solidnego powodu technicznego, zwłaszcza że wszyscy wiemy, że większość projektów jest zwykle w późnym stanie.

Wyobraź sobie, że stoisz przed długą i ogromną ścianą. Musisz przejść na drugą stronę.

Albo przebudujesz ścianę, aby zbudować drzwi, albo obejdziesz je.

Oszacuj czas dla obu rozwiązań, a otrzymasz uzasadnienie dla refaktoryzacji.

Nie zapomnij pomnożyć czasu w drugim rozwiązaniu przez liczbę osób, które muszą przejść na drugą stronę ściany.

Jak czytam w jednej z pozostałych odpowiedzi, zjadaj słonia jeden kęs na raz. Jestem zaangażowany w kontrolę dużego międzynarodowego projektu, w którym członkowie zespołu są rozproszeni geograficznie. Po zbudowaniu pierwszych dwóch wersji oprogramowania zespół zgodził się, że ich podejście, styl kodowania i rozwiązania konstrukcyjne są niespójne. Zgodzili się napisać nowe części aplikacji zgodnie z nowymi zasadami i konwencją, a kiedy (i tylko wtedy) będą musieli zmienić część starego kodu, najpierw dokonują go refaktoryzacji, aby spełnić nową konwencję. Wszystko działa całkiem dobrze. Proces refaktoryzacji trwa już prawie piąty miesiąc, część kodu jest refaktoryzowana, a niektóre nadal nie. Nowe funkcje zostały wprowadzone na czas, klienci są zadowoleni, deweloperzy są zadowoleni, zespół QA jest również zadowolony. Sytuacja wygrana-wygrana :)

Głównym celem refaktoryzacji jest ułatwienie w przyszłości. Nie można wykazać zysków z refaktoryzacji, jeśli nie porówna się wielu długoterminowych projektów, z których niewiele wykonano, a kilka bez stałego refaktoryzacji. Powszechnie przyjmuje się, że refaktoryzacja obniża koszty utrzymania i wdrażania zmian, ale trudno je udowodnić z biznesowego punktu widzenia. Kluczowym powodem wdrożenia refaktoryzacji jest zmniejszenie zadłużenia technicznego .

Ponadto refaktoryzacja powinna być procesem ciągłym, a czas poświęcony na refaktoryzację powinien zostać uwzględniony w samym zadaniu programistycznym. Posiadanie specjalnego „zadania refaktoryzacji” nie jest dobrym pomysłem.