Lavorare su un grande progetto è una buona o una cattiva cosa a lungo termine? [chiuso]

Le dimensioni non contano, il successo sì!

Lavorare su progetti con tutor di valore che possono accelerare il tuo giudizio e la tua esperienza e che hanno successo nel soddisfare i clienti è la cosa più importante che puoi concentrarti sulla carriera.

Lavorare su un progetto dopo un progetto che è un fallimento ti insegnerà le cose, ma in un modo arretrato che richiede molto tempo per capire. Lavorare su progetti a lungo termine che stanno fallendo è la stessa cosa.

Le dimensioni del progetto non sono complesse o semplici. Non significa più o meno cose nuove da imparare. I progetti complessi e "duri" sono solitamente dovuti a cattiva gestione, design e architettura eccessivamente complessi e simili, questo può essere applicato a progetti di più settimane e a progetti pluriennali.

Good Enough and YAGNI

Oggi esiste un gran numero di progetti che non hanno una lunga durata di conservazione. Ci sono progetti web che possono essere solo in produzione per alcune settimane o mesi a seconda del ciclo di vita della necessità del software. Pensa che i micrositi promozionali che sono di natura temporale saranno gettati via e non saranno mai aggiornati o mantenuti.

Imparare come ridimensionare le tue Architecture Astronaut tendenze e fare quel tanto che basta grattarsi un prurito è un'abilità molto rara e preziosa oggi.

Non che Abbastanza buono e YAGNI non si applichino a progetti a più lungo termine del ciclo di vita, ma ridimensionare processo e metodologia è molto più difficile che scalare.

La specializzazione è per gli insetti

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -Robert A. Heinlein

Applica quanto sopra allo sviluppo del software e non sbaglierai. Essere competenti in molte cose ti isolerà dalle mode e dai feticismi del settore e ti assicurerà di essere più occupabile rispetto a chi è un pony inganno .

Penso che sia molto utile lavorare su un grande progetto. Come si impara un sacco di aspetti di Ingegneria del software in progetti di grandi dimensioni, che include ma non è limitato a:

• Codice di organizzazione per
  • Riusabilità
  • Maintainability
  • estensibilità
• Lavoro di gruppo
• Gestione progetti

Quando dici di essere limitato alle tecnologie, probabilmente lo fai, ma puoi cambiare progetti / lavori / ruoli una volta che le parti interessanti del progetto sono state completate. Questo di solito è quando il progetto è entrato in produzione. Dopo un ciclo o due di aggiornamenti potresti iniziare ad annoiarti con la tecnologia

L'esperienza su un prodotto è molto diversa. Uno deve pensare a molti aspetti per un aggiornamento, ad esempio,

• Compatibilità con versioni precedenti
• Migrazione dei dati

Le tecnologie vanno e vengono comunque, ma l'esperienza di costruire un grande progetto sarà sempre utile. Detto questo, ogni volta che si avventurerà con una nuova tecnologia, l'esperienza di aver costruito piccoli progetti nella tecnologia agirà per la mitigazione del rischio quando si arriva a costruire un grande progetto al suo interno.

Vorrei fare alcuni punti non ancora menzionati nelle risposte altrimenti buone di Jarrod e Ozair:

• I progetti di grandi dimensioni tendono ad avere un ciclo di vita più lungo, quindi la manutenibilità è una preoccupazione chiave. (I piccoli progetti possono anche vivere a lungo, ma IMHO è meno probabile ... inoltre questi spesso diventano più grandi nel tempo.) In piccoli progetti, è meno probabile (essere obbligati a) imparare come scrivere mantenibile (= modulare, pulito , testabile, SOLID ) codice.
• I progetti di grandi dimensioni tendono a coinvolgere anche team di sviluppo più grandi e molte altre persone (vari manager, personale addetto alla certificazione, scrittori tecnici, ecc.) il che significa che la comunicazione (su più livelli) è più essenziale che in un piccolo progetto. / li>
• I progetti di grandi dimensioni tendono a rallentare nel tempo (a causa di un team più numeroso, di solito parte di una grande organizzazione e del lungo ciclo di vita), diventando sempre più in modalità di manutenzione. Questo può essere meno affascinante, tuttavia una parte importante del SDLC. Tuttavia, questo significa anche che le possibilità di imparare nuove tecnologie sono limitate. (OTOH, come suggerito sopra, c'è molto di più nello sviluppo di SW rispetto alla tecnologia ...) e di solito significa anche più burocrazia e meno agilità: - (

La risposta rapida sarebbe: Dipende .

Entrambi i progetti grandi / piccoli hanno i loro sapori specifici per gli sviluppatori coinvolti in esso. La principale differenza è nell'approccio alla gestione dei progetti e nella portata del progetto. Dal punto di vista dello sviluppatore, è più di creare codice dell'infrastruttura per gestire casi d'uso comuni per supportare il tuo progetto a lungo termine.

I progetti più piccoli tendono a essere team di un solo membro con pochissimo tempo di progettazione e scadenza aggressiva :)

La mia preferenza è lavorare su un progetto completo sia che sia piccolo o grande. Dovremmo avere una comprensione completa del progetto, essere coinvolti sin dall'inizio fino al tramonto. Inoltre dovremmo giocare più tiri nel progetto in modo che possiamo capire meglio un ciclo di vita del progetto.
Rispetto al Time Frame è meglio iniziare con piccoli progetti e apprenderli completamente, poi andare su Bigger / Large Project e provare ad apprenderli. Di solito sarà diverso apprendere il progetto grande. Ma se hai esperienza iniziale con Piccoli Progetti che ti aiuteranno a capire rapidamente il Progetto Grande

In breve: inizia con piccoli progetti, impara a fondo e poi stabilisci progetti di grandi dimensioni.