Conquistare la complessità: tecniche preziose [chiuso]

YAGNI. Il modo migliore per evitare la complessità accidentale è smettere di rendere le cose più generiche e flessibili di quelle che devono essere.

Ad esempio, non iniziare a cercare framework e librerie fino a quando conosci non ne hai effettivamente bisogno. Invece di risolvere i problemi di oggi, dedichiamo tempo a pensare a potenziali problemi che potrebbero sorgere in futuro. Non farlo. Concentrati su oggi.

Trovo che Event Driven Architecture e Command-Query Responsibility Segregation siano le tecniche più comuni che uso per conquistare la complessità.

In poche parole:

• I controller dell'interfaccia utente inviano comandi granulari per conto dell'utente
• I gestori di comandi modificano lo stato dell'applicazione tramite sottosistemi (come un modello di dominio o semplicemente script di transazione)
• Le modifiche allo stato dell'applicazione generano eventi
• I gestori di eventi reagiscono inviando più comandi e / o interagendo con i servizi applicativi (aggiornando i dati ausiliari per la visualizzazione, inviando email, ecc. ecc.) accade molto qui e questo è il metodo principale di disaccoppiamento della logica ausiliaria da quella logica che modifica lo stato dell'applicazione)

Su larga scala, cerco di attenermi in modo un po 'rigido al comando send, gestire il comando, generare eventi, gestire il pattern degli eventi - può dare una organizzazione su larga scala a una varietà di tipi di progetti.

Quindi, consento ai gestori di ottenere la loro funzione attraverso qualunque meccanismo appaia appropriato. Questi meccanismi formano sottocomponenti dell'applicazione come un modello di dominio con persistenza, logger, e-mail, ecc.

Consentire flessibilità nell'implementazione di questi sottocomponenti consente agilità (scrivilo per ottenerlo, se necessario), riutilizzo del codice (se collegato alla libreria o copia e incolla), refactoring (basiamo su questo componente precedentemente scritto ma miglioralo / modificalo in questo modo.

Ma attenersi a EDA & CQRS ci fornisce una certa coerenza architettonica tra i progetti, il che rende molto più semplice la navigazione di un codice in codice estero. Fornisce anche dei punti utili per implementare le funzionalità con AOP - come l'autorizzazione e l'amp; registrazione di comandi, eventi persistenti, distribuzione del carico di lavoro, ecc.

Ho trovato il seguente utile per ridurre la complessità:

• Uso di Lingua di alto livello , come Python. Non sempre possibile, però.
• Programmazione dal basso verso l'alto .
• Scrivere i test delle unità in anticipo.
• Refactoring, con particolare attenzione a DRY, utilizzando uno strumento di refactoring.
• Uso dei modelli di progettazione, ma solo quando appropriato.
• Metti in pratica i Principi SOLID quando fai OOP.
• Esecuzione frequente degli strumenti di metrica del codice sorgente, esp. misurare Cyclomatic Complexity .
• Evitare la notazione ungherese e altre menzioni pre / fissazioni osserzioni , per motivi di salute.
• Smetti di confondere concreto vs astratto con specifico o generale .

Spiegazioni pratiche.

(La frase deriva da questo: link

Se non riesci a spiegarlo con le mani in tasca, è troppo complesso. Semplifica fino a quando non puoi spiegarlo.

Aiuta a riassumere casi d'uso, architetture, schemi di progettazione, idiomi di programmazione e simili come storie brevi e facili da comprendere.

Questo di solito significa che devi creare blocchi significativi o astrazioni che devono essere isolati e spiegati separatamente.

Questi blocchi non sono monstrosities del linguaggio di programmazione, ma sono reali semplificazioni utili. Più simile alla natura "classe" rispetto a "istanza" di astrazione rispetto al "superclasse astratto" rispetto al problema "superclasse concreta" in cui gli esperti di OO sono impazziti.

Rendi il tuo sistema piatto anziché profondo: oggetti grandi che non parlano affatto, non un carico di adolescenti che parlano tra loro. Un tipo di dati può spesso essere modificato in un punto centrale in modo loopy, come PhysicsSystem .

Non è necessario disperdere quella logica in 50 diverse classi che devono parlare tra loro e mutare il proprio piccolo stato localizzato. Fare ciò porterà ognuno a essere individualmente più semplice, ma ragionare su ciò che fa in termini di fisica sarà, nel complesso, molto più complesso a causa della ragnatela delle interazioni che introduce. Basta fermarsi a pensare di rompere quel sistema fisico in 50 diverse classi e interfacce astratte, anche se individualmente semplici. Pensa a ciò che realmente fa alla tua capacità di comprendere ciò che farà il motore della fisica, e renditi conto di quanto ritardato possiamo essere con OOP, rendendo le cose esponenzialmente più complesse nel loro insieme per rendere semplice ogni individuo.

Guarda come i motori di gioco lo fanno. Hanno l'idea giusta.

La nozione di un'entità Car contribuisce a malapena a qualsiasi complessità del sistema, in quanto si tratta semplicemente di una raccolta di componenti e non fornisce alcuna funzionalità al sistema. E i componenti contribuiscono a malapena a qualsiasi complessità del sistema, dal momento che sono solo dati. Il sistema si scompone in una semplice linea piatta di sistemi pesanti, in gran parte indipendenti, che contengono la funzionalità, non una profonda ragnatela di interazioni tra interfacce astratte che rappresentano le idee più granulari lontane dalle esigenze del business. Non solo ridurrà sostanzialmente il codice richiesto per il software, ma renderà anche più facile suddividere il suo design in una manciata di sistemi di cui hai bisogno mentre ti consentirà di parlare con i manager e i clienti dell'organizzazione del sistema (che è letteralmente solo il organizzazione di questi sistemi) in un modo che possono effettivamente comprendere in misura molto maggiore, come PhysicsSystem , RenderSystem , ecc.

Ed è l'AF estensibile e manutenibile, che ti consente di affrontare idee di design inattese del tutto nuove che spezzerebbero le astrazioni più attentamente progettate, richiedendo comunque solo la modifica di un punto nel codice senza modifiche a cascata.