Cosa rende grande un progetto? [chiuso]

32

Solo per curiosità qual è la differenza tra un progetto di piccole, medie e grandi dimensioni? È misurato da righe di codice o complessità o cosa?

Sto costruendo un sistema di baratto e finora ho circa 1000 righe di codice per il login / registrazione. Anche se c'è un sacco di LOC, non lo considero un grande progetto perché non è così complesso, anche se questo è il mio primo progetto, quindi non ne sono sicuro. Come viene misurato?

project

— Jonathan
fonte

2

Sì ............ Più complessità significa più righe di codice.

— Robert Harvey,

3

Il primo KLOC è il più difficile ...

Successivamente devi chiedere "Cosa rende complesso un progetto? Linee di codice? Strati di astrazione?"

— Steven Evers,

Citi 1.000 righe di codice come "lotto". Questo in realtà non significa nulla senza contesto. Ho lavorato su diversi progetti con oltre un milione di righe di codice. Ho anche lavorato su quelli che definirei "piccoli" progetti che hanno solo 50.000 righe o giù di lì, ma a causa della complessità non sarebbero considerati "piccoli" a causa della quantità di risorse necessarie per progettare, codificare, e prova. Ma nella mia esperienza personale, non riesco a pensare ad alcun caso in cui considererei molte righe 1.000. Lo dico solo per fornire una prospettiva al tuo progetto di pugno. In bocca al lupo!

— TMarshall,

Direi che "la grandezza" di un progetto dipende da più di 1 fattore ...

— kiwixz,

20

Complessità.

Maggiore è la complessità, più difficile è imparare tutto nel progetto.

5

È simile a un imo tautologico. Un sistema complesso è sinonimo di sistema di grandi dimensioni; a meno che non si parli di complessità del codice e quindi potrebbe anche essere così che tutto sia ben disaccoppiato e abbia una sola responsabilità, nel qual caso la complessità del codice potrebbe effettivamente essere inferiore per progetti di grandi dimensioni. Quindi, dire che la complessità significa che il progetto è grande non significa davvero nulla.

— Henrik,

... o naturalmente qualsiasi altra misura di complessità.

— Henrik,

@Henrik, "sistema complesso" non equivale a "sistema grande".

1

No, è sinonimo.

— Henrik,

@Henrik, non sono d'accordo. Un sistema può essere grande ma regolare - vale a dire che molte cose vengono risolte quasi nello stesso modo, in cui è possibile prevedere in che modo vengono eseguite in base alla propria esperienza con il resto del sistema - e un sistema può essere piccolo ma comunque molto complesso.

34

All'incirca come accorderei le cose - tieni presente che questo è più o meno arbitrario. La "dimensione" del progetto in un insieme di altri fattori come complessità, linee di codice sorgente, numero di caratteristiche / valore aziendale, ecc. Un prodotto molto piccolo può fornire una grande quantità di valore, ecc. Detto questo:

2m + sloc è un progetto da grande a enorme. Questi sono generalmente così complessi che poche persone sono "fluenti" nell'intero sistema; piuttosto la responsabilità tende ad essere modulare lungo la struttura del codice. Questi progetti offrono spesso un enorme valore commerciale e possono essere mission-critical. A volte sono anche sottoposti a una forte tensione del debito tecnico e ad altre preoccupazioni legate all'eredità.
100k - 2m sloc è un progetto di medie dimensioni. Questa è la mia via di mezzo: il progetto è abbastanza complesso da richiedere alcune conoscenze specialistiche e ha probabilmente accumulato un certo grado di debito tecnico; probabilmente fornisce anche un certo grado di valore commerciale.
10k - 100k è un piccolo progetto, ma non troppo piccolo per avere una complessità sufficiente da richiedere la valutazione di un esperto; se sei open source, considera di convincere le persone di cui ti fidi a rivedere i tuoi impegni.
Qualsiasi cosa con meno di 10k sloc è davvero piccola. Ciò non significa che non possa fornire alcun valore, e molti progetti molto interessanti hanno un'impronta molto piccola (ad esempio Camping, la cui fonte è ~ 2 kb (!)). I non esperti in genere possono generare problemi di valore - correggere bug e aggiungere funzionalità - senza dover conoscere troppo il dominio.

— Joseph Weissman
fonte

4

Voterei due volte questo voto se potessi. I numeri sono in qualche modo arbitrari, ovviamente, ma penso che le descrizioni di ciò che implicano diversi gradi di "grandezza" siano esatte.

— Eric Anderson,

1

@EricAnderson È sicuramente più facile pensarlo in termini di descrizioni che di misura di sloc. Un programma Erlang da 100k sloc è facilmente un ordine di grandezza "più grande" di un programma C ++ da 100k sloc, basato semplicemente su ciò che fa indipendentemente da quanto sia facile leggere il codice a un livello superiore. A un certo punto leggere il codice non è nemmeno così difficile come solo ricordare cosa sta succedendo all'interno del sistema ad alto livello perché ci sono così tante funzionalità e centri logici.

— zxq9,

@ zxq9 Non sono d'accordo. È vero, ciò implica che la scelta della lingua potrebbe rendere più piccolo un grande progetto. Ciò che era usato dai grandi computer ora è troppo lento e ciò che era usato dai grandi progetti software può essere banale al giorno d'oggi. Ciò che è invariante è il costo / la complessità di un progetto. Sebbene SLOC non sia una misura perfetta, è ancora strettamente correlato al costo e alla complessità di un progetto software. — Proprio come le grandi macchine non sono necessariamente migliori, neanche i grandi progetti software. Se possibile, suddividere un progetto in componenti indipendenti e scegliere le tecnologie giuste per renderle ancora più piccole.

— Yongwei Wu,

14

Le dimensioni di un progetto sono misurate dal grado di non mantenibilità.

— mojuba
fonte

2

È pessimista: D

— Henrik,

.... e che misura è?

— Casey Patton,

1

@Casey Patton la misurazione è letteralmente il costo di manutenzione.

— Mojuba,

12

Complessità che può essere stimata in alcuni modi:

Budget. Un progetto con un budget di oltre $ 10.000.000 è probabilmente molto diverso da uno con meno di $ 10.000 per esempio. Ciò può includere manodopera, software, hardware e altri costi sostenuti nella realizzazione di un progetto.
Persona ore di lavoro per completare il progetto. Ci vorranno un milione di ore o qualcos'altro? Questo potrebbe anche essere visto come un fattore temporale in cui alcuni progetti potrebbero richiedere anni che direi essere grandi rispetto ad altri che potrebbero richiedere meno di una settimana. Si noti che le ore della persona possono essere fuorvianti come qualcuno potrebbe pensare raddoppiando il personale, quindi ci sono due volte più che lavorano al progetto, quindi il programma può essere suddiviso a metà, cosa che raramente avrebbe funzionato nella mia mente.
Quantità di hardware, altri sistemi e persone che utilizzano ciò che il progetto sta costruendo. Se qualcosa si lega a 101 sistemi, è probabile che sia più complicato che se si trova da solo e non si lega ad altro.

Mentre i requisiti possono sembrare un buon modo per misurarlo, spesso ci sono più requisiti che verranno trovati man mano che un progetto viene realizzato assumendo una metodologia non a cascata, credo.

— JB King
fonte

11

Una dimensione del progetto è probabilmente meglio misurata dal numero di requisiti del sistema, dove i requisiti non possono essere ulteriormente ridotti.

Certo, più requisiti significano principalmente più complessità, ma non è sempre così.

— David_001
fonte

1

Potrebbe non essere una buona misura: i requisiti per compilatori e kernel del sistema operativo possono essere sproporzionatamente grandi rispetto ad altri tipi di prodotti.

— Mojuba,

2

@mojuba: "Big" è un termine piuttosto ampio, immagino che scrivere un compilatore o un sistema operativo sia un progetto "grande"

— David_001

@ David_001: prendi il compilatore Turbo Pascal, f.ex., la cui dimensione binaria a un certo punto era di 70 kilobyte e tuttavia TP era un linguaggio di programmazione orientato agli oggetti in piena regola. Non abbiamo mai visto le fonti ma un eseguibile da 70kb non può essere un grande progetto.

— Mojuba,

@ David_001: non che io non sia completamente d'accordo con te in generale. Qualsiasi definizione di un "grande" progetto sarà vaga quanto la parola "grande" stessa.

— Mojuba,

@mojuba: Quando ho usato Turbo Pascal, non era affatto orientato agli oggetti.

— David Thornley,

4

Misurerei le dimensioni di un progetto in base a quanto sia difficile vedere l'intero progetto come un'unica grande immagine. Ad esempio, ho una base di codice esplorativa / di prototipazione per un problema di apprendimento automatico su cui sto lavorando. Sono solo 5k righe di codice, ma sembra un progetto enorme. Ci sono tonnellate di opzioni di configurazione che interagiscono in modi imprevedibili. Puoi trovare praticamente tutti i modelli di progettazione conosciuti dall'uomo da qualche parte nella base di codice per gestire tutta quella complessità. Il design è spesso non ottimale perché la cosa è cresciuta molto per evoluzione e non viene riformattata tutte le volte che dovrebbe essere. Sono l'unico che funziona su questa base di codice, eppure sono spesso sorpreso da come le cose interagiscono.

D'altra parte, uno dei miei progetti di hobby ha circa 3-4 volte più codice, eppure sembra molto più piccolo perché è fondamentalmente una libreria di funzioni matematiche che sono per lo più ortogonali tra loro. Le cose non interagiscono in modo complesso, ed è carino capire ogni funzione isolatamente. È facile vedere il quadro generale nella misura in cui ce n'è uno, perché non ce n'è molto da vedere.

— dsimcha
fonte

3

Risposta arbitraria: quanto è grande il progetto quanto desideri averlo fatto con l'approvvigionamento di eventi e la SOA sin dall'inizio. O che gli autori del sistema avevano letto il libro di Evan "DDD: Affrontare la complessità nel cuore del software";)

— Henrik
fonte

2

Complicità e ambito di applicazione

Complessità e ambito Credo che siano ciò che determina la dimensione di un progetto. Tuttavia, ci sono diversi intangibili che possono influenzare anche le dimensioni di un progetto.

Requisiti

La più grande caduta che ho dovuto affrontare è stata la mancanza di requisiti. Nella mia situazione particolare il responsabile delle vendite stava determinando i requisiti. Il suo focus era sulla vendita ... devo ottenere la vendita. Nella sua mente ciò che il cliente chiedeva non sembrava così complicato perché avevamo costruito qualcosa di simile. Requisiti vaghi portano a lavori a basso prezzo e aspettative oltre impegnate.

Mancanza di CCMU

CCMU è quello che chiamo un " Coo Ca Moo " (Cancella la comprensione reciproca completa). Devi avere una CCMU con il tuo cliente.

Se hai un piccolo progetto con una CCMU scadente, puoi finire di fare il progetto 2,3,4 o più volte. Così un semplice lavoro di 20 ore si trasforma in un progetto di 60 ore con uno staff stressato e un cliente molto insoddisfatto.

Scope Creep

Questo succede più spesso di quanto pensi. Il cliente decide che, poiché stai già eseguendo A, B e C, non dovrebbe essere così difficile aggiungere D o anche F. Se questo comportamento non viene controllato, può anche trasformare un piccolo progetto in un progetto di medie dimensioni. E a seconda di come il responsabile delle vendite ha venduto il lavoro, queste aspettative striscianti possono sembrare "GRATUITE" per il cliente.

— Michael Riley - AKA Gunny
fonte

1

È strano, leggendo molte di queste risposte, trovo che vedo le dimensioni di un progetto in modo molto diverso. Forse è il mio lavoro in una grande azienda, ma tendo a considerare le dimensioni di un progetto più che altro come una scala della sua visibilità / desiderabilità per i suoi clienti (a seconda della tua area di lavoro, questi possono essere collaboratori o clienti paganti effettivi).

— Kavet Kerek
fonte

1

La complessità è la risposta giusta, ma come stimarla?

I fattori sono:

I punti di estensione contano
Conteggio dei livelli dei moduli (funzioni, classi, sistemi di classi, librerie, librerie condivise, applicazioni, applicazioni di rete, ecc.)
Conteggio delle dipendenze (piattaforme incluse)
Conteggio delle interdipendenze delle caratteristiche.
Risorse non di codice necessarie (inclusi grafica / arte, script di guida - come script di progettazione di livello - e altre risorse necessarie per completare una versione dell'applicazione).

Più ne hai, più complesso è il progetto.

— Klaim
fonte

0

LOC è notoriamente inaccurato per molte misurazioni, ma penso che tu stia provando a misurare qualcosa che in realtà non esiste un modo preciso per misurare. Forse un'alternativa potrebbe essere la complessità ciclomatica .

Alla fine però, penso che la "grandezza" di un progetto sia difficile da quantificare. È quasi come chiedere come determinare se un cane è grande o no. Non solo ci sono molti modi per misurarlo (massa, volume, ecc.), Ma personalmente non lo trovo molto utile. La realtà è che i miei criteri saranno probabilmente qualcosa del tipo "Quanto è probabile che scappi da questo cane se lo vedo in un vicolo buio?"

E per la cronaca, generalmente non considererei molte righe di codice 1k come molto. Sarebbe una fetta considerevole di codice, ma non sarebbe che molto nel grande schema delle cose. Certo, suppongo che dipenda dalla lingua. Ad esempio, 1k righe di codice sono molto meno codice in una lingua come C che in una lingua come Pyhon.

— Jason Baker
fonte