Czy istnieje korelacja między złożonością kodu a wydajnością programisty?

10

Czy czas poświęcony na refaktoryzację bazy kodu jest warty na dłuższą metę, jeśli chodzi o produktywność programistów?

Wydaje mi się dość jasne, że modyfikacja czystego, dobrze zaprojektowanego systemu jest znacznie prostsza i szybsza niż praca na źle zaprojektowanym systemie, ale szukam pewnych solidnych dowodów. Czy są jakieś badania dotyczące tego tematu?

productivity complexity Benny Hallett
źródło
Zobacz REKONSTRUKCJA
hakre
1
Zacznij sam utrzymywać bałagan i bądź sędzią.
Tulains Córdova

Odpowiedzi:

16

Empirycznie trudniej jest utrzymać oprogramowanie o wyższych wskaźnikach złożoności, takich jak złożoność cykliczna. Istnieją badania potwierdzające to z lat 70. („Złożoność programu i produktywność programisty”, ET Chen) . Istnieją również prace sugerujące, że gęstość złożoności, która jest cykliczną złożonością w stosunku do wielkości systemu, dotyczy także czasu konserwacji („Gęstość cykliczności i produktywność konserwacji oprogramowania”, GK Gill, CF Kemerer) , która jest również dostępna tutaj za darmo . Niestety, abonament IEEE jest niezbędny do artykułu Chena, ale możesz spróbować poszukać go w innych źródłach, jeśli jesteś zainteresowany.

Z punktu widzenia jakości często warto poświęcić trochę czasu na refaktoryzację, zakładając, że masz wdrożone ramy testowe, aby zapobiec wprowadzeniu nowych wad. Umożliwi to łatwiejsze wdrażanie nowych funkcji w systemie, dodawanie dodatkowych testów i szkolenie nowych programistów do pracy.

Ostatecznie jednak istnieje presja na dostarczenie nowej funkcjonalności i wartości dodanej. Musisz zrównoważyć refaktoryzację z wdrożeniem nowej funkcjonalności i naprawą wad.

Thomas Owens
źródło
2
kolejną kwestią do dodania jest to, że podczas refaktoryzacji prawdopodobnie również implementujesz funkcje w sposób lepszy / bardziej wydajny / czystszy. Jest takie przysłowie, które słyszałem niezliczone czasy, że „za 5 lat będziesz żałować, że uważasz, że Twój kod jest„ dobry ”
warren
1
@hakre Sprawdziłem, kiedy to opublikowałem i teraz, używając zarówno wyszukiwarki Google, jak i Google Scholar. W momencie, gdy pierwotnie napisałem ten post, żaden artykuł nie był dostępny bez zakupu. Jednak od tego czasu jeden artykuł został opublikowany na domenie University of Pittsburgh, która wydaje się należeć do jednego z autorów i dołączyłem do niego link. Drugi papier nie jest dostępny za darmo. Dodałem tytuły do ​​treści wpisu, aby nieco ułatwić ich wyszukiwanie. Jeśli nie chcesz czytać artykułów, musisz zaakceptować moją analizę w połączeniu z moją wiedzą i doświadczeniem.
Thomas Owens
0

Szukam solidnych dowodów

Więc przestań marnować tutaj swój czas.

  1. Znajdź kod, który jest drogi w utrzymaniu. To jest łatwe. Zobacz bilety problemów swojej organizacji.

  2. Znajdź kod, który jest tani w utrzymaniu. Znajdź kod, który jest często uruchamiany, ale ma kilka zgłoszeń problemów lub nie ma go wcale.

  3. Zmierz złożoność za pomocą dowolnego z powszechnie dostępnych narzędzi do zarządzania złożonością.

  4. Wygrzej się w dowodzie.

Podałeś teraz liczby, aby potwierdzić oczywistość.

S.Lott
źródło
5
Nie całkiem. złożoność zadania wykonywanego przez oprogramowanie należy odróżnić od dodatkowej złożoności spowodowanej wybraną implementacją.
reinierpost
4
-1 brak odpowiedzi
Dave Hillier