Lo sviluppo di grandi applicazioni richiede uno sforzo enorme. Possono esserci team per ogni fase di sviluppo e devono utilizzare modelli di progettazione diversi e passare attraverso l'intero SDLC.
Ho due anni di esperienza come sviluppatore di software su piccole applicazioni e sono interessato a quali sono gli approcci e gli argomenti comuni. pratiche per le grandi applicazioni? Soprattutto dal punto di vista della gestione del progetto.
Come posso adottare tali pratiche lavorative?
Lavorare su grandi team è sicuramente una nuova esperienza. Non sarai più in grado di capire o probabilmente avere accesso all'intera base di codice che costituisce il tuo prodotto. Dovrai probabilmente eseguire controlli di processo particolari che non riguardano in realtà ciò che sta facendo la tua squadra o il modo in cui lo fanno, ecc.
Sto ancora imparando da solo su questo argomento, ma penso che la mia chiave di lettura sia ancora lontana:
Non hai bisogno di capire l'intero ecosistema, e il tentativo di farlo può effettivamente ostacolarti, specialmente quando inizi a salire. Quando partirò, consiglierei di concentrarti sulla comprensione del tuo codice e dei limiti logici su come il tuo codice interagisce con il codice di altri team (database condivisi, cache, servizi SOAP / REST, file system, ecc.) E quali dipendono da up e downstream e i dipendenti sono.
Nelle grandi organizzazioni ci sono semplicemente troppi ingranaggi mobili per ogni persona per avere una conoscenza intima del funzionamento interno di ciascun sistema discreto. Diventare davvero bravo a capire come trovare la singola persona o la pagina wiki che ha le risposte necessarie per risolvere i propri problemi di prodotto o di processo è davvero un set di abilità che si desidera raccogliere.
Ciò significa conoscere un po 'la struttura della tua organizzazione e chi porre domande su come ottenere informazioni su un argomento specifico o su chi porre domande su chi porre domande su chi porre domande su un particolare argomento.
Conoscere ed essere in buoni rapporti con i tuoi architetti del software, i project manager, gli sviluppatori di lead, ecc. tutto diventa molto utile qui.
Per quanto riguarda i design pattern e le cose tecniche.
Non penso che ci siano molti cambiamenti importanti sui modelli di progettazione usati sui piccoli progetti rispetto ai grandi progetti. Una fabbrica è una fabbrica è una fabbrica giusta?
Allo stesso tempo, per gestire il gran numero di persone coinvolte, tende ad essere spinto a compartimentare componenti specifici dell'applicazione in modo che siano indipendenti e disaccoppiati da altri componenti il più possibile. Nel mio ruolo attuale vedo molti diagrammi N-Tier con un sacco di piccole scatole che denotano funzionalità specifiche del prodotto. per la maggior parte ogni squadra è responsabile di una o più di quelle caselle specifiche. Quindi siamo molto precisi su ciò che i nostri componenti sono in / out e requisiti, poiché non possiamo semplicemente modificare quei dettagli volenti o nolenti a causa degli strati di persone coinvolte nell'apportare modifiche.
La mia divisione non porta questo all'estremo che fanno altre aziende, ma se stai lavorando su una grande soluzione distribuita piuttosto che su un unico grande programma come Ubuntu o Windows potresti scavare in un'architettura orientata ai servizi come il modello Amazon è in corso al fine di facilitare questa separazione delle preoccupazioni.
Proprio come i diagrammi dell'architettura n-tier con componenti logici specifici, SOA è molto utile in quanto se fai le cose nel modo corretto e implementa meccanismi di controllo della versione dell'interfaccia solida e comunichi le imminenti modifiche dell'interfaccia in anticipo puoi abilitare più team a lavorare sulle soluzioni VNext in parallelo, lavorando contro endpoint stentati e interfacce predeterminate fino a quando alcuni flussi verso il basso quando i vari servizi sono abbastanza funzionali da iniziare a connettersi direttamente l'uno all'altro per iniziare a servire le risposte effettive piuttosto che le risposte di stub / mock in scatola.
Ci sono anche alcuni processi molto interessanti intorno all'impostazione dell'ambiente di sviluppo quando si lavora su servizi con interdipendenze tra servizi che sono stati tutti sviluppati in parallelo, e come si può assicurare che l'ambiente di sviluppo di ogni team o delle società condivise abbia gli ultimi bit possibili distribuito senza introdurre interruzioni funzionali importanti che bloccano le altre squadre.
Hai chiesto "... come adottare questa pratica lavorativa ...". Non penso ci sia una vera risposta di scelta rapida. Se vuoi sapere come avviene lo sviluppo in una grande azienda, vai a lavorare in una grande azienda e guarda cosa fanno (e come funziona). Dopo alcuni anni, vai a lavorare in una grande azienda diversa, vedi cosa è diverso e cosa è lo stesso. Ripeti questo numero di volte.
Sono stato in IT da circa 20 anni e sto ancora imparando come accade lo sviluppo. Ho lavorato in un gran numero di aziende, grandi e piccole. Sono tutti diversi. Tutti fanno alcune cose bene e altre male. Ma ho imparato qualcosa di nuovo sullo sviluppo del software in ognuno di essi.
Ci dispiace, ma non c'è davvero modo di fare esperienza, se non facendo esperienza.
Leggi altre domande sui tag project-management