Ile wierszy kodu może wytworzyć programista C # na miesiąc? [Zamknięte]

Kierownik mojego miejsca pracy zadał mi i mojej grupie programistów pytanie:

Ile wierszy kodu może wytworzyć programista C # na miesiąc?

Stary system miał zostać przeniesiony do C # i chciałby, aby ten środek był częścią planowania projektu.

Z jakiegoś (najwyraźniej wiarygodnego) źródła miał odpowiedź „10 SLOC / miesiąc ”, ale nie był z tego zadowolony.

Grupa zgodziła się, że określenie tego było prawie niemożliwe, ponieważ zależałoby to od długiej listy okoliczności. Moglibyśmy jednak stwierdzić, że mężczyzna nie odejdzie (lub nie będzie z nas bardzo rozczarowany), jeśli nie znajdziemy odpowiedzi, która bardziej mu odpowiada. Więc odszedł z wielokrotnie lepszą odpowiedzią „10 SLOC / dzień ”

Czy można odpowiedzieć na to pytanie? (od ręki lub nawet z pewną analizą)

Zapytaj swojego kierownika, ile stron umowy może napisać jego prawnik miesięcznie. Potem (miejmy nadzieję) zda sobie sprawę, że istnieje ogromna różnica między pisaniem kontraktu jednostronicowego a pisaniem kontraktu 300-stronicowego bez luk i sprzeczności. Lub między napisaniem nowej umowy a zmianą istniejącej. Lub między napisaniem nowej umowy a przetłumaczeniem jej na inny język. Lub do innego systemu prawnego. Może nawet zgodzi się, że „strony umowy na jednostkę czasu” nie są zbyt dobrym miernikiem wydajności prawników.

Ale dać jakąś odpowiedź na swoje pytanie rzeczywistym: W moim doświadczeniu, dla nowego projektu kilkaset SLOC dziennie i deweloper nie są rzadkością. Ale gdy tylko pojawią się pierwsze błędy, liczba ta gwałtownie spadnie.

Ile wierszy kodu może wytworzyć programista C # na miesiąc?

Jeśli są dobre, mniej niż zero.

Biegnij w drugą stronę ... Teraz.

LoC jest jednym z najgorszych wskaźników, jakich możesz użyć.

Źli programiści mogą potencjalnie pisać więcej LoC dziennie niż dobrzy programiści, ale rezygnują ze śmieci.

W zależności od złożoności kodu, przenoszenie może odbywać się za pomocą procesów automatyzacji, które skutkowałyby dużymi tysiącami zmian + LoC dziennie, podczas gdy trudniejsze sekcje, w których konstrukcje językowe są zupełnie innym kodem, są przenoszone na 100LoC dziennie.

Wyślij go, aby przeczytał stronę Wikipedii na temat SLOC . Podaje ładne i proste przykłady, dlaczego jest to tak kiepski wskaźnik.

Prawidłowa odpowiedź: nie ...

Kierownictwo to powinno zostać pouczone, że SLOC nie jest prawidłową miarą postępu analizy

Niedbała odpowiedź: dowolny numer, z którego możesz się wymyślić.

Po prostu daj mu numer, a ty i twój zespół możecie łatwo go zwiększyć. (Poprzez umieszczenie linii, pustych linii, komentarzy itp. Itd., Aby ten facet mógł nadal żyć w swoim fantastycznym świecie, nawiedzać kolejną drużynę i kontynuować cykl wzmocniony nędzą, który stanowi historię dla thedailywtf.

Nie miłe, ale wykonalne.

Na pierwszy rzut oka to pytanie wygląda absolutnie głupio i wszyscy tutaj odpowiedzieli tylko na głupią część C # LoC. Ale jest jeden ważny niuans - jest to pytanie o wydajność przenoszenia . Właściwym sposobem na zadanie tego pytania jest pytanie, ile wierszy kodu projektu źródłowego (tego, który jest przenoszony), programista może obsłużyć w danym przedziale czasu. Jest to całkowicie uzasadnione pytanie, ponieważ znana jest całkowita liczba wierszy kodu i jest to dokładnie ilość pracy do wykonania. Właściwym sposobem odpowiedzi na to pytanie jest zebranie trochę danych historycznych - praca, powiedzmy, przez tydzień, i zmierzenie wydajności każdego z programistów.

Mam tylko jedno do powiedzenia:

„Mierzenie postępu programowania za pomocą wierszy kodu jest jak mierzenie postępu budowy samolotu według masy”.

- Bill Gates

Następnie możesz argumentować, że Bill Gates nie wiedział, jak zrobić udane oprogramowanie;)

Uwaga: SLOC jest jednak bardzo dobrą miarą złożoności bazy kodu!

I 
can
write
large
numbers
of
lines
of
code
per
month.

W rzeczywistości proporcjonalna do liczby słów.

Widzisz mój punkt widzenia?

Mogę mieć nieco inne stanowisko w tej sprawie, ale myślę, że rozumiem, dlaczego dyrektor szukał tych informacji, jeśli obecnie planuje projekt. Ponieważ trudno jest oszacować, jak długo zajmie projekt, jedną z zastosowanych metod (patrz: Szacowanie oprogramowania: Demystifying the Black Art ) jest oszacowanie, jak długo zajmie projekt na podstawie liczby SLOC w podobnych projektach, a teraz mogą programiści produkować średnio. W praktyce należy tego dokonać przy użyciu danych historycznych, które grupa ma pod ręką w przypadku podobnych projektów z tymi samymi lub podobnymi programistami.

Jednak nic nie warte jest to, że te szacunki są przeznaczone tylko do podstawowego planowania projektu i nie mają na celu nadania tempa programistom w projekcie, ponieważ rzeczy zmieniają się z dnia na dzień. Tak więc większość z tego, co czytasz przy użyciu SLOCs jako narzędzia szacowania, jest to, że są one dobre na dłuższą metę, jeśli masz już dużą wiedzę, ale kiepskie do codziennego użytku.

Na ogół kiepskim pomysłem jest nazywanie swojego szefa idiotą, więc moje sugestie zaczynają się od zrozumienia i omówienia wskaźników, a nie ich odrzucenia.

Niektóre osoby, które tak naprawdę nie są uważane za idiotów, korzystały z danych opartych na wierszach kodu. Używali ich Fred Brooks, Barry Boehm, Capers Jones, Watts Humphries, Michael Fagan i Steve McConnell. Prawdopodobnie z nich korzystałeś, nawet jeśli tylko powiedzieć koledze, ten moduł Boga ma 4000 linii, należy go podzielić na mniejsze klasy.

Istnieją konkretne dane związane z tym pytaniem ze źródła, które wielu z nas szanuje.

http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html

http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html

http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22

Podejrzewam, że najlepszym zastosowaniem wiersza kodu na godzinę programisty jest pokazanie, że w trakcie trwania projektu wartość ta zacznie się dość wysoko, ale w miarę wykrycia i naprawienia defektów zostaną dodane nowe wiersze kodu w celu rozwiązania problemów, które nie były częścią pierwotnych szacunków, a wiersze kodu usunięte w celu wyeliminowania powielania i poprawy wydajności pokażą, że LOC / hr wskazuje na rzeczy inne niż produktywność.

• Gdy kod zostanie napisany szybko, niechlujnie, nadęty i bez jakiejkolwiek próby refaktoryzacji, pozorna wydajność będzie najwyższa. Morał będzie polegał na tym, że musisz uważać na to, co mierzysz.
• W przypadku konkretnego programisty, jeśli w tym tygodniu dodają lub dotykają dużej ilości kodu, w przyszłym tygodniu może wystąpić techniczny dług związany z przeglądem kodu, testem, debugowaniem i przeróbką.
• Niektórzy programiści będą pracować z bardziej spójną wydajnością niż inni. Może się okazać, że spędzają najwięcej czasu na tworzeniu dobrych historii użytkowników, bardzo szybko się odwracają i przeprowadzają odpowiednie testy jednostkowe, a następnie odwracają się i szybko tworzą kod, który koncentruje się tylko na historiach użytkowników. Problem polega na tym, że metodyczni programiści prawdopodobnie szybko się odwrócą, napiszą kompaktowy kod i będą mieli niewielkie poprawki, ponieważ bardzo dobrze rozumieją problem i rozwiązanie, zanim zaczną kodować. Wydaje się rozsądne, że kodują mniej, ponieważ kodują dopiero po przemyśleniu, zamiast przed i po.
• Gdy kod jest oceniany pod kątem gęstości defektów, okaże się, że jest mniej niż jednolity. Niektóre kody odpowiadają za większość problemów i wad. Będzie kandydatem do przepisania. Kiedy tak się stanie, stanie się najdroższym kodem, ponieważ dzięki temu wysoki stopień przeróbki. Będzie miał najwyższą liczbę wierszy kodu brutto (dodaną, usuniętą, zmodyfikowaną, jak można zgłaszać z narzędzia takiego jak CVS lub SVN), ale najniższą zainwestowaną linię netto kodu na godzinę. Może to być kombinacja kodu albo implementującego najbardziej złożony problem, albo najbardziej skomplikowane rozwiązanie.

Niezależnie od tego, jak okaże się debata na temat produktywności programisty w liniach kodu, przekonasz się, że potrzebujesz więcej siły roboczej, niż możesz sobie pozwolić, a system nigdy nie zostanie ukończony na czas. Wasze prawdziwe narzędzia nie są miernikami. Używają najlepszej metodologii, najlepszych programistów, których możesz zatrudnić lub szkolić, a także kontroli zakresu i ryzyka (prawdopodobnie metodami zwinnymi).

Daj mu lepszą charakterystykę do pracy

Zamiast LOC wyjaśnij, że jest to najgorszy wskaźnik do zastosowania. Następnie daj mu alternatywę:

Liczba funkcji / funkcji według funkcji / żądań funkcji -> NOFF / RFF

Może być konieczne dodanie ważenia / normalizacji oprócz NOFF / RFF, aby uwzględnić liczbę zapytań na tydzień.

:) oczywiście powyższe jest wymyślone, ale wszystko jest lepsze niż SLOC ...

Mogę powiedzieć, że wielu wykonawców dużego projektu napisało 15000 LOC (każdego) w ciągu roku. To niesamowicie trudna odpowiedź, ale była dla nas użyteczna, ponieważ mamy 400 000 istniejących C ++ LoC i mogliśmy dowiedzieć się, że przekształcenie tego wszystkiego w C # zajęłoby nam około 26 osobolat. Daj lub weź.

Więc teraz znamy przybliżony rząd wielkości, możemy lepiej na to zaplanować - zdobycie 20 deweloperów i oszacowanie rocznej pracy dla nich wszystko byłoby w porządku. Przed policzeniem nie mieliśmy pojęcia, ile czasu zajmie migracja.

Więc radzę ci sprawdzić cały kod, który napisałeś w określonym czasie (miałem szczęście, że mam nowy projekt do pracy), a następnie uruchomić na nim jedno z wielu narzędzi metrycznych. Podziel liczbę przez czas, a możesz dać mu dokładną odpowiedź - ile LOC faktycznie piszesz dziennie. Dla nas było to 90 LOC dziennie! Wydaje mi się, że mieliśmy dużo spotkań i dokumentacji na temat tego projektu, ale chyba też będziemy mieli dużo spotkań i dokumentacji na następny :)

Brzmi nieźle.

/programming/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

Jeśli weźmiesz pod uwagę debugowanie, dokumentację, planowanie itp. Średnio jest to około 10 linii kodu dziennie. Właściwie oceniałbym 10 linii dziennie na wysokim poziomie (tj. Bardzo produktywny programista).

Nawet jeśli możesz wydłużyć kilkaset wierszy w ciągu jednego dnia (nie jest to zrównoważone). To nie będzie kod jakości, dopóki nie dodasz całej dokumentacji testu jednostki i oczywiście debugujesz kod po tym, jak test jednostki pokaże błędy. Po tym wszystkim, co zostało zrobione, wróciłeś do 10.

Domyślam się, że programista pracujący w języku takim jak C # powinien móc pisać / generować około 10 000 LoC dziennie. Myślę, że mógłbym to zrobić. Po prostu nigdy bym tego nie zrobił.

To, czego chcesz od programisty, to jego praca w 10 LoC / dzień. Mniej kodu jest zawsze lepsze. Często zaczynam od tworzenia dużej części kodu, a następnie odcinam się, aż osiągam maksimum prostoty, więc faktycznie mam dni z ujemnymi LoC.

W pewnym sensie kodowanie jest jak poezja. Pytanie nie brzmi: ile wierszy może napisać poeta, ale ile może przekazać w 14 wierszach sonetu.

Pozwól swojemu przełożonemu sobie z tym poradzić lub rozpocznij poszukiwanie pracy.

Z całą powagą, możesz poświęcić temu czas, co może skończyć się beznadziejnym wysiłkiem w wyjaśnianiu kierownictwu właściwych i niewłaściwych metod pomiaru postępów projektu w realizacji. W rzeczywistości jednak, po co są inżynierowie i kierownicy projektów.

Z drugiej strony, okoliczności są takie, że pytającym wykonawcą JEST Twój kierownik ds. Inżynierii i / lub projektu. Masz do czynienia ze znacznie większymi i bardziej podstawowymi zagadnieniami, nawet jeśli jeszcze się nie ujawniły. W takim przypadku taki problem może służyć jako „strzał ostrzegawczy” w przypadku większych problemów.

Inne odpowiedzi są poprawne, to głupie pytanie, a odpowiedź nie znaczy nic cholernego. To wszystko prawda, ale zdarza mi się wiedzieć, ile wierszy kodu wygenerowałem w mniej więcej miesiąc.

To około 3000 linii kodu C # bez XML-doc. Wdrażałem nową funkcjonalność i skończyłem z tą kwotą za miesiąc lub miesiąc i tydzień. Wszystko to skończyło się kontrolą źródła, wiele kodu zostało napisane, a następnie refaktoryzowane lub usunięte.

Jestem programistą C # i staram się być w tym dobry, ale nie mogę powiedzieć, jak obiektywnie jestem dobry. Próbowałem napisać dobry kod i włożyłem wiele wysiłku, aby ułatwić jego utrzymanie. W tym kodzie umieszczam komentarze tylko raz lub dwa razy.

Nie wiem, czy to za dużo, czy za mało wierszy kodu i muszę powiedzieć, że tak naprawdę mnie to nie obchodzi. Jest to bezsensowna część danych i nie można jej w żaden sposób bezpiecznie wykorzystać do ekstrapolacji. Ale zdarza mi się, że znam te dane, więc postanowiłem je udostępnić.

Cóż, jak zwykle jestem trochę spóźniony na to przyjęcie, ale to jest naprawdę interesujące. Początkowo myślałem tak samo jak większość, że pytanie dyrektora jest głupie. Przeczytałem jednak odpowiedź SK-logic i zdałem sobie sprawę, że jest to rozsądne pytanie zadane bezsensownie. Lub inaczej mówiąc, za pytaniem kryje się ważny problem.

Menedżerowie często muszą próbować ustalić wykonalność, finansowanie, zatrudnienie itp. Dla projektu. To rozsądny problem. W przypadku portu w prostoford oszacowanie oparte na liniach kodu portu podzielone przez szacunkowe średnie linie kodu na programistę dziennie jest atrakcyjne w prostocie, ale skazane na niepowodzenie ze wszystkich powodów podanych na tej stronie.

Bardziej rozsądnym podejściem byłoby:

1. W celu oszacowania na miejscu zapytaj programistów z największym doświadczeniem w kodzie, aby oszacowali dokładnie, ile to zajmie. Jest to z pewnością niepoprawne z wielu powodów, dla których nie będę tu wchodził, ale jest to najlepsze, co mogą zrobić na początku. Przynajmniej powinni mieć pomysł, czy będzie to łatwe w ciągu tygodnia, czy lat, nawet przy dodatkowych zasobach. Jeśli wykonano porty lub inne prace o podobnej wielkości, mogą to wykorzystać jako przewodnik.
2. Oszacuj port według komponentu, aby uzyskać całkowity rozmiar. Należy uwzględnić zadania niezwiązane bezpośrednio z portem, takie jak konfiguracja infrastruktury (maszyny, systemy kompilacji itp.), Badanie i zakup oprogramowania itp.
3. Zidentyfikuj najbardziej ryzykowne elementy portu i zacznij od nich. Te prognozy najprawdopodobniej spowodują największe straty, więc należy to zrobić z góry, jeśli to możliwe, aby późno w porcie było niewiele niespodzianek.
4. Śledź postępy względem zmiany wielkości wykonanej w kroku 2, aby stale obliczać oczekiwany czas trwania portu. W miarę postępu projektu powinno to stać się dokładniejsze. Oczywiście liczba wierszy kodu, które zostały przeniesione (funkcje oryginalnej bazy kodu, które są teraz w przeniesionym kodzie), może być również wykorzystana jako metryka i jest faktycznie pomocna w zapewnieniu, że oryginalny produkt jest przenoszony, a nie dodano kilka świetnych nowych funkcji, nie zajmując się rzeczywistym portem.

Byłyby to kroki od podstaw, oczywiście istnieje wiele innych działań wokół tego, które są pomocne, takie jak badanie narzędzi do portowania i wtykowych ram, tworzenie prototypów, określanie, co naprawdę musi zostać przeniesione, ponowne wykorzystywanie narzędzi testowych i infrastruktury itp.