Quando i sistemi diventano sempre più grandi, come fai a mantenere una comprensione globale del tuo sistema? [duplicare]

Question

Quando i sistemi diventano sempre più grandi, come fai a mantenere una comprensione globale del tuo sistema? [duplicare]

#1 da (25 voti)

18

Oggi mi sono reso conto penosamente che per alcune decisioni è necessaria una buona conoscenza generale del sistema. Altrimenti, il rischio è troppo alto perché la tua ipotesi si rivelasse sbagliata.

Immagina di essere uno sviluppatore di un negozio online. Per comprendere il sistema, devi comprendere molti sottosistemi collegati, ad esempio:

Come ricevere ed elaborare le informazioni sui prodotti da vari fornitori
In che modo il cliente può cercare e ordinare prodotti sul tuo negozio web
In che modo gli ordini vengono elaborati e gestiti dal servizio clienti
In che modo il sistema SAP gestisce il processo di fatturazione
...

Più grande diventa il sistema, più devi capire.

Se manca questa conoscenza, soluzioni sub-ottimali sviluppate quando team specializzati hanno lavorato insieme. Team specializzati, che hanno compreso solo in dettaglio la loro parte del sistema.

Per affrontare questo problema, la nostra azienda ha cambiato la strategia, in modo che un team di sviluppo debba sempre essere responsabile di tutti gli aspetti di una funzionalità. Anche se coinvolge l'intera catena di processi. (È una specie di team di caratteristiche, ma non di team che lavorano su diversi sottosistemi.)

Quali sono le strategie efficaci per gli sviluppatori per mantenere aggiornate le conoscenze relative al sistema e al processo operativo?

Penso che una buona documentazione di sistema sia una chiave, ma temo che ci sia un punto in cui la mente umana non può scalare alla velocità del sistema. A un certo punto di dover semplicemente, ma che ipotesi semplificate possono rivelarsi errori costosi. Quando devi implementare e mantenere il codice, devi solo conoscere i dettagli esatti.

Come sviluppatore, attualmente devo affrontare un conflitto di interessi difficile:

Ho bisogno di dedicare più tempo alla comprensione del nostro sistema e del nostro processo operativo.
Ho bisogno di sviluppare e mantenere il nostro codice.

Poiché il tempo è limitato, 2) vince per lo più. Il risultato è che per lo più ottengo una conoscenza più approfondita lungo il percorso e una certa metà delle conoscenze delle conversazioni casuali.

Sai quanto enormi aziende come Amazon risolvano questo problema? Suppongo che nessun singolo essere umano sia in grado di comprendere un processo così complesso e sia in grado di fornire il codice in più sottosistemi contemporaneamente.

documentation knowledge-transfer

posta Philipp Claßen 04.09.2014 - 00:25

fonte

1 risposta

Leggi altre domande sui tag documentation knowledge-transfer

"richieste pull" simili a Github senza Github Quando una classe o un modulo dovrebbe essere in un assembly / DLL separato?

score 25 · Accepted Answer

Comprendi i componenti

Iniziamo con un'affermazione fondamentale che, spero, è già evidente:

Smaller teams are more efficient, creative and productive than larger ones.

E una massima semplice, ma fondamentalmente importante:

To cook an elephant, break it into smaller pieces.

In termini di programmazione, lo facciamo incapsulando, astrazione e modularizzazione, cercando sempre di creare interfacce coerenti, facilmente comprensibili, funzionali e coerenti tra i componenti. Ogni parte dell'elefante riceve la sua scatola nera concettuale; una volta che le parti interne di ogni scatola nera sono progettate, codificate, testate e accettate, nessuno deve più pensare agli interni della scatola, a meno che un nuovo requisito imponga un cambiamento funzionale.

Funziona anche a livello di persone. Poiché i team più piccoli sono più efficienti dei team più grandi, le aziende più grandi (in particolare le organizzazioni a matrice) hanno spesso gruppi di lavoro più piccoli, ciascuno dei quali è responsabile di una determinata parte del software.

Documenta le interazioni

Come probabilmente hai già capito, il problema non sono le scatole nere, è capire le interazioni tra le scatole nere. Ci sono un certo numero di tecniche per affrontare questo, tutte che coinvolgono più tempo e risorse:

Documentazione di classe
Test di integrazione
Diagrammi architettonici
Diagrammi del flusso di dati

E così via. Ovviamente, devi avere persone in grado di leggere e comprendere questa documentazione e applicarla ad alto livello. Deve essere disponibile per gli sviluppatori di software e aggiornato.

Stiamo sognando, vero?

Dove lavoro, gestiamo un negozio piuttosto snello. Ma facciamo del nostro meglio per creare questi artefatti. Sono, infatti, richiesti elementi del prodotto software complessivo.

Dividi e conquista

Fondamentalmente, quello che vuoi è che i tuoi piccoli team (e il tuo software baby elefante) appaiano più o meno così:

Eiltuoteamdisoftwaregenerale(esviluppatoelefantedelsoftware)perassomigliareaquesto:

La vera sfida è questa: come si mantiene il flusso di informazioni ad un alto livello di qualità e produttività? Nell'ambito della progettazione di sistemi, il modo in cui viene fatto è progettare attentamente le comunicazioni tra i nodi, in modo che interfacce, attori, oggetti e messaggi siano ben definiti, coerente , chiaro e comprensibile.

Ricorda, stiamo parlando di scatole nere qui. Comprendiamo già le scatole nere; la chiave è capire le interazioni che avvengono tra le scatole nere. Un'architettura sensibile può significare la differenza tra un software ben organizzato e facilmente comprensibile e una grande palla di fango.

E infine ...

Sii chiaro su ciò che vuoi

Se hai dei requisiti software poco chiari o sottostimati, non è realistico avere una buona conoscenza del software. I requisiti dovrebbero essere comprensibili in modo tale che lo stakeholder possa comprendere chiaramente quando una funzionalità è completata, e ci sono metriche specifiche, identificabili e misurabili attraverso le quali il successo può essere dichiarato.