it-swarm-eu.dev

Kolik řádků kódu může vývojář C # vyrobit za měsíc?

Vedoucí pracovník na mém pracovišti se mě a mé skupiny vývojářů zeptal na otázku:

Kolik řádků kódu může vývojář C # vyrobit za měsíc?

Starý systém měl být přenesen na C # a chtěl by toto opatření jako součást plánování projektu.

Z nějakého (očividně důvěryhodného) zdroje měl odpověď „10 SLOC/měsíc“, ale s tím nebyl spokojený.

Skupina souhlasila s tím, že to bylo téměř nemožné specifikovat, protože by to záleželo na dlouhém seznamu okolností. Ale mohli bychom říct, že ten muž neopustí (nebo nebude v nás velmi zklamaný), pokud jsme nepřišli s odpovědí, která by mu lépe vyhovovala. Takže odešel s mnohokrát lepší odpovědí „10 SLOC/den

Lze na tuto otázku odpovědět? (offhand nebo dokonce s nějakou analýzou)

21
lox

Zeptejte se svého manažera, kolik smluvních stran může jeho právník napsat měsíčně. Pak (doufejme) si uvědomí, že existuje obrovský rozdíl mezi uzavřením jednostránkové smlouvy a uzavřením 300stránkové smlouvy bez mezer a rozporů. Nebo mezi uzavřením nové smlouvy a změnou stávající smlouvy. Nebo mezi uzavřením nové smlouvy a překladem do jiného jazyka. Nebo do jiného právního systému. Možná bude dokonce souhlasit s tím, že „smluvní strany za jednotku času“ nejsou velmi dobrým měřítkem produktivity právníka.

Ale abych vám dal někteří odpověď na vaši skutečnou otázku: Podle mých zkušeností není několik set SLOC za den a vývojář neobvyklých. Jakmile se však objeví první chyby, toto číslo prudce poklesne.

84
nikie

Kolik řádků kódu může vývojář C # vyrobit za měsíc?

Pokud jsou dobré, méně než nula.

33
quentin-starin

Běh opačným způsobem ... Teď.

LoC je jednou z nejhorších metrik, které můžete použít.

Špatní vývojáři mohou potenciálně psát více LoC denně než dobří vývojáři, ale vydávají nesmyslný kód.

V závislosti na složitosti kódu může být přenos prováděn automatizačními procesy, které by měly za následek velké tisíce + změny LoC denně, zatímco obtížnější sekce, kde jsou jazykové konstrukty divoce odlišným kódem, budou přeneseny při 100 ° C denně.

Pošlete ho, aby si přečetl stránku Wikipedie na SLOC . Pokud uvede několik pěkných a jednoduchých příkladů, proč je tak špatná metrika.

21
Dan McGrath

Správná odpověď: Ne ...

Tento vedoucí pracovník by měl být poučen o tom, že SLOC není platnou metrikou pro postup analýzy

Sloppy Answer: Jakékoli číslo, ze kterého si můžete vytvořit.

Jen mu dejte nějaké číslo, vy a váš tým můžete snadno číslo navýšit. (Vložením řádků, prázdných řádků, komentářů atd., Jen aby tenhle chlap mohl žít ve svém fantazijním světě a pronásledovat další tým a pokračovat v utrpení posíleném cyklu, díky němuž se příběh stane příběhem.

Ne pěkné, ale schopné.

18
Zekta Chan

Od prvního pohledu vypadá tato otázka naprosto hloupě a všichni zde odpovídali na hloupou část C # LoC. Existuje však jedna důležitá nuance - je to otázka výkonu portování. Správný způsob, jak se zeptat na tuto otázku, je zeptat se, kolik řádků kódu zdrojového projektu (ten, který je přenesen) může vývojář zpracovat v dané časové jednotce. Je to naprosto odůvodněná otázka, protože je znám celkový počet řádků kódu a přesně to je množství práce, kterou je třeba udělat. A správný způsob, jak odpovědět na toto spalování, je sbírat trochu historických dat - pracovat, řekněme, za týden, a měřit výkon každého z vývojářů.

10
SK-logic

Mám jen jednu věc:

"Měření postupu programování pomocí řádků kódu je jako měření hmotnosti budovy v letadle."

-- Bill Gates

Poté můžete tvrdit, že Bill Gates nevěděl, jak vytvořit úspěšný software;)

Poznámka: SLOC je velmi dobrá míra složitosti kódu a základny!

7
Matthieu M.
I 
can
write
large
numbers
of
lines
of
code
per
month.

Ve skutečnosti je úměrný počtu slov.

Vidíš můj názor?

5
JBRWilkinson

Obecně je špatný nápad nazývat svého šéfa idiotem, takže moje návrhy začínají chápáním a diskutováním metrik, nikoli jejich odmítáním.

Někteří lidé, kteří ve skutečnosti nejsou považováni za idioty, použili metriky založené na řádcích kódu. Fred Brooks, Barry Boehm, Capers Jones, Watts Humphries, Michael Fagan a Steve McConnell je používali. Pravděpodobně jste je použili, i když jen na to, abyste řekli kolegovi, tento modul Bůh má 4000 řádků, je třeba jej rozdělit do menších tříd.

S touto otázkou existují konkrétní údaje ze zdroje, který mnozí z nás respektují.

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

Mám podezření, že nejlepším využitím řádku kódu za hodinu programátora je ukázat, že po celou dobu trvání projektu bude tato hodnota dost vysoká, ale jak budou zjištěny a opraveny závady, budou přidány nové řádky kódu pro řešení problémů, které nebyly součástí původních odhadů a řádky kódu odstraněné, aby se odstranila duplicita a zvýšila se účinnost, ukáže, že LOC/h označuje věci jiné než produktivitu.

  • Když je kód psán rychle, nedbalý, nafouklý a bez jakéhokoli pokusu o refactorování, bude zřejmá účinnost nejvyšší. Morální zde bude, že musíte být opatrní, co měříte.
  • Pro konkrétního vývojáře, pokud tento týden přidávají nebo se dotýkají velkého množství kódu, může příští týden existovat technický dluh, který bude muset zaplatit z hlediska kontroly kódu, testování, ladění a přepracování.
  • Někteří vývojáři budou pracovat konzistentněji než ostatní. Může být zjištěno, že tráví nejvíce času získáváním dobrých uživatelských příběhů, velmi rychle se obracejí a provádějí odpovídající testy jednotek, a pak se obracejí a rychle vytvářejí kód, který je zaměřen pouze na uživatelské příběhy. Zde je třeba vzít v úvahu, že metodičtí vývojáři se pravděpodobně budou rychle obracet, budou psát kompaktní kód a budou mít málo přepracování, protože dobře pochopí problém a řešení dříve, než začnou kódovat. Zdá se rozumné, že budou kódovat méně, protože kódují až poté, co si to promyslí, místo před a po.
  • Když je kód vyhodnocen z hlediska jeho hustoty defektů, bude zjištěno, že je méně než jednotný. Nějaký kód bude odpovídat za většinu problémů a vad. Bude to kandidát na přepis. Když k tomu dojde, stane se nejdražším kódem, protože díky němu je vysoký stupeň přepracování. Bude mít nejvyšší hrubé řádky počtů kódů (přidané, smazané, upravené, jak by mohly být hlášeny z nástroje jako CVS nebo SVN), ale nejnižší čisté řádky kódu za investovanou hodinu. To může nakonec být kombinací kódu buď implementace nejsložitější problém nebo nejsložitější řešení.

Bez ohledu na to, jak se ukáže debata o produktivitě programátora v řádcích kódu, zjistíte, že potřebujete více lidské síly, než si můžete dovolit, a systém nikdy nebude dokončen včas. Ty skutečné nástroje nejsou metriky. Používají špičkovou metodiku, nejlepší vývojáře, které si můžete najmout nebo trénovat, a kontrolu nad rozsahem a riziky (pravděpodobně pomocí agilních metod).

4
DeveloperDon

Možná k tomu budu mít trochu odlišný postoj, ale myslím, že chápu, proč výkonná agentura hledala tyto informace, pokud v současné době plánují projekt. Protože je těžké odhadnout, jak dlouho bude projekt trvat, je jednou z metod, která se používá (viz: Odhad softwaru: Demystifikování černého umění ), odhadnout, jak dlouho bude projekt trvat. na základě počtu SLOC v podobných projektech a nyní mohou vývojáři vyrábět v průměru. V praxi je to zamýšleno pomocí historických záznamů, které má skupina po ruce pro podobné projekty se stejnými nebo podobnými vývojáři.

Nic však nestojí za to, že tyto odhady jsou určeny pouze pro základní plánování projektu a ve skutečnosti nejsou určeny k tomu, aby nastavily tempo vývojářů na projektu, protože se věci mění ze dne na den. Většinu toho, co čtete o používání SLOC jako nástroje pro odhad, je, že jsou dlouhodobě dobré, pokud již máte dobré znalosti, ale jsou pro každodenní použití mizerné.

4
rjzii

Mohu vám říci, že množství dodavatelů pro velký projekt napsal za rok 15 000 LOC (každý). To je neuvěřitelně drsná odpověď, ale bylo to pro nás užitečné, protože máme 400 000 existujících C++ LoC a mohli jsme přijít na to, že převedení na C # by nám trvalo asi 26 mužských let. Dej nebo vezmi.

Takže nyní známe hrubý řád velikosti, můžeme na to lépe naplánovat - dostat 20 devs a odhadnout roční práci pro ně by bylo všechno v pořádku. Před započtením jsme nevěděli, jak dlouho bude migrace trvat.

Takže moje rada pro vás je zkontrolovat celý kód, který jste napsali, ve specifickém množství času (měl jsem štěstí, že jsem měl nový projekt, se kterým jsem pracoval), a pak na něm spusťte jeden z mnoha nástrojů metriky kódu. Vydělte číslo časem a můžete mu dát přesnou odpověď - kolik LOC ve skutečnosti píšete za den. Pro nás to vyšlo na 90 LOC denně! Myslím, že jsme na tomto projektu měli spoustu schůzek a dokumentace, ale pak myslím, že na příští schůzce budeme mít spoustu schůzek a dokumentace :)

3
gbjbaanb

Dej mu lepší metriku, s níž bude pracovat

Místo LOC vysvětlete, že je to = nejhorší metrika, kterou chcete použít. Pak mu dejte alternativu:

Počet funkcí/funkcí za Požadavky na funkce/funkce -> NOFF/RFF

Možná budete muset přidat vážení/normalizaci nad NOFF/RFF, abyste uspokojili množství požadavků týdně.

:) jasně výše uvedené je vytvořeno, ale cokoli, je lepší než SLOC ...

3
Darknight

Zní to správně.

https://stackoverflow.com/questions/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

Pokud vezmete v úvahu ladění, dokumentaci, plánování atd. Průměrně se pohybuje kolem 10 řádků kódu denně. Vlastně bych hodnotil 10 řádků denně na vysoké straně (tj. Velmi produktivní dev).

Přestože můžete za jeden den vypálit několik stovek řádků (není to udržitelné). Nemělo by to být kód kvality, dokud nepřidáte celou dokumentaci k testování jednotky a samozřejmě neodstraníte kód poté, co test jednotky ukáže chyby. Po tom všem, co se stalo, jste zpět na 10.

2
Martin York

Ostatní odpovědi jsou správné, je to hloupá otázka a odpověď neznamená zatracenou věc. Je to všechno pravda, ale náhodou vím, kolik řádků kódu jsem vyrobil zhruba za měsíc.

Je to asi 3 000 řádků kódu C # bez XML-doc. Implementoval jsem nové funkce a skončil jsem s touto částkou za měsíc, měsíc a týden. Je to všechno, co skončilo v ovládání zdroje, bylo napsáno mnoho kódu a poté refactored nebo vymazáno.

Jsem C # vývojář a snažím se být v tom dobrý, ale nemohu vám říct, jak objektivně dobrý jsem. Snažil jsem se napsat dobrý kód a vynaložit velké úsilí, aby bylo snadné jej udržovat. Do tohoto kódu jsem vložil komentáře pouze jednou nebo dvakrát.

Nevím, jestli je to příliš mnoho nebo příliš málo řádků kódu a musím říci, že mi to opravdu nezáleží. Je to nesmyslná část dat a nelze ji nijak bezpečně použít k extrapolaci. Ale náhodou tyto údaje znám, takže jsem se rozhodl je sdílet.

1
Dyppl

Nechte svého manažera, ať to zvládne, nebo začněte hledat práci.

Se vší vážností byste mohli strávit čas tím, co by se mohlo stát beznadějnou snahou vysvětlit exekutivě správné a nevhodné metody měření pokroku projektu k dokončení. Ve všech skutečnostech však pro co jsou inženýři a projektoví manažeři.

Na druhé straně jsou okolnosti takové, že výkonný pracovník JE váš inženýr a/nebo projektový manažer. Máte mnohem větší a základní problémy, se kterými se musíte vypořádat, i když se ještě neodhalili. V takovém případě může takový problém sloužit jako „varovný výstřel“ pro větší problémy.

1
mummey

Myslím, že vývojář pracující s jazykem jako C # by měl být schopen psát/generovat asi 10 000 LoC/den. Myslím, že bych to mohl udělat. Jen jsem nikdy ne.

Co od vývojáře chcete, je, aby svou práci provedl za 10 LoC/den. Méně kódu je vždy lepší. Často krát začnu vyrábět velké množství kódu a potom se odříznu, dokud nedosáhnu holého maxima jednoduchosti, takže ve skutečnosti mám dny se zápornými LoC.

V jistém smyslu je kódování jako poezie. Otázkou není, kolik řádků může básník psát, ale kolik dokáže sdělit ve 14 řádcích sonetu.

1
back2dos

No, na tuto párty jsem trochu pozdě, ale to je vlastně zajímavé. Zpočátku jsem měl stejnou myšlenku jako většina, že výkonná otázka je těžká. Četl jsem však odpověď SK-logiky a uvědomil jsem si, že se jedná o rozumnou otázku položenou nesmyslně. Nebo, jinak řečeno, za otázkou je platný problém.

Manažeři se často musí snažit určit proveditelnost, financování, personální zajištění atd. Pro projekt. To je rozumný problém. Pro přímý port je odhad založený na řádcích kódu portu dělený odhadovaným průměrem řádků kódu na vývojáře za den přitažlivý v jednoduchosti, ale odsouzen k selhání ze všech důvodů uvedených na této stránce.

Rozumnější přístup by byl: -

  1. Pro odhad na místě požádejte vývojáře, kteří mají s kódem nejvíce zkušeností, odhad střeva, jak dlouho to bude trvat. To musí být nesprávné z mnoha důvodů, do kterých sem nepůjdu, ale je to nejlepší, co budou moci udělat hned na začátku. Přinejmenším by měli mít představu, zda to bude snadné udělat za týden nebo roky, a to i s dalšími zdroji. Pokud již byly provedeny nějaké podobné velikosti portů nebo kusů práce, mohly by to použít jako průvodce.
  2. Odhadněte port podle komponenty a získejte celkovou velikost. Je třeba zahrnout úkoly, které přímo nesouvisejí s portem, jako je nastavení infrastruktury (stroje, systémy sestavování atd.), Vyšetřování a nákup softwaru atd.
  3. Identifikujte nejrizikovější komponenty portu a začněte nejprve s těmi. Je pravděpodobné, že odhady vyhodí nejvíce, takže pokud je to možné, měly by být provedeny předem, aby v přístavu byla překvapení omezená.
  4. Sledujte pokrok oproti dimenzování provedenému v kroku 2, abyste mohli průběžně vypočítávat očekávanou dobu trvání portu. Jak se projekt posouvá dopředu, mělo by to být přesnější. Počet řádků kódu, které byly přeneseny (funkce v původní kódové základně, které jsou nyní v přeneseném kódu), lze samozřejmě také použít jako metriku a je skutečně užitečné zajistit, aby byl původní produkt přenášen spíše než přidává se řada skvělých nových funkcí, aniž by se řešil skutečný port.

Byly by to kroky holých kostí, samozřejmě existuje mnoho dalších aktivit, které jsou užitečné, jako je zkoumání nástrojů pro přenos portů a zásuvných rámců, vytváření prototypů, určování toho, co skutečně potřebuje být přeneseno, opětovné použití testovacích nástrojů a infrastruktury atd.

0
acarlon