Mityczny człowiek miesięcznie 10 linii na dzień dewelopera - jak blisko w przypadku dużych projektów? [Zamknięte]


129

Wszyscy zawsze mówią, że mogą pokonać „10 linii na programistę dziennie” z „Miesiąca Mitycznego Człowieka”, a rozpoczynając projekt, zwykle mogę dostać kilkaset linii dziennie.

Ale u mojego poprzedniego pracodawcy wszyscy programiści byli bardzo sprytni, ale był to duży projekt, ponad milion linii kodu, z bardzo uciążliwymi wymaganiami certyfikacyjnymi i łączący się z innymi wielomilionowymi projektami. W pewnym momencie, jako ćwiczenie z ciekawości, wykreśliłem linie kodu w produkcie wysyłkowym w mojej grupie (nie licząc narzędzi, które opracowaliśmy) i oczywiście, stopniowo, dochodził do około 12 linii dodawania netto na programistę dziennie. Nie licząc zmian, kodu testowego czy faktu, że programiści nie pracowali codziennie nad rzeczywistym kodem projektu.

Jak się mają inni ludzie? A jakie masz wymagania (wyobrażam sobie, że jest to czynnik)?


13
powinno być wiki społeczności.
Malfist

24
Gdyby „10” było binarne, byłoby bliżej znaku.
geofftnz

2
Bardzo interesujące pytanie. :)
Emil H

9
Znalazłem fajny cytat: „Pomiar postępu programowania za pomocą linii kodu jest jak mierzenie postępu budowy samolotu według wagi”. w tej witrynie [link] ( devtopics.com/101-great-computer-programming-quotes )
mm24

2
@Greg Bacon, Bill the Lizard: Naprawdę chciałbym, aby to pytanie zostało ponownie otwarte. Może nie pasuje do zasad SO, ale zdecydowanie przyciąga gości. (Do tej pory 35875 widzów)
Skippy Fastol

Odpowiedzi:


46

Myślę, że liczba dodanych wierszy w dużym stopniu zależy od stanu projektu, a tempo dodawania do nowego projektu będzie znacznie wyższe niż w przypadku projektu początkowego.

Praca jest inna w obu przypadkach - przy dużym projekcie zwykle spędzasz większość czasu na ustalaniu relacji między częściami, a jedynie niewielką ilość na faktyczną zmianę / dodanie. podczas gdy w nowym projekcie - głównie piszesz ... dopóki nie jest wystarczająco duży i tempo się zmniejsza.


W rzeczy samej. Na początku tego projektu reklama netto była znacznie większa.
Matthias Wandel

1
Tak więc podtrzymuje teorię dzielenia dużego projektu na wiele niezależnych części (mogą to być nawet niezależne projekty) - w celu oddzielenia.
sergzach

108

Jestem dumny, że w jednym z moich obecnych projektów, w niektórych modułach, włożyłem ujemną liczbę wierszy do podstawy kodu. Określenie, które obszary kodu stały się niepotrzebnie skomplikowane i można je uprościć dzięki bardziej przejrzystemu i przejrzystemu projektowi, jest użyteczną umiejętnością.

Oczywiście niektóre problemy są z natury złożone i wymagają złożonych rozwiązań, ale w przypadku większości dużych projektów obszary, które miały słabo zdefiniowane lub zmieniające się wymagania, zwykle mają zbyt złożone rozwiązania z większą liczbą problemów 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ęć linii kodu dziennie, ale nie myślę o ilości kodu, który napisałem, tylko o tym, co robi i jak dobrze to robi. Z pewnością nie zamierzałbym pokonywać dziesięciu linii dziennie ani uważać tego za osiągnięcie.


49
+1 za dodanie linii negatywnych. Kiedyś pracowałem nad małym projektem, w którym zmniejszyłem liczbę linii z 15 000 do 5 000, dodając nowe funkcje (i znacznie zmniejszając liczbę błędów i zwiększając prędkość).
rmeador

55

Podoba mi się ten cytat:

Jeśli chcemy liczyć wiersze kodu, nie powinniśmy traktować ich jako „wyprodukowane wiersze”, ale jako „wykorzystane wiersze”. - Edsger Dijkstra

Czasami wnieśliście więcej, usuwając kod niż dodając


30

Powinieneś przestać używać tego wskaźnika, w większości przypadków jest on bez znaczenia. Spójność, sprzężenie i złożoność są ważniejszymi miernikami niż wiersze kodu.


25
Nie używałem go jako miernika produktywności. To było prywatne ćwiczenie dla mojej własnej ciekawości.
Matthias Wandel

3
Słusznie. Mimo to trudno jest odpowiedzieć bez dokładniejszej definicji tego, co należy uznać za wiersz kodu.
Otávio Décio

1
@Matthias: Powinienem edytować to w OP, gdybym był tobą, na przykład byłbym mniej ... agresywny: P
annakata

28

Jak się mają inni ludzie?

Jestem jedynym programistą pracującym na pełny etat 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, z których każdy ma kilkaset wierszy. Ponadto istnieje wiele duplikatów między OCaml i F #. Nie utrzymujemy żadnych wewnętrznych baz kodów większych niż 50 kLOC.

Oprócz tworzenia i utrzymywania własnego oprogramowania, w ciągu ostatnich 7 lat doradzałem także wielu klientom z branży. Dla pierwszego klienta napisałem 2000 linii kodu OCaml w ciągu 3 miesięcy, co daje 20 linii kodu dziennie. Dla kolejnego klienta czterech z nas napisało kompilator, który wygenerował miliony linii kodu C / C ++ / Python / Java / OCaml, a także dokumentację w ciągu 6 miesięcy, co daje 2000 linii kodu dziennie na programistę. Dla innego klienta zamieniłem 50kLOC C ++ na 6kLOC F # w 6 miesięcy, co daje -352 linie kodu dziennie. Dla jeszcze jednego klienta przepisuję 15kLOC OCaml w F #, który będzie tego samego rozmiaru, czyli 0 linii kodu dziennie.

Dla naszego obecnego klienta zamienię 1600000 linii kodu C ++ i Mathematica na ~ 160kLOC języka F # w ciągu 1 roku (pisząc kompilator na zamówienie), co będzie kosztować -6000 linii kodu dziennie. To będzie mój najbardziej udany projekt do tej pory i pozwoli zaoszczędzić naszym klientom miliony dolarów rocznie na bieżących kosztach. Myślę, że każdy powinien starać się pisać -6 000 linii kodu dziennie.


1
Podoba mi się twoja odpowiedź i rozumiem sarkazm. Z samej ciekawości, czy mógłbyś wyjaśnić, dlaczego przepisanie kodu w języku F # pozwoli zaoszczędzić pieniądze twojego klienta? Znałem OCaml i napisałem tłumacza w tym języku i nie dotykałem tego języka od kilku lat, a teraz wciąż słyszę F # (więc jestem tego bardzo ciekawy)
mm24

7
@ mm24 „czy mógłbyś wyjaśnić, dlaczego przepisanie kodu w języku F # pozwoli zaoszczędzić pieniądze Twojego klienta”. Po pierwsze, zostali naprawdę oszukani przez Wolfram Research, który obciążył ich kontraktami na konsultacje o wartości 1 miliona funtów, aby naprawić problemy, które celowo wprowadzili w aktualizacjach Mathematica, np. Zmiana semantyki [LongDash]. Po drugie, konsolidują dwie bazy kodu (Mathematica i C ++), które są obecnie utrzymywane w tandemie w jedną bazę kodu F #, zmniejszając nie tylko powielony wysiłek, ale także wiele interakcji związanych z aktualizacjami produktów i poprawkami zidentyfikowanymi podczas testowania.
JD

7
@ mm24 Po trzecie, automatyzacja. Robią ręcznie wiele rzeczy, do których albo istnieją już istniejące narzędzia .NET do automatyzacji, albo .NET ułatwia tworzenie takich narzędzi. Zadania obejmują instrumentowanie kodu z licznikami czasu do mierzenia wydajności (użyj profilera), ręczne pisanie serializatorów (użycie biblioteki), ręczne kopiowanie nazw klucz-wartość (użycie odbicia) i krytyczne aktualizacje systemów na żywo przesłane przez firmę są wykonywane przez osoby w IT ręcznie (napisz narzędzie, aby firma mogła bezpośrednio wprowadzać zmiany).
JD

7
@ mm24 Po czwarte, ogromna poprawa wydajności. F # jest o rząd wielkości szybszy niż Mathematica, a ich kod weryfikacyjny w języku F # jest 5x szybszy niż ich produkcyjny kod C ++. Oznacza to, że testy są wykonywane w ciągu sekund, a nie godzin, w którym to momencie testowanie staje się integralną częścią rozwoju, radykalnie poprawiając produktywność.
JD

7
@ mm24 Po piąte, zwiększone możliwości. Chcą wyeliminować martwy kod i zmierzyć pokrycie kodu w swoich testach, ale nie mogą tego zrobić za pomocą narzędzi, z których korzystają. Przejście na .NET sprawia, że ​​jest to (i nie tylko!) Łatwe.
JD

13

Bez faktycznego sprawdzania mojego egzemplarza „Mitycznego miesiąca człowieka” (każdy, kto to czyta, powinien mieć łatwo dostępny egzemplarz), był rozdział, w którym Brooks przyglądał się produktywności za pomocą napisanych wierszy. Interesującą kwestią dla niego nie była faktyczna liczba wierszy pisanych dziennie, ale fakt, że wydawało się, że jest mniej więcej taki sam w asemblerze i PL / I (myślę, że był to używany język wyższego poziomu).

Brooks nie miał zamiaru wyrzucać jakiejś arbitralnej wartości produktywności, ale pracował na podstawie danych dotyczących rzeczywistych projektów iz tego, co pamiętam, mogło to wynosić średnio 12 linii dziennie.

Zwrócił uwagę, że można się spodziewać wahań wydajności. Powiedział, że kompilatory były trzy razy trudniejsze niż programy użytkowe, a systemy operacyjne trzy razy trudniejsze niż kompilatory. (Wydaje się, że lubił używać mnożników trzech do oddzielenia kategorii).

Nie wiem, czy doceniał wtedy indywidualne różnice między produktywnością programisty (chociaż w argumencie o rząd wielkości postulował siedmiokrotną różnicę), ale jak wiemy, najwyższa produktywność to nie tylko kwestia pisania więcej kod, ale także napisanie odpowiedniego kodu do wykonania zadania.

Jest też kwestia środowiska. Brooks spekulował trochę na temat tego, co uczyniłoby programistów szybszymi lub wolniejszymi. Podobnie jak wiele osób, wątpił, czy obecne mody (debugowanie interaktywne z wykorzystaniem systemów podziału czasu) były lepsze od starych (ostrożne wstępne planowanie dwugodzinnego ujęcia z wykorzystaniem całej maszyny).

Biorąc to pod uwagę, zignorowałbym każdą rzeczywistą liczbę produktywności, którą wymyślił, jako bezużyteczną; Stała wartość książki tkwi w zasadach i bardziej ogólnych lekcjach, których ludzie uparcie się nie uczą. (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.)


3
Myśl o innej produktywności programisty - Z mojego doświadczenia wynika, że ​​przeciętny programista zajmie x razy więcej czasu na rozwiązanie danego problemu, ale też niestety napisze x razy więcej kodu. Tak więc, biorąc pod uwagę proste „wiersze kodu dziennie”, przeciętny programista jest równie produktywny.
Matthias Wandel

11

Łatwo jest uzyskać kilkaset wierszy kodu dziennie. Ale spróbuj uzyskać kilkaset wysokiej jakości linii kodu dziennie i nie jest to takie łatwe. Dodaj do tego debugowanie i przechodzenie przez dni z niewielką liczbą nowych linii lub bez nich, a średnia spadnie dość szybko. Spędziłem tygodnie na debugowaniu trudnych problemów, a odpowiedź to 1 lub 2 wiersze kodu.


W rzeczy samej. Ale gdy projekt się rozrasta, częściej trafisz na ten scenariusz. Napisałem doskonałe 10-liniowe programy, które nie miały żadnych błędów. To wszystko kwestia skali.
Matthias Wandel

1
Nie ma programów, które nie zawierają błędów.
Daniel Moura

14
Bah! twoja gramatyka zawiera błędy ...
RAL

3
@DanielMoura Och, nie zgodziłbym się z tym ... Program „hello world” może nie być zbyt przydatny, ale można by z całą pewnością powiedzieć, że nie ma żadnych błędów :)
WendiKidd

10

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

W świecie .NET istnieje wygodny sposób liczenia LoC. Punkt sekwencji . Punkt sekwencji to jednostka debugowania, to część kodu podświetlona na ciemnoczerwono podczas wstawiania punktu przerwania. Za pomocą punktu sekwencji możemy mówić o logicznym LoC , a metrykę tę można porównać w różnych językach .NET. Metryka logicznego kodu LoC jest obsługiwana przez większość narzędzi .NET, w tym metrykę kodu VisualStudio, NDepend lub NCover.

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

tekst alternatywny

Produkcja LoC musi być liczona w perspektywie długoterminowej. W niektóre dni będziesz pluć więcej niż 200 LoC, w inne dni spędzisz 8 godzin na naprawie błędu, nie dodając nawet jednego LoC. W niektóre dni wyczyścisz martwy kod i usuniesz LoC, w niektóre dni spędzisz cały swój czas na refaktoryzacji istniejącego kodu i nie dodawaniu nowego LoC do całości.

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

  1. Jest objęty testami jednostkowymi
  2. jest to związane z jakimś kontraktem kodowym (jeśli to możliwe, oczywiście nie wszystkie LoC można sprawdzić w umowach).

W tym stanie mój osobisty wynik w ciągu ostatnich 5 lat, kiedy kodowałem narzędzie NDepend dla programistów .NET, to średnio 80 fizycznych LoC dziennie bez jakiegokolwiek uszczerbku dla jakości kodu . Rytm jest trwały i nie widzę, żeby w najbliższym czasie zmniejszył się. Podsumowując, NDepend to baza kodu C #, która obecnie waży około 115K fizycznego LoC

Dla tych, którzy nienawidzą liczenia LoC (widziałem ich wiele w komentarzach tutaj), zaświadczam, że po odpowiednim skalibrowaniu liczenie LoC jest doskonałym narzędziem do szacowania . Po zakodowaniu i pomiarze dziesiątek funkcji osiągniętych w moim szczególnym kontekście rozwoju, doszedłem do punktu, w którym mogę dokładnie oszacować rozmiar dowolnej funkcji TODO w LoC i czas, jaki zajmie mi dostarczenie jej do produkcji.


1
Twój post ma fundamentalne znaczenie i zasługuje na znacznie więcej pozytywnych głosów.
Skippy Fastol

9

Nie ma czegoś takiego jak srebrna kula.

Pojedyncza metryka sama w sobie jest bezużyteczna.

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

Łączna liczba wierszy: 252.682
Linie kodu: 127.323
Komentarze: 99.538
Puste wiersze: 25.821

Załóżmy, że w ogóle nie piszę żadnych komentarzy, to znaczy 127.323 linii kodu. Z twoim stosunkiem napisanie tej biblioteki kodu zajęłoby mi około 10610 dni. To 29 lat.

Na pewno nie spędziłem 29 lat na pisaniu tego kodu, ponieważ wszystko to jest C #, a C # nie istnieje tak długo.

Teraz możesz argumentować, że kod nie jest wcale taki dobry, ponieważ najwyraźniej musiałem przekroczyć twoje 12 linii dziennie i tak, zgodzę się na to, ale jeśli mam sprowadzić oś czasu do kiedy została wydana wersja 1.0 (a nie zacząłem jej tworzyć przed wydaniem wersji 2.0), czyli 2002-02-13, około 2600 dni, średnia to 48 linii kodu dziennie.

Czy wszystkie te wiersze kodu są dobre? Na pewno nie. Ale do 12 linii kodu dziennie?

Na pewno nie.

Wszystko zależy.

Możesz mieć programistę najwyższej klasy, który wypuszcza kod w kolejności tysięcy wierszy dziennie, a średni programista produkuje kod w kolejności setek wierszy dziennie, a jakość jest taka sama.

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

Suma, którą chcesz, to równowaga. Ilość zmienionego kodu, liczba znalezionych błędów, złożoność kodu, a trudność związana z naprawieniem tych błędów.


Amen! (plus spacje na spotkanie 15 minut)
Nate

Uwaga, te statystyki zostały obliczone przez DPack ( usysware.com/dpack ).
Lasse V. Karlsen

5
Być może zasada 10 wierszy dziennie nie dotyczy czegoś mniejszego, takiego jak biblioteka klas, którą napisałeś (zakładam sam). Wiele liczb Brooks pochodzi z dużych projektów (IBM OS360), których skala jest zasadniczo inna niż w Twojej bibliotece klas. Domyślam się, że obserwacja Brooksa jest (często) ważna w przypadku dużych projektów, które wymagają wielu ludzi i znaczącej sieci komunikacji międzyludzkiej, ale nieważna w przypadku mniejszych projektów.
J. Polfer

6

Steve McConnell podaje interesującą statystykę w swojej książce „Software Estimation” (str. 62 Tabela 5.2). Rozróżnia typy projektów (awionika, biznes, telekomunikacja, itp.) I wielkość projektu 10 kLOC, 100 kLOC, 250 kLOC. Liczby podano dla każdej kombinacji w LOC / StaffMonth. EG Avionic: 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) == <2LOC / dzień!


1
250 linii kodu Terra? Co jest nie tak z KLoC?
fadedbee

4

Myślę, że pochodzi to z dni rozwoju wodospadu , w których faktyczna faza rozwoju projektu może wynosić zaledwie 20-30% całkowitego czasu projektu. Weź wszystkie wiersze kodu i podziel je przez cały czas trwania projektu, a otrzymasz około 10 wierszy dziennie. Podziel tylko przez okres kodowania, a zbliżysz się do tego, co ludzie cytują.


3

Nasz kod źródłowy to około 2,2 MLoC na około 150 osobolat wysiłku. To daje około 75 linii C ++ lub C # na programistę dziennie, przez cały okres trwania projektu.


2

Myślę, że wielkość projektu i liczba zaangażowanych programistów to duże czynniki. W mojej karierze jestem daleko ponad tym, ale przez cały ten czas pracowałem sam, więc praca z innymi programistami nic nie kosztuje.


1
Małe projekty pomagają, podobnie jak samotnik. Początkowo byłem zszokowany, widząc, że uderzamy w tę historyczną postać, przynajmniej stopniowo. Na początku tego projektu moja produktywność była co najmniej 10x wyższa.
Matthias Wandel

2

Dobre planowanie, dobry projekt i dobrzy programiści. Dostajesz to wszystko razem i nie poświęcisz 30 minut na napisanie jednej linii. Tak, wszystkie projekty wymagają zatrzymania się i zaplanowania, przemyślenia, omówienia, przetestowania i debugowania, ale przy dwóch liniach dziennie każda firma potrzebowałaby armii, aby tetris działał ...

Podsumowując, jeśli pracowałeś dla mnie z prędkością 2 linii na godzinę, lepiej przynosisz mi dużo kaw i masujesz moje stopy, żebyś nie został zwolniony.


1

Można podejrzewać, że ten odwieczny cukierek menedżerski powstał, gdy wszystko było aplikacją sys napisaną w C, ponieważ magiczna liczba różnił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. I ostatecznie kogo obchodzi liczba napisanych wierszy kodu? Czy powinieneś skończyć, gdy osiągniesz 10 tysięcy linii? 100K? Tak arbitralne.

To jest bezużyteczne.


Jak więc opisujesz wielkość projektu?
Matthias Wandel

1
Jeśli pochodzi z „The Mythical Man-Month”, znacznie wyprzedza C. W tej książce Brooks przyjrzał się idei, że wyjście programisty w wierszach / dzień jest dość stałe, niezależnie od języka, i przypuszczał, że pisanie w bardziej wyrazistym języku (mniej wierszy na jednostkę funkcjonalności) spowoduje, że programiści będą bardziej produktywni. Zdawał sobie sprawę, że liczba ta będzie się znacznie różnić (jego zasadą było, że systemy operacyjne są około 9 razy trudniejsze niż aplikacje).
David Thornley

2
Dyskretne jednostki kodu, punkty łączności (czyli interakcje jednostek), warstwy, klasy (w OOP) ... istnieje około miliona sposobów. KLOC nie są tak naprawdę dobrą miarą inną niż potencjalna jednostka złożoności. (Np. „Debugowanie zajęło 3 tygodnie, ponieważ musiałem przejrzeć 4 KLOCy, aby go znaleźć!”)
John Rudy

2
@David: Wiem, skąd to pochodzi, mogę przeczytać pytanie i właśnie teraz mam tę książkę z przodu na półce przede mną. Co ciekawe, pierwsza opublikowana data również podaje, że jest to post C o 3 lata. Mój punkt widzenia - wyraźnie źle sformułowany - był taki, że jest archaiczny, a ponadto sama koncepcja jest bezużyteczna. Hah! To naprawdę jest biblijne.
annakata

Cóż, mieliśmy wiele punktów łączności i tym podobne. Ale jak to w ogóle liczysz? Kiedy coś staje się punktem łączności? Kiedy zajęcia mają znaczenie? Rozmiar skompilowanego kodu jest prawdopodobnie lepszą miarą w ramach danego systemu i języka, ale różni się w zależności od systemu.
Matthias Wandel
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.