Sono continuamente sopraffatto da grandi progetti, quando raggiungono un certo livello di complessità. Una volta raggiunto un certo punto in un progetto, i miei progressi rallentano fino a gattonare e mi ritrovo a ripercorrere costantemente i miei passi e risolvere ogni tipo di confusione.

Sono diventato davvero bravo nel refactoring a causa di questa mia debolezza. E cerco sempre di scomporre i miei oggetti in oggetti più piccoli e più gestibili. Questa debolezza mi ha anche probabilmente indotto a prestare troppa attenzione alla progettazione corretta delle cose.

So che se posso dividere i miei problemi in più piccoli, sarò in grado di realizzare senza problemi. Una strategia che viene in mente è lo sviluppo guidato dai test. Cos'altro posso fare?

smetti di pensare al codice

iniziare a pensare a livelli, funzionalità, moduli, servizi e altre astrazioni di livello superiore

ti senti sopraffatto perché stai pensando a un livello troppo basso

Rendere il complesso semplice è facile ; aspetta pensa che sia il contrario.

Tutti lottano con questo, non esiste una soluzione semplice che abbia un'efficacia estrema.

Dal momento che non hai elencato questo nelle tue domande, il mio suggerimento sarebbe di:

Concentrarsi sulla coesione funzionale tramite:

Il principio della singola responsabilità stabilisce che ogni oggetto dovrebbe avere un'unica responsabilità e che la responsabilità dovrebbe essere interamente incapsulata dalla classe. Tutti i suoi servizi dovrebbero essere strettamente allineati a tale responsabilità.

Se lo cerchi tra i risultati nella prima pagina di Google troverai due grandi risorse:

• " Principio della singola responsabilità " di Robert C. Martin (febbraio 2002): questo principio discute la necessità di collocare le cose che cambiano per ragioni diverse in classi diverse.
• " Curly's Law: Do One Thing " di Jeff Atwood (Mar / 2007): Il principio di responsabilità singola afferma che una classe dovrebbe avere una, e una sola, ragione per cambiare.

Cos'è la coesione nell'informatica?

La coesione è una misura di quanto siano fortemente correlate o focalizzate le responsabilità di un singolo modulo. Come applicato alla programmazione orientata agli oggetti, se i metodi che servono la classe data tendono ad essere simili in molti aspetti, allora si dice che la classe abbia un'alta coesione. In un sistema altamente coeso, la leggibilità del codice e la probabilità di riutilizzo sono aumentate, mentre la complessità è gestibile.

La coesione diminuisce se : - Le funzionalità incorporate in una classe, cui si accede attraverso i suoi metodi, hanno poco in comune. - I metodi svolgono molte attività varie, spesso utilizzando insiemi di dati a grana grossa o non correlati.

Gli svantaggi della bassa coesione (o "debole coesione") sono: - Maggiore difficoltà nella comprensione dei moduli. - Maggiore difficoltà nel mantenere un sistema, perché le modifiche logiche nel dominio influiscono su più moduli e perché le modifiche in un modulo richiedono modifiche nei moduli correlati. - Maggiore difficoltà nel riutilizzo di un modulo perché la maggior parte delle applicazioni non necessita del set casuale di operazioni fornito da un modulo.

Se avete domande fatemi sapere.

Decomponi le caratteristiche nell'elemento più piccolo possibile. Ad esempio, un singolo campo in un modulo. Scegli quello più rischioso o prioritario e vai avanti come se fosse una semplice correzione di bug, non un grande progetto. È vero che finirai con qualche refactoring in seguito, ma almeno andrai avanti.

Dalla mia esperienza hai risposto alla tua stessa domanda con il commento su TDD. Per me mi sono sentito spesso lo stesso di te, il rapido successo iniziale si è rapidamente impantanato in dettagli minori una volta che il sistema ha raggiunto una certa dimensione. Ho scoperto che TDD mi ha aiutato perché potevi affrontare ogni parte del sistema come piccoli blocchi, sapendo che il resto del sistema avrebbe o avrebbe dovuto continuare a funzionare mentre lo lasciavi. Penso anche che con TDD sia utile assicurarsi che il sistema sia chiaramente suddiviso in blocchi più piccoli che sono testabili indipendentemente.

Alcune persone sono brave a progettare programmi modulari e facilmente comprensibili, ma la maggior parte dei programmatori non ha questa possibilità, in misura minore o maggiore. Conosco un libro, una procedura o una pratica che possono trasformare uno dei primi tipi di programmatori nel secondo, tranne forse per molta esperienza. Ma non ne sono nemmeno sicuro.

La linea di fondo è che la maggior parte dei programmatori farà fatica a superare il mediocre, alcuni riusciranno a stare bene (che è il posto in cui vorrei collocare me stesso e forse il 50% dei programmatori professionisti nel (diciamo) settore IB), e molto la piccola minoranza sarà eccellente. Devo dire che nella mia lunga carriera non ho mai incontrato uno di questi eccellenti :-)

Penso che molte persone provino a progettare troppo le soluzioni. Adottano l'approccio "Adamo ed Eva" quando solo uno leggermente più pratico semplificherebbe notevolmente le cose.

Le classi specializzate non sono cattive, sono la naturale conseguenza della progettazione di software audio.

Molti programmatori, a mio avviso, non riescono a capirlo e non c'è nessun libro di cui sia a conoscenza che lo chiarisca chiaramente.

Un'altra cosa che sicuramente aiuta è il TDD, che ti permette di capire "come" utilizzerai la classe in pratica e può in molti casi salvare la giornata, perché mostra eventuali problemi / limitazioni all'inizio della giornata.

Infine, un'altra cosa MOLTO importante che vorrei cercare se fossi in te sono i modelli di progettazione. I modelli di progettazione sono il modo in cui le persone più intelligenti di te o di me risolvono i problemi di programmazione. L'idea alla base di schemi, indovina un po '?, è che non devono essere usati come libri di cucina, ricette che devi solo sbattere lì, ma pensosamente e prima di tutto capire il dominio dell'applicazione.

Un uso saggio del modello ridurrà notevolmente la quantità di dettagli che devi gestire.

Una buona libreria di modelli di design progettata intorno alle tue esigenze, si rivelerà preziosa. Vediamo un esempio molto semplice solo per mettere le cose nel contesto:

immagina di avere un modulo in cui, quando si preme un pulsante, altri moduli devono aggiornarsi. Questo è un tipico schema "osservatore". Hai un soggetto e diversi osservatori, che li registrano con l'argomento. Perché è necessario implementare un'interfaccia? Puoi semplicemente aggiungere i metodi o, meglio ancora, utilizzare un'interfaccia per gli osservatori e un elenco generico per l'argomento. Ora hai il meglio di entrambi i mondi: indipendenza per gli osservatori e niente cose bizzarre sull'argomento.

Spero abbia senso per te!

Andrea

Il problema della velocità e della leggibilità degli sviluppatori può sorgere quando trascuriamo la necessità di astrazione. In alcune delle basi di codice di grandi dimensioni in cui ho lavorato, il singolo nemico più comune era l'ennesima quantità di classi specializzate con funzionalità molto simili che causano il gonfiamento del codice. Se facciamo un passo indietro e comprendiamo i requisiti nel loro insieme e non come parti dell'applicazione, allora ci verranno in mente molte astrazioni.

Alcuni semplici passaggi che mi hanno aiutato

• Utilizzare l'analizzatore di somiglianza (come Simian) per trovare blocchi di codice duplicati nella base di codice. Un sacco di codice duplicato significa meno astrazione.
• Monitora le dimensioni di classi e metodi, grandi classi e metodi significano che pochi servizi o controller diventano divinità.
• Rendi obbligatori i test unitari / di integrazione, ti dà la sicurezza di refactoring e funge anche da specifica.
• Retrospettiva quindicinale con l'azienda per capire se i termini tecnici / commerciali / di dominio che usano si riflettono nei nomi delle classi. Questo aiuta a comprendere e ottenere nomi per raccolte di prima classe invece di rappresentare come semplici set ed elenchi. Alcune astrazioni a cui non abbiamo mai pensato emergeranno anche quando ci sediamo con gli uomini d'affari.