it-swarm-eu.dev

Co dělá projekt velkým?

Jen ze zvědavosti, jaký je rozdíl mezi malým, středním a velkým projektem? Měří se řádky kódu nebo složitosti nebo co?

Buduji výměnný systém a zatím mám asi 1000 řádků kódu pro přihlášení/registraci. I když existuje spousta LOC, nepovažoval bych to za velký projekt, protože není složitý, i když je to můj první projekt, takže si nejsem jistý. Jak se měří?

32
Jonathan

Složitost.

Čím složitější, tím těžší je naučit se vše v projektu.

20
user1249

Zhruba to, jak bych věci souhlasil - mějte na paměti, že je to víceméně svévolné. „Velikost“ projektu v kombinaci s dalšími faktory, jako je složitost, zdrojové řádky kódu, počet funkcí/obchodní hodnota atd. Velmi malý produkt může přinést velké množství hodnoty atd. Říká se:

  • 2m + sloc je velký až obrovský projekt. Jsou obecně tak složité, že jen málo lidí, pokud někteří lidé mluví „plynule“ v celém systému; spíše odpovědnost má tendenci být modularizována podél struktury kódu. Tyto projekty často přinášejí obrovskou obchodní hodnotu a mohou být kritické. Někdy jsou také vystaveni velkému tlaku technických dluhů a dalších starostí.

  • 100k - 2m sloc je středně velký projekt. To je moje střední fáze: projekt je dostatečně komplexní, aby vyžadoval určité odborné znalosti, a pravděpodobně získal určitou míru technického dluhu; pravděpodobně také přináší určitou míru obchodní hodnoty.

  • 10k - 100k je malý projekt, ale ne příliš malý na to, aby měl dost složitosti, že budete chtít odbornou úvahu; Pokud máte otevřený zdroj, zvažte, zda si lidé, kterým důvěřujete, zkontrolují vaše závazky.

  • Něco menšího než 10k sloku je opravdu malé. To neznamená, že to nemůže přinést žádnou hodnotu, a mnoho velmi zajímavých projektů má velmi malý otisk (např. Camping, jehož zdroj je ~ 2 kb (!)). Non-odborníci mohou obecně řídit hodnoty obavy - opravit chyby a přidávat funkce - aniž by museli vědět příliš mnoho o doméně.

34
Joseph Weissman

Velikost projektu se měří podle míry neudržitelnosti.

14
mojuba

Složitost, kterou lze odhadnout několika způsoby:

  1. Rozpočet. Projekt s rozpočtem 10 000 000 + + se pravděpodobně docela liší od projektu, který je například pod 10 000 $. To může zahrnovat náklady na práci, software, hardware a další náklady vynaložené při provádění projektu.
  2. Osoba hodin práce na dokončení projektu. Bude to trvat milion hodin nebo něco jiného? To lze také považovat za faktor časové osy, kdy některé projekty mohou trvat roky, což bych řekl, že byly velké ve srovnání s jinými, které mohou trvat méně než týden. Uvědomte si, že pracovní doba člověka může být zavádějící, protože si někdo může myslet zdvojnásobením počtu zaměstnanců, takže na projektu pracuje dvakrát tolik, pak lze rozvrh rozdělit na polovinu, což mi zřídkakdy pomůže.
  3. Množství hardwaru, dalších systémů a lidí využívajících to, co projekt staví. Pokud se něco váže na 101 systémů, pak je pravděpodobné, že bude složitější, že pokud bude stát sám a nebude se k ničemu vázat.

I když požadavky mohou znít jako pěkný způsob, jak to měřit, často existuje více požadavků, které budou nalezeny, protože se projekt provádí za předpokladu, že se domnívám, že jde o metodiku bez vodopádu.

12
JB King

Velikost projektu se pravděpodobně nejlépe měří podle počtu požadavků systému, kde požadavky nelze dále snížit.

Více požadavků většinou samozřejmě znamená složitější, ale není tomu tak vždy.

11
David_001

Změřil bych velikost projektu podle toho, jak obtížné je vidět celý projekt jako jeden velký obrázek. Mám například průzkumnou/prototypovou kódovou základnu pro problém strojového učení, na kterém pracuji. Je to jen 5 000 řádků kódu, ale je to jako velký projekt. Existuje spousta možností konfigurace, které interagují nepředvídatelným způsobem. Můžete najít téměř každý návrhový vzor, ​​o kterém člověk ví, že je někde v kódové základně, a spravovat takovou složitost. Design je často suboptimální, protože věc evolucí hodně rostla a není refaktorizována tak často, jak by měla být. Jsem jediný, kdo pracuje na této kódové základně, ale často mě překvapuje, jak věci interagují.

Na druhé straně, jeden z mých hobby projektů má asi 3-4x tolik kódu, a přesto se cítí mnohem menší, protože je to v zásadě knihovna matematických funkcí, které jsou většinou vzájemně ortogonální. Věci nekomunikují komplexně a je docela rozumné pochopit každou funkci izolovaně. Je snadné vidět velký obraz do té míry, že existuje, protože není toho moc vidět.

4
dsimcha

Libovolná odpověď: Jak velký je projekt, kolik si přejete, abyste to udělali pomocí zdrojů událostí a SOA od začátku.) Nebo že autoři systému přečetli Evanovu knihu „DDD: Tackling Složitost v srdci softwaru “;)

3
Henrik

Kompatibilita a rozsah

Složitost a rozsah Věřím, že to, co určuje, jak velký je projekt opravdu. Existuje však několik nehmotných aktiv, které mohou ovlivnit i velikost projektu.

Požadavky

Největším pádem, kterému jsem čelil, byl nedostatek požadavků. V mé konkrétní situaci vedoucí prodeje určoval požadavky. Soustředil se na prodej ... musí dostat prodej. V jeho mysli se to, co zákazník požadoval, nezdálo až tak složité, protože jsme postavili něco podobného. Vague požadavky vedou k podhodnoceným pracovním místům a nadměrným očekáváním.

Nedostatek CCMU

CCMU je to, čemu říkám "Coo Ca Moo" (Vymazat úplné vzájemné porozumění). Musíte mít CCMU se svým zákazníkem.

Pokud máte malý projekt se špatnou CCMU, můžete ukončit projekt 2,3,4 nebo vícekrát. Jednoduchá 20hodinová práce se tak promění v 60hodinový projekt s vystresovaným personálem a velmi nespokojeným zákazníkem.

Rozsah Creep

To se děje častěji, než si myslíte. Zákazník se rozhodne, že jelikož již děláte A, B & C, nemělo by být tak obtížné přidat D nebo dokonce F. Pokud toto chování není zaškrtnuto, může také malý projekt změnit na středně velký projekt. A v závislosti na tom, jak vedoucí prodeje prodal zakázku, se tato očekávání dotažení rozsahu mohou zdát "ZDARMA" zákazníkovi.

Je to zvláštní, když jsem četl spoustu těchto odpovědí, zjistil jsem, že vidím velikost projektu velmi odlišně. Možná je to moje práce ve velké korporaci, ale já mám sklon vnímat velikost projektu jako měřítko jeho viditelnosti/vhodnosti pro své klienty (v závislosti na vaší oblasti práce to mohou být spolupracovníci nebo skuteční platící zákazníci).

1
Kavet Kerek

Složitost je správná odpověď, ale jak ji odhadnout?

Faktory jsou:

  1. Počet bodů rozšíření
  2. Počet vrstev modulů (funkce, třídy, systémy tříd, knihovny, sdílené knihovny, aplikace, síťové aplikace atd.)
  3. Počet závislostí (včetně platforem)
  4. Počet vzájemných závislostí funkcí.
  5. Nezbytné prostředky bez kódu (včetně grafiky/umění, skriptů pro řízení - jako jsou skripty pro návrh úrovně - a další zdroje potřebné k dokončení verze aplikace).

Čím více z nich máte, tím složitější je projekt.

1
Klaim

LOC je notoricky nepřesná pro mnoho měření, ale myslím, že se snažíte změřit něco, co opravdu není přesný způsob měření. Možná alternativou může být cyklomatická složitost .

Nakonec si ale myslím, že „bigness“ projektu je obtížné kvantifikovat. Je to skoro jako ptát se, jak zjistíte, zda je pes velký nebo ne. Nejenže existuje několik způsobů, jak to změřit (hmotnost, objem atd.), Ale já osobně to nepovažuji za velmi užitečné. Realita je taková, že moje kritéria budou pravděpodobně něco podobného: „Jak je pravděpodobné, že od tohoto psa uteču, když to uvidím v temné uličce?“

A pokud jde o záznam, obecně bych nepovažoval 1k řádek kódu za hodně. Byl by to značný kus kódu, ale nebylo to , které tolik ve velkém schématu věcí. Samozřejmě si myslím, že to záleží na jazyce. Například 1k řádků kódu je mnohem méně kódem v jazyce jako C, než v jazyce jako Pyhon.

0
Jason Baker