Come gestire la complessità accidentale nei progetti software

Quando a Murray Gell-Mann fu chiesto come Richard Feynman fosse riuscito a risolvere così tanti problemi difficili, Gell-Mann rispose che Feynman aveva un algoritmo:

1. Scrivi il problema.
2. Pensa intensamente.
3. Scrivi la soluzione.

Gell-Mann stava cercando di spiegare che Feynman era un diverso tipo di risolutore di problemi e che non si potevano ottenere approfondimenti dallo studio dei suoi metodi. Mi sento un po 'allo stesso modo riguardo la gestione della complessità in progetti software medio / grandi. Le persone che sono brave sono intrinsecamente brave e in qualche modo riescono a stratificare e impilare varie astrazioni per rendere il tutto gestibile senza introdurre alcun innesto estraneo.

Quindi l'algoritmo di Feynman è l'unico modo per gestire la complessità accidentale o ci sono metodi reali che gli ingegneri del software possono applicare costantemente per domare la complessità accidentale?

Quando vedi una buona mossa, cercane una migliore.
—Emanuel Lasker, 27 anni campione del mondo di scacchi

Nella mia esperienza, il principale fattore di complessità accidentale sono i programmatori che si attengono alla prima bozza, solo perché sembra funzionare. Questo è qualcosa che possiamo imparare dai nostri corsi di composizione in inglese. Costruiscono in tempo per passare attraverso diverse bozze nei loro compiti, incorporando il feedback degli insegnanti. Le lezioni di programmazione, per qualche motivo, non lo fanno.

Esistono libri pieni di modi concreti e oggettivi per riconoscere, articolare e correggere il codice non ottimale: Clean Code , Lavorare in modo efficace con il codice legacy e molti altri. Molti programmatori hanno familiarità con queste tecniche, ma non sempre impiegano il tempo per applicarle. Sono perfettamente in grado di ridurre la complessità accidentale, non hanno preso l'abitudine di provare .

Parte del problema è che spesso non vediamo la complessità intermedia del codice di altre persone, a meno che non abbia subito una revisione tra pari in una fase iniziale. Il codice pulito sembra facile da scrivere, quando in realtà coinvolge diverse bozze. Scrivi all'inizio il modo migliore che ti viene in mente, noti complessità inutili che introduce, quindi "cerca una mossa migliore" e fai il refactoring per rimuovere quelle complessità. Quindi continui a "cercare una mossa migliore" fino a quando non riesci a trovarne una.

Tuttavia, non metti il ​​codice per la revisione fino a dopo tutto quel churn, quindi esternamente sembra che potrebbe anche essere stato un processo simile a Feynman. Hai la tendenza a pensare di non poter fare tutto in una sola parte in quel modo, quindi non ti preoccupi di provare, ma la verità è l'autore di quel codice meravigliosamente semplice che hai appena letto di solito non puoi scrivere tutto in un pezzo come quello, o se possono, è solo perché hanno esperienza di scrivere codice simile molte volte prima, e ora possono vedere il modello senza gli stadi intermedi. Ad ogni modo, non puoi evitare le bozze.

"L'abilità di architettura del software non può essere insegnata" è un errore diffuso.

È facile capire perché molte persone ci credono (quelli che sono bravi in ​​esso vogliono credere di essere misticamente speciali, e quelli che non vogliono credere che non sia colpa loro se non lo sono). è comunque sbagliato; l'abilità è solo un po 'più pratica rispetto ad altre abilità software (ad esempio comprensione dei loop, gestione dei puntatori, ecc.)

Sono fermamente convinto che la costruzione di sistemi di grandi dimensioni sia suscettibile alla pratica ripetuta e all'apprendimento dall'esperienza nello stesso modo in cui diventare un grande musicista o oratore pubblico è: un minimo di talento è un prerequisito, ma non è un minimo deprimente enorme che è fuori portata della maggior parte dei praticanti.

Affrontare la complessità è un'abilità che acquisisci in gran parte provando e fallendo alcune volte. È solo che le molte linee guida generali che la comunità ha scoperto per la programmazione in generale (usa i livelli, combatti la duplicazione ovunque si alzi la testa, aderisca religiosamente allo 0/1 / infinito ...) non sono così ovviamente corretti e necessari per un principiante fino a quando effettivamente non programmano qualcosa di grande. Fino a quando non sei stato effettivamente morso da una duplicazione che ha causato problemi solo mesi dopo, semplicemente non puoi "ottenere" l'importanza di tali principi.

Il pensiero pragmatico di Andy Hunt affronta questo problema. Si riferisce al modello Dreyfus, in base al quale ci sono 5 fasi di competenza in varie abilità. I novizi (fase 1) hanno bisogno di istruzioni precise per poter fare qualcosa in modo corretto. Gli esperti (fase 5), al contrario, possono applicare schemi generali a un determinato problema. Citando il libro,

Spesso è difficile per gli esperti spiegare le loro azioni con un livello di dettaglio elevato; molte delle loro risposte sono così ben praticate da diventare azioni preconsce. La loro vasta esperienza è minata da aree non verbali e preconsce del cervello, il che rende difficile per noi osservare e difficile per loro articolare.

Quando gli esperti fanno le loro cose, sembra quasi magico per tutti noi: strani incantesimi, intuizione che sembra apparire dal nulla e un'abilità apparentemente inquietante di conoscere la risposta giusta quando il resto di noi non è nemmeno così sicuro sulla domanda. Non è magico, ovviamente, ma il modo in cui gli esperti percepiscono il mondo, come risolvono i problemi, i modelli mentali che usano e così via, sono tutti notevolmente diversi dai non esperti.

Questa regola generale di vedere (e di conseguenza evitare) problemi diversi può essere applicata specificamente al problema della complessità accidentale. Avere un determinato set di regole non è sufficiente per evitare questo problema. Ci sarà sempre una situazione che non è coperta da quelle regole. Dobbiamo acquisire esperienza per essere in grado di prevedere problemi o identificare soluzioni. L'esperienza è qualcosa che non può essere insegnata, può essere acquisita solo provando, fallendo o riuscendo costantemente e imparando dagli errori.

Questa domanda da Workplace è rilevante e IMHO sarebbe interessante da leggere in questo contesto.

Non lo spieghi, ma la "complessità accidentale" è definita come complessità che non è inerente al problema, rispetto alla complessità "essenziale". Le tecniche richieste per "Addomesticare" dipenderanno da dove inizi. Quanto segue si riferisce principalmente ai sistemi che hanno già acquisito una complessità non necessaria.

Ho esperienza in numerosi progetti pluriennali in cui la componente "accidentale" ha notevolmente superato l'aspetto "essenziale", e anche quelli in cui non lo è stata.

In realtà, l'algoritmo di Feynman si applica in una certa misura, ma ciò non significa che "pensare davvero duro" significa solo magia che non può essere codificata.

Trovo che ci siano due approcci che devono essere adottati. Prendili entrambi - non sono alternative. Uno è quello di affrontarlo frammentariamente e l'altro è fare una grande rielaborazione. Quindi certamente "annota il problema". Ciò potrebbe assumere la forma di un audit del sistema: i moduli di codice, il loro stato (odore, livello di test automatizzato, quanti membri del personale dichiarano di capirlo), l'architettura complessiva (ce n'è una, anche se "ha problemi" ), stato dei requisiti, ecc. ecc.

È la natura della complessità "accidentale" che non esiste un problema che debba essere risolto. Quindi devi triage. Dove fa male - in termini di capacità di mantenere il sistema e progredire nel suo sviluppo? Forse un po 'di codice è davvero maleodorante, ma non ha la massima priorità e la correzione può essere fatta attendere. D'altra parte, potrebbe esserci del codice che restituirà rapidamente il tempo impiegato per il refactoring.

Definisci un piano per quale sarà un'architettura migliore e cerca di assicurarti che il nuovo lavoro sia conforme a quel piano: questo è l'approccio incrementale.

Inoltre, articola il costo dei problemi e usalo per costruire un business case per giustificare un refactor. La cosa chiave qui è che un sistema ben progettato può essere molto più robusto e testabile, il che comporta un tempo molto più breve (costi e pianificazione) per attuare il cambiamento - questo ha un valore reale.

Una grande rielaborazione rientra nella categoria "pensa davvero duro" - devi farlo bene. È qui che avere un "Feynman" (beh, una piccola parte di uno andrebbe bene) paga enormemente. Una rilavorazione importante che non si traduce in un'architettura migliore può essere un disastro. Le riscritture del sistema completo sono note per questo.

In ogni approccio è implicito sapere come distinguere "accidentale" da "essenziale" - vale a dire che è necessario disporre di un grande architetto (o team di architetti) che comprenda davvero il sistema e il suo scopo.

Detto questo, la cosa fondamentale per me sono i test automatizzati . Se ne hai abbastanza, il tuo sistema è sotto controllo. Se non lo fai. . .

" Tutto dovrebbe essere reso il più semplice possibile, ma non più semplice. "
- Attribuito ad Albert Einstein

Vorrei disegnare il mio algoritmo personale per gestire la complessità accidentale.

1. Scrivi una user story o un caso d'uso. Rivedere con il proprietario del prodotto.
2. Scrivi un test di integrazione non riuscito perché la funzione non è presente. Rivedi con il QA, o capo ingegnere, se c'è qualcosa del genere nel tuo team.
3. Scrivere unit test per alcune classi che potrebbero superare il test di integrazione.
4. Scrivi l' implementazione minima per quelle classi che superano i test unitari.
5. Esamina i test unitari e l'implementazione con un altro sviluppatore. Vai al passaggio 3.

L'intera magia del design sarebbe al passaggio 3: come si organizzano queste lezioni? Questo si rivela essere la stessa domanda di: come immagini di avere una soluzione al tuo problema prima di avere una soluzione al tuo problema?

Sorprendentemente, solo immaginando di avere la soluzione sembra essere una delle principali raccomandazioni delle persone che scrivono sulla risoluzione dei problemi (chiamata "pio desiderio" di Abelson e Sussman in Struttura e interpretazione dei programmi per computer e "lavorare a ritroso" in How to Polya Risolvilo )

D'altra parte, non tutti hanno lo stesso " gusto per le soluzioni immaginate ": ci sono soluzioni che solo tu trovi eleganti e ce ne sono altre più comprensibili da un pubblico più vasto. Ecco perché è necessario rivedere il proprio codice con colleghi sviluppatori: non tanto per ottimizzare le prestazioni, ma per concordare soluzioni comprese. Di solito questo porta a una riprogettazione e, dopo alcune iterazioni, a un codice molto migliore.

Se continui a scrivere implementazioni minime per superare i test e scrivi test che sono compresi da molte persone, dovresti finire con una base di codice in cui permane solo una complessità irriducibile .

Complessità accidentale

La domanda originale (parafrasata) era:

In che modo gli architetti gestiscono la complessità accidentale nei progetti software?

La complessità accidentale sorge quando coloro che hanno la direzione di un progetto scelgono di aggiungere tecnologie che sono una tantum e che la strategia generale degli architetti originali del progetto non ha intenzione di entrare nel progetto. Per questo motivo è importante registrare il ragionamento alla base della scelta in strategia.

La complessità accidentale può essere ostacolata dalla leadership che si attiene alla loro strategia originale fino a quando apparentemente non è necessario un deliberato allontanamento da tale strategia.

Evitare complessità inutili

In base al corpo della domanda, lo riformulerei in questo modo:

In che modo gli architetti gestiscono la complessità dei progetti software?

Questa riformulazione è più adatta al corpo della domanda, in cui è stato poi introdotto l'algoritmo di Feynman, fornendo un contesto che suggerisce che per i migliori architetti, di fronte a un problema, hanno un gestalt dal quale poi abilmente costruiscono una soluzione, e che il resto di noi non può sperare di impararlo. Avere una gestalt di comprensione dipende dall'intelligenza della materia e dalla loro volontà di apprendere le caratteristiche delle opzioni architettoniche che potrebbero essere nel loro ambito.

Il processo di pianificazione per il progetto userebbe l'apprendimento dell'organizzazione per fare un elenco dei requisiti del progetto, quindi tentare di costruire un elenco di tutte le opzioni possibili e quindi riconciliare le opzioni con i requisiti. La gestalt dell'esperto gli consente di farlo rapidamente, e forse con un lavoro poco evidente, facendogli sembrare facilmente.

Sottolineo che viene a lui a causa della sua preparazione. Per avere la gestalt dell'esperto è necessaria la familiarità con tutte le opzioni e la lungimiranza di fornire una soluzione semplice che consenta di prevedere le esigenze future previste che il progetto dovrebbe prevedere, nonché la flessibilità di adattarsi alle mutevoli esigenze di il progetto. La preparazione di Feynman fu quella di avere una profonda conoscenza di vari approcci sia in matematica che in fisica teorica e applicata. Era innato curioso e abbastanza brillante da dare un senso alle cose che aveva scoperto sul mondo naturale che lo circondava.

L'esperto architetto della tecnologia avrà una simile curiosità, attingendo a una profonda comprensione dei fondamenti nonché a un'ampia esposizione a una grande diversità di tecnologie. Lui (o lei) avrà la saggezza di attingere alle strategie che hanno avuto successo in tutti i domini (come i Principi di programmazione Unix ) e quelle che si applicano a domini specifici (come i modelli di progettazione e le guide di stile ). Potrebbe non essere intimamente informato di ogni risorsa, ma saprà dove trovare la risorsa.

Costruire la soluzione

Questo livello di conoscenza, comprensione e saggezza, può essere tratto dall'esperienza e dall'educazione, ma richiede intelligenza e attività mentale per mettere insieme una soluzione strategica gestalt che lavori insieme in modo da evitare complessità accidentali e inutili. Richiede all'esperto di mettere insieme questi fondamenti; questi erano i knowledge worker previsti da Drucker quando coniò il termine per la prima volta.

Torna alle domande finali specifiche:

Metodi specifici per domare la complessità accidentale possono essere trovati nei seguenti tipi di fonti.

• Principi di programmazione Unix
• Modelli di progettazione
• e guide di stile ( ad esempio PEP 8 di Python )

Seguire i principi della programmazione Unix ti permetterà di creare semplici programmi modulari che funzionano bene e sono robusti con interfacce comuni. Seguire i modelli di progettazione ti aiuterà a costruire algoritmi complessi che non sono più complessi del necessario. Le seguenti guide di stile assicureranno che il codice sia leggibile, gestibile e ottimale per la lingua in cui è scritto il codice. Gli esperti avranno interiorizzato molti dei principi presenti in queste risorse e saranno in grado di metterli insieme in modo coerente e senza soluzione di continuità.

Questa potrebbe essere stata una domanda difficile alcuni anni fa, ma oggigiorno l'IMO non è più difficile eliminare la complessità accidentale.

Ciò che Kent Becksaid ha di se stesso, ad un certo punto: "Non sono un grande programmatore; sono solo un buon programmatore con grandi abitudini".

Vale la pena sottolineare due cose, l'IMO: si considera un programmatore , non un architetto, e si concentra sulle abitudini, non sulla conoscenza.

Il modo di Feynman di risolvere problemi difficili è l'unico modo per farlo. La descrizione non è necessariamente molto facile da capire, quindi la analizzerò. La testa di Feynman non era solo piena di conoscenza, ma era anche piena dell'abilità di applicare quella conoscenza. Quando hai le conoscenze e le abilità per usarlo, risolvere un problema difficile non è né difficile né facile. È l'unico risultato possibile.

Esiste un modo completamente non magico di scrivere codice pulito, che non contiene complessità accidentale, ed è per lo più simile a quello che Feynman ha fatto: acquisire tutte le conoscenze necessarie, allenarsi per abituarsi a metterlo al lavoro, piuttosto che averlo nascosto in qualche angolo del cervello, quindi scrivi codice pulito.

Ora, molti programmatori non sono nemmeno a conoscenza di tutte le conoscenze necessarie per scrivere codice pulito. I programmatori più giovani tendono a scartare le conoscenze sugli algoritmi e le strutture di dati e i programmatori più vecchi tendono a dimenticarlo. O notazione O grande e analisi della complessità. I programmatori più anziani tendono a scartare schemi o odori di codice o non sanno nemmeno che esistono. La maggior parte dei programmatori di qualsiasi generazione, anche se conoscono i modelli, non ricordano mai esattamente quando utilizzare e le parti dei driver. Pochi programmatori di qualsiasi generazione valutano costantemente il proprio codice rispetto ai principi SOLID. Molti programmatori mescolano tutti i possibili livelli di astrazione in tutto il luogo. Non sono a conoscenza di un altro programmatore, per il momento, di valutare costantemente il suo codice rispetto alle puzze descritte da Fowler nel suo libro di refactoring. Sebbene alcuni progetti utilizzino alcuni strumenti di metrica, la metrica più utilizzata è la complessità, in un modo o nell'altro, mentre altre due metriche - accoppiamento e coesione - sono in gran parte ignorate, anche se sono molto importanti per il codice pulito. Un altro aspetto che quasi tutti ignorano è il carico cognitivo. Pochi programmatori trattano i test unitari come documentazione, e ancora meno sono consapevoli che i test unitari difficili da scrivere o nominare sono un altro puzzo di codice, che di solito indica un cattivo factoring. Una piccola minoranza è consapevole del mantra del design guidato dal dominio per mantenere il modello di codice e il modello di dominio aziendale il più vicino possibile l'uno all'altro, poiché le discrepanze sono destinate a creare problemi lungo la strada. Tutti questi devono essere considerati, sempre, se vuoi che il tuo codice sia pulito. E molti altri che non riesco a ricordare in questo momento. la metrica più utilizzata è la complessità, in un modo o nell'altro, mentre altre due metriche - accoppiamento e coesione - sono in gran parte ignorate, anche se sono molto importanti per il codice pulito. Un altro aspetto che quasi tutti ignorano è il carico cognitivo. Pochi programmatori trattano i test unitari come documentazione, e ancora meno sono consapevoli che i test unitari difficili da scrivere o nominare sono un altro puzzo di codice, che di solito indica un cattivo factoring. Una piccola minoranza è consapevole del mantra del design guidato dal dominio per mantenere il modello di codice e il modello di dominio aziendale il più vicino possibile l'uno all'altro, poiché le discrepanze sono destinate a creare problemi lungo la strada. Tutti questi devono essere considerati, sempre, se vuoi che il tuo codice sia pulito. E molti altri che non riesco a ricordare in questo momento. la metrica più utilizzata è la complessità, in un modo o nell'altro, mentre altre due metriche - accoppiamento e coesione - sono in gran parte ignorate, anche se sono molto importanti per il codice pulito. Un altro aspetto che quasi tutti ignorano è il carico cognitivo. Pochi programmatori trattano i test unitari come documentazione, e ancora meno sono consapevoli che i test unitari difficili da scrivere o nominare sono un altro puzzo di codice, che di solito indica un cattivo factoring. Una piccola minoranza è consapevole del mantra del design guidato dal dominio per mantenere il modello di codice e il modello di dominio aziendale il più vicino possibile l'uno all'altro, poiché le discrepanze sono destinate a creare problemi lungo la strada. Tutti questi devono essere considerati, sempre, se vuoi che il tuo codice sia pulito. E molti altri che non riesco a ricordare in questo momento. mentre altre due metriche - accoppiamento e coesione - sono in gran parte ignorate, anche se sono molto importanti per il codice pulito. Un altro aspetto che quasi tutti ignorano è il carico cognitivo. Pochi programmatori trattano i test unitari come documentazione, e ancora meno sono consapevoli che i test unitari difficili da scrivere o nominare sono un altro puzzo di codice, che di solito indica un cattivo factoring. Una piccola minoranza è consapevole del mantra del design guidato dal dominio per mantenere il modello di codice e il modello di dominio aziendale il più vicino possibile l'uno all'altro, poiché le discrepanze sono destinate a creare problemi lungo la strada. Tutti questi devono essere considerati, sempre, se vuoi che il tuo codice sia pulito. E molti altri che non riesco a ricordare in questo momento. mentre altre due metriche - accoppiamento e coesione - sono in gran parte ignorate, anche se sono molto importanti per il codice pulito. Un altro aspetto che quasi tutti ignorano è il carico cognitivo. Pochi programmatori trattano i test unitari come documentazione, e ancora meno sono consapevoli che i test unitari difficili da scrivere o nominare sono un altro puzzo di codice, che di solito indica un cattivo factoring. Una piccola minoranza è consapevole del mantra del design guidato dal dominio per mantenere il modello di codice e il modello di dominio aziendale il più vicino possibile l'uno all'altro, poiché le discrepanze sono destinate a creare problemi lungo la strada. Tutti questi devono essere considerati, sempre, se vuoi che il tuo codice sia pulito. E molti altri che non riesco a ricordare in questo momento. Un altro aspetto che quasi tutti ignorano è il carico cognitivo. Pochi programmatori trattano i test unitari come documentazione, e ancora meno sono consapevoli che i test unitari difficili da scrivere o nominare sono un altro puzzo di codice, che di solito indica un cattivo factoring. Una piccola minoranza è consapevole del mantra del design guidato dal dominio per mantenere il modello di codice e il modello di dominio aziendale il più vicino possibile l'uno all'altro, poiché le discrepanze sono destinate a creare problemi lungo la strada. Tutti questi devono essere considerati, sempre, se vuoi che il tuo codice sia pulito. E molti altri che non riesco a ricordare in questo momento. Un altro aspetto che quasi tutti ignorano è il carico cognitivo. Pochi programmatori trattano i test unitari come documentazione, e ancora meno sono consapevoli che i test unitari difficili da scrivere o nominare sono un altro puzzo di codice, che di solito indica un cattivo factoring. Una piccola minoranza è consapevole del mantra del design guidato dal dominio per mantenere il modello di codice e il modello di dominio aziendale il più vicino possibile l'uno all'altro, poiché le discrepanze sono destinate a creare problemi lungo la strada. Tutti questi devono essere considerati, sempre, se vuoi che il tuo codice sia pulito. E molti altri che non riesco a ricordare in questo momento. s mantra per mantenere il modello di codice e il modello di dominio aziendale il più vicino possibile l'uno all'altro, poiché le discrepanze sono destinate a creare problemi lungo la strada. Tutti questi devono essere considerati, sempre, se vuoi che il tuo codice sia pulito. E molti altri che non riesco a ricordare in questo momento. s mantra per mantenere il modello di codice e il modello di dominio aziendale il più vicino possibile l'uno all'altro, poiché le discrepanze sono destinate a creare problemi lungo la strada. Tutti questi devono essere considerati, sempre, se vuoi che il tuo codice sia pulito. E molti altri che non riesco a ricordare in questo momento.

Vuoi scrivere un codice pulito? Non è richiesta magia. Basta andare a imparare tutto ciò che è necessario, quindi utilizzarlo per valutare la pulizia del codice e fare il refactor fino a quando non sei soddisfatto. E continua a studiare: il software è ancora un campo giovane e nuove intuizioni e conoscenze vengono acquisite a un ritmo rapido.