Oblicz koszty złego kodu

Szukam argumentów, aby przekonać kierownictwo do zainwestowania wysiłku w refaktoryzację.

Rejestrujemy pracę za pomocą Jira i odnosimy każde svn-commit do wywołania Jira.

Moim pomysłem jest wykonanie następujących czynności:

• ręcznie wykryć obszar kodu, który jest wyjątkowo źle zaimplementowany, ale często używany: zarówno z User-POV, jak i Developer-POV (poprawki błędów)
• pobierz svn-commits, które zawierają problemy JIRA
• filtruj problemy według niektórych kryteriów (typ problemu, wersja, priorytet itp.)
• obliczyć czas / wysiłek poświęcony tym błędom
• oszacować wysiłki i ryzyko związane z refaktoryzacją
• przedstaw liczby i poproś o wysiłek, aby to naprawić.

Co o tym sądzisz? Czy taki pomiar byłby użyteczny i / lub przekonujący? Jakie są zalety i wady?

Przekonałem się, że jeśli możesz podać prawidłowe numery, menedżerowie są bardziej skłonni do działania. (Jeśli potrafią zrozumieć logikę i koszt / korzyść).

IMHO, aby przedstawić przekonujący przypadek, potrzebujesz następujących informacji, aby pokazać, jak źle jest:

• liczba zarejestrowanych incydentów pomocy technicznej dotyczących problemów
• czas spędzony w godzinach na utrzymywaniu / wspomaganiu zespołu złego kodu / robieniu poprawek wsparcia
• koszt czasu oparty na stawce godzinowej osób wykonujących konserwację / pomoce zespołu / wsparcie
• jakiś sposób na zademonstrowanie, jak ważne dla firmy są te przedmioty

Aby uzasadnić refaktoryzację, potrzebujesz:

• oszacuj czas na refaktoryzację i wdrożenie każdej z 3 najlepszych z tych złych rzeczy
• kosztorys wdrożenia (takie same stawki godzinowe, jakie zastosowano powyżej)

Dzięki nim możesz uzasadnić oszczędność czasu, jeśli refaktoryzacja zajmuje o wiele mniej niż czas wsparcia dla 3 incydentów dla każdego z tych 3 najlepszych elementów. Możesz argumentować, że ta krótsza ilość czasu będzie wystarczająca

• być mniej niż n więcej incydentów wsparcia
• nie będzie więcej takich incydentów dla tych rzeczy (JESZCZE LEPSZE!)

Jednak najtrudniejsza część tej sprzedaży będzie odpowiadać na następujące pytanie, ponieważ wiele osób nie budżetuje czasu w harmonogramach na całe wsparcie, które wykonujesz:

Jak długo będę musiał czekać na zakończenie bieżącego projektu Y, gdy spędzasz czas na pracy nad tymi problemami z X ????? (pomimo obecnych czasów wsparcia, których nie można przewidzieć i zaplanować na wykresach Gantta)

Zależy to w dużej mierze od tego, jak dobrze komunikujesz się z decydentami i jak rozumieją sytuację.

ZDECYDOWANIE uważam, że warto to zrobić, więc ćwiczysz budowanie sprawy za pomocą mierników i oszczędzasz sobie czas, nawet jeśli tego nie robią. Niestety, nie wszyscy łatwo przekonać pomimo danych. POWODZENIA!

Pamiętaj, że refaktoryzacja wprowadza również błędy (które złapiesz podczas testowania, ale mimo to są błędami i muszą zostać naprawione). Nie ciągnij Netscape przez przypadek. To zależy od twojej osobistej definicji „refaktoryzacji”. Dla niektórych oznacza to „przepisanie całego kodu” na inne oznacza „zmień niektóre elementy wewnętrzne”. Jak powiedzieć, jaki jesteś? Zadaj sobie następujące pytanie:

Czy w ogóle zmieniam interfejs publiczny?

Jeśli odpowiedź brzmi „tak”, wykonujesz przeprojektowanie. Jeśli odpowiedź brzmi „nie”, dokonujesz refaktoryzacji i prawdopodobnie możesz to zrobić w trakcie codziennych czynności bez specjalnej zgody. Jest to istotne dla twojego pytania, ponieważ przeprojektowanie wygeneruje znacznie więcej błędów, a refaktoryzacja jest zwykle łatwiejsza do wykonania (ponieważ twoje testy już wykonują interfejs publiczny i nie będą musiały być modyfikowane).

Jest to trudny przypadek, ponieważ nikt nigdy nie wie, ile kosztowałby X z refaktorem wykonanym rok temu lub bez niego. Z mojego doświadczenia wynika, że ​​pragmatyczni menedżerowie zawsze strzelają do tego rodzaju rzeczy, ponieważ:

1. Wysiłek nie wiąże się z bezpośrednim strumieniem dochodów (koszt finansowy, niepodlegający rozliczeniu)
2. Brzydki działający kod nadal działa, ryzykujesz tworzenie problemów zamiast ich rozwiązywania (potencjalny koszt jakości)
3. Inne projekty będą opóźnione podczas refaktoryzacji (koszt czasu)

Wszystkie takie numery są ostatecznie na podstawie domysłów, w przypadku porównanie ilości odgadnąć to będzie kosztować nie byłaby wobec czego domyślać kosztowałoby do Refactor. Najlepsze, co możesz zrobić, to pokazać, że masz jakieś liczbowe, oparte na faktach podstawy do zgadywania, i masz całkiem niezłą.

Zaletą jest to, że prawdopodobnie skutecznie przekona ich, aby pozwolili ci się zreformować, a może pójść dobrze i zmniejszyć liczbę błędów.

Wadą jest to, że jeśli ilość czasu poświęcanego na naprawianie błędów nie spadnie przynajmniej tak długo, jak czas poświęcony na refaktoryzację, prawdopodobnie nie będziesz już mógł refaktoryzować i prawdopodobnie będziesz obwiniony za „zmarnowany” czas .

Oszczędność czasu debugowania uzyskana dzięki zmniejszeniu złożoności całego projektu lub ułatwieniu dodawania funkcji może być zbyt trudna do zmierzenia, aby ci pomóc, ale możesz wspomnieć, że one istnieją.