architettura software (progettazione OO) corso di aggiornamento [chiuso]

Ho ragione nel ritenere che non effettui alcun test unitario? Il test delle unità è un ottimo modo per mostrare dove si disegna / manca l'architettura ... se non si è in grado di testare le classi in isolamento, il progetto potrebbe essere rotto ... se è difficile scrivere test per le classi, questo potrebbe anche essere un segno che il design potrebbe essere migliorato. Il test delle unità mi ha insegnato più sulla corretta progettazione di qualsiasi libro là fuori ...

I miei due suggerimenti sarebbero da un lato, tornare ai fondamenti e, dall'altro, aggiungere a quelli fondamentali nella cassetta degli attrezzi:

Ritorno ai fondamenti: I principi di progettazione sono gli elementi fondamentali che guidano i modelli di progettazione, senza i principi da perseguire per tutti quei modelli formali non esisterebbero. Inizia con il SOLID link ) e vai su pezzi del codice che ritieni siano diventati accidentati e inizia a valutare quali principi si stanno rompendo e perché. Per il futuro codice che scrivi, con ogni classe o metodo o design che inizi a implementare, chiediti se obbedisce ai principi o se ne infrange uno.

Aggiunta di fondamentali: Lei menziona OO e chiaramente ha una strong spinta verso questa direzione, ma i progetti OO possono spesso essere migliorati attraverso la comprensione del paradigma funzionale e il modo in cui raggiunge la conformità con i principi di progettazione. Se non hai imparato alcun linguaggio funzionale, impara Haskell o f # o Clojure o qualcuno di loro (Haskell ti darà letteralmente il mal di testa e cambierà idea per te). Solo imparando e praticando uno di questi per un mese nel tuo tempo libero ti daranno nuovi strumenti che ti permetteranno di obbedire più facilmente e in modo completo ai principi del buon design in scenari in cui forse gli approcci OO non hanno proprio un buon design.

Un altro approccio per un rinfresco è Clean Coders . È una raccolta di video di Uncle Bob (Robert C. Martin).

Guarda i titoli di questi video. Vedrete che riguardano principalmente TDD, Clean Code, SOLID e Pattern di componenti. Il nostro team sta guardando un video a settimana (con una discussione successiva) per avere una comprensione comune dei principi che vogliamo seguire. Test unitari per esempio ... e i video che spiegano molto bene, come farlo e come iniziare.

Generare versioni spesso significa che il codice cambia continuamente: piccoli miglioramenti, nuove funzionalità, funzionalità aggiuntive, ecc. Quindi la regola principale (come dice il mio college) è tenere presente che qualunque cosa tu scriva oggi verrà cambiata Domani. L'intero sistema dovrebbe essere estremamente flessibile e semplice, in modo che le modifiche non interrompano la sua architettura o causino altri problemi.

Se non hai abbastanza tempo per progettare tutto bene, sono abbastanza sicuro che sia colpa della tua gestione. Continuano a spingerti, quindi devi produrre codice di lavoro tutto il tempo. Cerca di convincerli che la creazione di un buon design sin dall'inizio è essenziale: ciò farà risparmiare tempo in futuro. Altrimenti rischi di avere un mucchio di codice funzionante ma ingestibile. Inoltre, migliore è il design, minore è la necessità di programmare il tempo. Quando tutto è pensato a fondo, c'è ben poco da fare.

Potresti anche prendere in considerazione la revisione del codice. Lo sviluppo richiederà più tempo, ma molto più tempo sarà risparmiato sulla risoluzione dei bug.

Nell'azienda che lavoro, ogni pezzo di design un po 'grande viene discusso con il nostro team leader. Nulla è codificato senza il suo OK. Presumo, dovresti essere la persona del tuo team che approverebbe il design. Se pensi di non avere abbastanza abilità, puoi farlo insieme ad altri membri della tua squadra, che sono i più abili. Durante le revisioni del codice potresti raccogliere l'intero team e dire loro quali sono i miglioramenti: come e perché sono stati creati. Questo è importante, perché (a) tutti impareranno e (b) c'è una grande possibilità che otterrai alcune buone idee dai college meno esperti.

Posso rilevare qualcosa dalla tua domanda:

1. Sembra che tu pensi che sia possibile "migliorare" l'architettura del software. Questo non è vero. Ogni modifica che stai facendo può solo rompere l'idea originale del design: le idee che hai avuto anni fa erano già state dimenticate e qualcos'altro le ha sostituite.
2. Quello che puoi fare è "cercare di seguire l'architettura esistente". Questo richiede uno sforzo per comprenderlo e seguirlo. Dovrebbero solo fare questi miglioramenti che seguono l'architettura esistente. L'architettura diventa più strong quando le persone smettono di inventare nuove cose e seguono semplicemente i modelli esistenti.
3. Nel corso del tempo il software diventerà più complicato. Questo può nascondere la struttura originale del software se la nuova roba sta inventando nuovi modelli.