Buone pratiche per lo sviluppo su larga scala / consegna di software [chiuso]

In sostanza stai chiedendo "qual è il modo migliore per scrivere software commerciale", e se chiedi a 5 ragazzi avrai 8 risposte.

Pertanto, la risposta migliore che posso dare a una domanda così ampia (non sono sicuro che sia "troppo ampia" e quindi un candidato alla chiusura, e quindi proverò a rispondere) è:

DIPENDE.

Dipende da quanti sviluppatori lavorano insieme . In un ambiente di sviluppo più piccolo, ad esempio in un'azienda di medie dimensioni che fornisce molte app personalizzate per lo sviluppo delle app, potrebbero esserci molti progetti che devono essere completati e pochissimi programmatori che li eseguano. In questo caso il responsabile IT di solito consegna ciascun progetto a uno, forse a due sviluppatori e dice "fai questo, fai il lavoro che puoi, ma ne ho bisogno in un mese". Questo è di solito un ambiente abbastanza libero in cui i programmatori auto-inizianti "lupo solitario" possono prosperare. Tuttavia, in un ambiente del genere tende ad esserci un sacco di quadri concorrenti portati indipendentemente l'uno dall'altro dagli sviluppatori che non si siedono e parlano di struttura unificata. La qualità del codice può risentirne e il codice spesso non aderisce a nessun "manuale di stile" diverso da quello che è stato predefinito dall'IDE.

D'altro canto, le code houses generalmente si organizzano in squadre, gettando quante persone quante sono le tempistiche e il budget per la richiesta del progetto. Queste squadre richiedono non solo auto-partenti, ma buoni giocatori di squadra che comunicano tra loro e collaborano. Questo fornisce la "sinergia" di cui i manager amano parlare, aumentando la velocità. Ma ciò richiede che l'intera squadra canticchi come una macchina ben oliata e che abbia un project manager che è bravo a mantenere la roadmap di sviluppo libera da ostacoli.

Dipende da quanti progetti devono essere sviluppati contemporaneamente . Generalmente è una buona idea mantenere una squadra che lavora su una cosa finché non ha finito, quindi rivalutare le dimensioni e il trucco della squadra prima di assegnare la prossima grande cosa. Mantenere una squadra facendo una cosa li tiene concentrati. Tuttavia, più persone sono per squadra, meno squadre hai, a parità di altre condizioni. Ciò aumenta la velocità della squadra su una cosa, ma può ridurre il rendimento complessivo. Incorporare elementi di lavoro di altri progetti nel programma di una squadra ottiene le piccole cose ma prende l'attenzione dal progetto principale, causando una riduzione della velocità causata dal cambio mentale. Squadre ridotte riducono la velocità ma aumentano il numero di "pipeline" simultanee, riducendo il tempo che gli elementi si trovano nel backlog con gli altri capi dipartimento andando "perché non hai iniziato a lavorare sul mio progetto?".

Dipende dall'ambito e dal budget dei progetti . Se un cliente ha bisogno di uno sviluppatore per aumentare un sito che il suo UX interno abbia wireframe, e ne hanno bisogno in un mese per $ 10 bis, e tutti questi vincoli sono fattibili, non ha senso assegnare un'intera squadra di sviluppo ad esso; non è ciò che il cliente chiede, ciò di cui ha bisogno, né ciò per cui sono disposti a pagare. Viceversa, avere un team di sviluppo unico al lavoro sul prossimo superprogetto interno non è una buona idea se si può aiutare; non solo lo sviluppo sarà rallentato perché solo un ragazzo lo sta codificando, stai solo ottenendo la prospettiva di uno sviluppatore sulla soluzione che, per sua natura, sarà limitata.

Creare software di grandi dimensioni è una cosa difficile da fare correttamente, e seguire le buone pratiche è molto importante.

Un buon inizio è progettare correttamente il sistema. Partizionala il più possibile e crea interfacce valide (ecco perché gli ingegneri hardware sono talvolta ottimi architetti).

I concetti comuni si applicano anche qui (repository di codici, unità che testano il codice, integrazione continua, ecc.)

Dipende, ma ci sono alcuni aspetti che sono comuni in tutti i tipi di programmi.

1. Inizia lo sviluppo dal punto di vista dei sistemi: gestione della memoria, gestione dei processi, ecc.

2. Esegui una codifica efficiente. Non inserire tutto il codice in un singolo file. Crea varie funzioni e chiamale, è una buona pratica.

3. Cerca di accorciare il codice il più possibile e distribuire il numero minimo di variabili possibile.

4. Concentrati maggiormente sul salvataggio della memoria di sistema rispetto al risparmio di spazio su disco (sebbene entrambi siano ugualmente importanti). La memoria di sistema deve essere gestita con cura in modo che non vi sia un utilizzo eccessivo di quello che il cliente si aspetta di utilizzare. Al giorno d'oggi abbiamo dischi rigidi con uno spazio enorme, quindi lo spazio su disco non sarà un problema, ma ancora una volta il codice è efficiente, migliore è la gestione del disco.

Non ti verrà detto di fare tutto da solo, quindi concentrati maggiormente sul tuo dovere piuttosto che preoccuparti del risultato finale. È un'esperienza meravigliosa. E assicurati che ti piaccia farlo: -)

Tutto il meglio.