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?”.