Jak określić priorytet i wagę „ulepszenia kodu”?

W naszym systemie śledzenia błędów mamy pola „priorytet” i „ważność”. Istotność definiujemy jako „jak wpływa na użytkownika”, a priorytet na „jak wpływa na produkt”.

Moje pytanie dotyczy tego, jak sklasyfikować zadanie „poprawy kodu” pod względem ważności i priorytetu. Załóżmy, że ulepszenie nie zmienia żadnego zachowania, ale czyni go „lepszym kodem”. Oczekujemy ogólnie długoterminowej poprawy konserwacji, ale trudno ją oszacować.

Kiedy używamy naszych definicji dla priorytetu i ważności, poprawa kodu uzyskuje najniższe wartości dla obu, chyba że wprowadzisz do obrazu pewne trudne do przewidzenia długoterminowe korzyści. Oznacza to, że poprawa kodu jest niepoważnym zadaniem i nigdy nie należy próbować.

Jednak uważam, że niezwykle ważne jest ciągłe ulepszanie i przekształcanie kodu, ponieważ:

• Rozwój oprogramowania sam w sobie jest ciągłym procesem uczenia się i bez ulepszania kodu nie da się go polepszyć.
• Zespół powinien być dumny ze swojego kodu.
• Przyszła konserwacja zajmie mniej czasu, a w długim okresie oszczędności będą znaczące.

Czy uważasz, że takie zadania nigdy nie powinny być tworzone, a takie ulepszenia wykonywane tylko „na żądanie”, „gdy są powiązane z błędem”? Nawet jeśli jest to związane z błędem, czy nie byłby to punkt dyskusji na temat przeglądu kodu, np. „Dlaczego dokonałeś tak drastycznej zmiany w strukturze?”.

Zazwyczaj nie lubię postrzegać działań związanych z „ulepszaniem kodu” jako osobnego zadania, które można przypisać, ponieważ samo ulepszanie kodu nigdy nie przybliża bezpośrednio do wypełniania historii użytkowników lub wymagań. Właśnie dlatego zadania poprawy kodu zawsze będą miały tak niski priorytet, że nigdy nie zostaną przypisane.

Widzę poprawę kodu jako stałą, coś, co każdy programista powinien robić tak naturalnie, jak pisanie na klawiaturze. Uwzględniam to w moich szacunkach dla każdego zadania. Jeśli moim zadaniem jest dotknięcie klasy lub jakiegoś kodu źródłowego, który nie był oglądany od dłuższego czasu, zakładam, że pewna praca porządkowa jest prawdopodobnie w porządku i odpowiednio zwiększam swoje oszacowanie.

Najlepszy scenariusz Przypadek kończę zadanie wcześniej i mogę wykorzystać pozostały czas na ulepszenie kodu, a nawet zaprojektowanie. W najgorszym przypadku zadanie to trwa znacznie dłużej niż oczekiwano, ale mam ten dodatkowy czas jako bufor.

Jeśli chcesz zmienić kod, ustaw priorytet zadania zgodnie z definicją (tj. „Jak wpływa na produkt”). Niektóre refaktoryzacje nie będą miały większego wpływu na produkt, a inne będą, w zależności od zakresu wymaganej pracy. Ustawienie wyższego priorytetu będzie oznaczało, że po zakończeniu refaktoryzacji trzeba będzie przeprowadzić więcej testów, aby upewnić się, że nie wystąpi nic nieoczekiwanego.

Możesz także chcieć wprowadzić nową kategorię do swojego systemu śledzenia błędów, aby podzielić zadania tego rodzaju na zadania „Refaktoryzacja”. W ten sposób będziesz wiedział, jak interpretować wartość priorytetu; oznacza to, że wyższy priorytet oznacza większy wpływ, a zatem wymaga więcej testów.

Brakuje tylko weryfikacji twoich założeń dotyczących istniejącego kodu: jeśli uda nam się ulepszyć kod, można uzyskać mniej czasu i znaczne oszczędności. Czy to kosmetyk, czy występują poważne problemy?

Sprawdź swoje prognozy debugowania i ulepszeń. Jeśli trwa to dłużej i pojawiają się ciągłe komentarze na temat konieczności zmiany kodu w pierwszej kolejności lub wyczyszczenia go, może to być najlepszy pomiar. Następnie możesz zidentyfikować swoją bazę kodu jako: Dobra, wymaga drobnych przeróbek lub poważnego refaktoryzacji.

Wszystko to jest względne. Trudno jest nadać tak wysoki priorytet, gdy są klienci, którzy chcą więcej funkcji i są gotowi zapłacić natychmiast za rozliczane godziny.

Interesujące pytanie.

Myślę, że musisz oszacować, ile wierszy kodu i ile modułów może wpłynąć na zmianę.

Może mógłbyś sprawdzić, ile testów jednostkowych, jeśli je masz, ulegnie uszkodzeniu, dokonując zmiany. Prawdopodobnie oznaczałoby to wypróbowanie zmiany w oddziale, aby uzyskać pomysł.

Następnie określ progi dla tych poziomów priorytetu i ważności.

Należy również wziąć pod uwagę, że konieczne będzie zaangażowanie wielu testerów. Jeśli zmiana dotyczy dużej powierzchni aplikacji, konieczne może być ponowne przetestowanie wielu systemów.

Zacznijmy od dwóch założeń tutaj.

1. Do każdej nowej historii piszesz swój kod najlepiej jak potrafisz, być może wsparty wiedzą otoczenia Twojego zespołu.
2. Ilekroć masz historię, która zmienia funkcjonalność istniejącego kodu, wykorzystujesz swoją nową wiedzę o systemie i lepsze umiejętności, aby ulepszyć kod w procesie wdrażania nowej historii.

Biorąc pod uwagę te dwa założenia, nigdy nie ma potrzeby wyraźnego wysiłku „ulepszania kodu”. Twój kod poprawia się podczas pisania systemu. Oznacza to, że nie cały kod spełnia najnowsze i największe standardy w zakresie konserwacji, ale „Jeśli nie jest zepsuty, nie naprawiaj go”. Uważam, że kod refaktoryzacji, który nie musi być zmieniany, to „pozłacanie” tak samo, jak dodanie niepotrzebnej widocznej funkcjonalności. Jeśli kod jest w jakiś sposób uszkodzony, napisz prawidłowy test, który się nie powiedzie; zaloguj błąd; a następnie refaktoryzować, aby rozwiązać ten błąd.

Kradnę głosowanie z ruchu Agile:

Wprowadź błąd, zgadnij surowość i priorytet,

Następnie codziennie, co tydzień lub co miesiąc przeglądaj wszystkie nowe błędy i głosuj na ich oceny. Najlepiej jest to zrobić podczas spotkania z użytkownikami końcowymi na temat planowania sprintu. Następnie możesz porozmawiać o kolejnych funkcjach w tym czasie i być pozytywnym,