Mythical Man month 10 lines per developer day - jak blisko dużych projektów? [zamknięte]

W jednym z moich obecnych projektów, w niektórych modułach, jestem dumny, że przyczyniłem się do ujemnej liczby linii do bazy kodu. Przydatną umiejętnością jest określenie, które obszary kodu urosły niepotrzebnie i można je uprościć za pomocą czystszego i wyraźniejszego projektu.

Oczywiście niektóre problemy są z natury złożone i wymagają złożonych rozwiązań, ale w większości dużych projektów obszary, które miały słabo zdefiniowane lub zmieniające się wymagania, mają tendencję do zbyt złożonych rozwiązań z większa liczba spraw na linię.

Biorąc pod uwagę problem do rozwiązania zdecydowanie wolę rozwiązanie, które zmniejsza liczbę linii. Oczywiście na początku małego projektu mogę wygenerować o wiele więcej niż dziesięć linijek kodu dziennie, ale zazwyczaj nie myślę o ilości kodu, który napisałem, tylko o tym, co robi i jak dobrze to robi. Na pewno nie dążyłbym do pokonania dziesięciu linii dziennie lub uznania tego za osiągnięcie.

Podoba mi się ten cytat:

Jeśli chcemy policzyć linie kodu, nie powinniśmy traktować ich jako "linie wyprodukowane", ale jako "linie wydane". - Edsger Dijkstra

Kilka razy przyczyniłeś się bardziej usuwając Kod niż dodając

Powinieneś przestać używać tej metryki, to w większości nie ma znaczenia. Spójność, sprzężenie i złożoność są ważniejszymi metrykami niż linie kodu.

Jak sobie radzą inni?

Jestem jedynym pełnoetatowym programistą w naszej firmie i napisałem 500 000 linii kodu OCaml i F# w ciągu ostatnich 7 lat, co odpowiada około 200 liniom kodu dziennie. Jednak zdecydowana większość tego kodu to przykłady samouczków składające się z setek oddzielnych projektów o długości kilkuset linii. Ponadto, istnieje wiele duplikacji między OCaml i F#. Nie utrzymujemy żadnych baz kodów wewnętrznych większych niż 50kLOC.

Oprócz tworzenia i utrzymywania własnego oprogramowania, konsultowałem się również z wieloma klientami z branży w ciągu ostatnich 7 lat. Dla pierwszego klienta, napisałem 2000 linii OCaml w ciągu 3 miesięcy, czyli 20 linii kodu dziennie. Dla następnego klienta, czworo z nas napisało kompilator, który wygenerował miliony linii kodu C/C++/Python/Java/OCaml oraz dokumentację w ciągu 6 miesięcy, czyli 2000 linii kodu dziennie na programistę. Dla innego klienta, ja zastąpił 50kLOC C++ na 6kloc F# w ciągu 6 miesięcy, czyli -352 linijki kodu dziennie. Dla yet another client przepisuję 15kloc OCaml w F#, który będzie tego samego rozmiaru, więc 0 linii kodu dziennie.

Dla naszego obecnego klienta , zamienię 1 600 000 linii kodu C++ i Mathematica na ~160kloc F# w ciągu 1 roku (pisząc kompilator na zamówienie), który będzie wynosił -6 000 linii kodu dziennie. To będzie mój najbardziej udany projekt do tej pory i uratuje nasze klient miliony dolarów rocznie w bieżących kosztach. Myślę, że każdy powinien starać się pisać -6000 linijek kodu dziennie.

Bez sprawdzania mojej kopii "mitycznego męskiego miesiąca" (każdy czytający to powinien mieć kopię łatwo dostępną), był rozdział, w którym Brooks spojrzał na produktywność po napisanych wierszach. Ciekawostką dla niego nie była rzeczywista liczba wierszy napisanych dziennie, ale fakt, że wydawało się to mniej więcej takie samo w asemblerze i w PL / I(myślę, że był to język wyższego poziomu).

Brooks nie chciał wyrzucić jakiegoś arbitralnego postać produktywności, ale pracował na podstawie danych o rzeczywistych projektach, i z tego co pamiętam, mogły one być średnio 12 linii / dzień.

Zwrócił uwagę, że produktywność może być różna. Powiedział, że Kompilatory są trzy razy twardsze niż programy aplikacyjne, a systemy operacyjne trzy razy twardsze niż Kompilatory. (Wydaje się, że lubił używać mnożników trzech do oddzielania kategorii.)

Nie wiem czy doceniał wtedy indywidualność różnice między produktywnością programisty (chociaż w argumencie rzędu wielkości postulował czynnik siedmiu różnic), ale jak wiemy wyższa produktywność nie jest tylko kwestią pisania większej ilości kodu, ale także pisania właściwego kodu do wykonania zadania.

Jest też kwestia środowiska. Brooks spekulował trochę o tym, co sprawi, że deweloperzy będą szybsi lub wolniejsi. Jak wielu ludzi, zastanawiał się, czy obecne fad (interaktywne debugowanie za pomocą podziału czasu systemy) były lepsze niż stare sposoby (staranne przygotowanie do dwugodzinnego strzału przy użyciu całej maszyny).

Biorąc pod uwagę, że lekceważyłbym każdą rzeczywistą liczbę produktywności, którą wymyślił jako bezużyteczną; ciągła wartość książki tkwi w Zasadach i bardziej ogólnych lekcjach, których ludzie nie uczą się. (Hej, gdyby wszyscy się ich nauczyli, książka byłaby interesująca tylko historycznie, podobnie jak wszystkie argumenty Freuda, że istnieje coś w rodzaju podświadomości umysł.)

Łatwo jest uzyskać kilkaset linijek kodu dziennie. Ale postaraj się uzyskać kilkaset linii kodu jakości dziennie i nie jest to takie proste. Góra to z debugowaniem i przechodzeniem przez dni z małą ilością lub bez nowych linii dziennie, a średnia spadnie dość szybko. Spędziłem tygodnie debugowania trudnych problemów i odpowiedź jest 1 lub 2 linijki kodu.

Byłoby znacznie lepiej zdać sobie sprawę, że mówienie o fizycznych liniach kodu jest dość bezsensowne. Liczba fizycznych linii kodu (LoC)jest tak zależna od stylu kodowania, że może się różnić o rząd wielkości od jednego programisty do drugiego.

W świecie. Net istnieje wygodny sposób liczenia LoC. Punkt sekwencji . Punkt sekwencji jest jednostką debugowania, jest to część kodu podświetlona na ciemnoczerwony podczas umieszczania punktu przerwania. Z punktem sekwencji mamy może mówić o logicznym LoC , a ten metryczny może być porównywany w różnych językach. NET. Logical Loc code metric jest obsługiwany przez większość narzędzi. NET, w tym VisualStudio code metric, NDepend lub NCover.

Na przykład, oto metoda 8 LoC (punkty sekwencji w nawiasach początkowych i końcowych nie są brane pod uwagę):

Produkcja LoC musi być liczona w dłuższej perspektywie. Niektóre dni będziesz pluć więcej niż 200 LoC, inne dni spędzisz 8 godzin naprawianie błędu przez nie dodawanie nawet jednego LoC. Niektóre dni wyczyścisz martwy kod i usuniesz LoC, niektóre dni spędzisz cały swój czas na refaktoryzacji istniejącego kodu i nie dodajesz żadnego nowego LoC do sumy.

Osobiście liczę pojedyncze LoC w moim własnym wyniku produktywności tylko wtedy, gdy:

1. jest objęty testami jednostkowymi
2. jest to związane z jakimś rodzajem umowy kodowej (jeśli to możliwe, nie wszystkie LoC oczywiście mogą być sprawdzane przez umowy).

W tym stanie, mój osobisty wynik w ciągu ostatnich 5 lat kodowania narzędzia Ndepends dla programistów. NET wynosi średnio 80 fizycznych LoC dziennie bez poświęcania żadnej średniej jakości kodu . Rytm jest utrzymany i nie widzę, żeby w najbliższym czasie się zmniejszył. Ogólnie rzecz biorąc, NDepend jest bazą kodu C#, która obecnie waży około 115k fizycznego LoC

Dla tych, którzy nienawidzą liczenia LoC (widziałem ich wielu w komentarzach tutaj), zaświadczam, że raz odpowiednio skalibrowane, liczenie LoC jest doskonałym narzędzie szacowania . Po zakodowaniu i zmierzeniu dziesiątek funkcji osiągniętych w moim konkretnym kontekście rozwoju, osiągnąłem punkt, w którym mogę dokładnie oszacować rozmiar dowolnej funkcji TODO w LoC i czas, jaki zajmie mi dostarczenie jej do produkcji.

Nie ma czegoś takiego jak Srebrna kula.

Taki pojedynczy metryk sam w sobie jest bezużyteczny.

Na przykład, mam własną bibliotekę klasową. Obecnie prawdziwe są następujące statystyki:

Suma wierszy: 252.682
Kod linii: 127.323
Komentarze: 99.538
Puste linie: 25.821

Załóżmy, że w ogóle nie piszę żadnych komentarzy, czyli 127.323 linijek kodu. Z Twoim współczynnikiem, ta biblioteka kodu zabierze mnie 10610 dni na napisanie. To 29 lat.

Na pewno nie spędziłem 29 lat pisząc ten kod, ponieważ to wszystko C#, A C# nie było już tak długo.

Teraz możesz argumentować, że kod nie jest aż tak dobry, ponieważ oczywiście musiałem przekroczyć Twoje 12 linijek dziennie metryki, i tak, zgodzę się na to, ale jeśli mam sprowadzić oś czasu do czasu wydania 1.0 (i nie zacząłem go robić aż do wydania 2.0), czyli 2002-02-13, około 2600 dni, to jest to, że nie wiem, jak to zrobić. średnia to 48 linijek kodu dziennie.

Wszystkie te linie kodu są dobre? Nie ma mowy. Ale do 12 linijek kodu dziennie?

Heck no.

Wszystko zależy.

Możesz mieć najwyższej klasy programistę ubijającego kod w kolejności tysięcy linii dziennie, a średni programista ubijający kod w kolejności setek linii dziennie, a jakość jest taka sama.

I tak, będą błędy.

Suma, którą chcesz, to równowaga. Ilość kodu zmienione, w porównaniu z liczbą znalezionych błędów, w porównaniu ze złożonością kodu, w porównaniu z trudnościami w naprawieniu tych błędów.

Steve McConnell podaje interesującą statystykę w swojej książce "szacowanie oprogramowania" (P62 tabela 5.2) Rozróżnia typy projektów (awioniczne, biznesowe, Telco itp.) i wielkości projektów 10 kLOC, 100 kLOC, 250 kLOC. Numery są podane dla każdej kombinacji w Loc/StaffMonth. Np. Awionika: 200, 50, 40 Systemy Intranetowe (Wewnętrzne): 4000, 800, 600 Systemy Wbudowane: 300, 70, 60

Co oznacza: np. dla projektu Avionic 250-kLOC jest 40 (LOC / miesiąc)/22 (dni / miesiąc) ==

Myślę, że pochodzi to z Dni Rozwoju wodospadu , gdzie rzeczywista faza rozwoju projektu może wynosić zaledwie 20-30% całkowitego czasu projektu. Weź całkowitą liczbę linii kodu i podziel przez cały czas projektu, a otrzymasz około 10 linii / dzień. Podziel tylko przez okres kodowania, a zbliżysz się do tego, co ludzie cytują.

Nasza baza kodowa to około 2,2 MLoC dla około 150 Man-lat wysiłku. Czyli o 75 linie c++ lub c# na programistę na dzień, przez cały okres trwania projektu.

Myślę, że rozmiar projektu i liczba zaangażowanych deweloperów są w tym Duże czynniki. Jestem daleko powyżej tego w mojej karierze, ale pracowałem sam przez cały ten czas, więc nie ma strat w pracy z innymi programistami.

Dobre planowanie, dobry projekt i dobrzy Programiści. Masz tyle czasu i nie poświęcisz 30 minut na napisanie jednej linijki. Tak, wszystkie projekty wymagają,aby zatrzymać i planować,przemyśleć, omówić, przetestować i debugować, ale przy dwóch liniach dziennie każda firma potrzebuje armii, aby Tetris do pracy...

Reasumując, gdybyś pracował dla mnie po 2 linie na godzinę, lepiej przynieś mi dużo kawy i posmaruj moje stopy, żeby cię nie wylali.

Podejrzewa się, że ten odwieczny bit Manager-candy został wymyślony, gdy wszystko było aplikacją sys napisaną w C, ponieważ jeśli nic innego, magiczna liczba zmieniałaby się o rzędy wielkości w zależności od języka, skali i charakteru aplikacji. A potem musisz zdyskontować komentarze i atrybuty. A kogo w końcu obchodzi liczba napisanych linijek kodu? Masz być skończony, gdy osiągniesz 10 km linii? 100 tysięcy? Takie arbitralne.

To bezużyteczne.