smetti di pensare al codice

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

sei sopraffatto perché stai pensando a un livello troppo basso

Decompone le funzionalità nel più piccolo oggetto possibile. Ad esempio, un singolo campo su un modulo. Scegli quello più rischioso o ad alta priorità e vai avanti come se fosse una semplice correzione di bug, non un grosso progetto. È vero che in seguito ti ritroverai con qualche refactoring, ma almeno andrai avanti.

Dalla mia esperienza hai risposto alla tua stessa domanda con il commento su TDD. Per quanto mi riguarda, mi sono sentito spesso come te, il rapido successo iniziale si è rapidamente trasformato in impotenti dettagli quando il sistema ha raggiunto una certa dimensione. L'ho trovato con TDD perché mi ha aiutato perché potevi affrontare ogni parte del sistema come piccoli pezzi, sapendo che il resto del sistema avrebbe o avrebbe dovuto continuare a funzionare come lo avevi lasciato. Penso anche che, con TDD, aiuti a garantire che il tuo sistema sia chiaramente suddiviso in blocchi più piccoli che sono testabili in modo indipendente.

Alcune persone sono brave a progettare programmi modulari e facilmente comprensibili, ma la maggior parte dei programmatori manca di questa funzionalità, in misura minore o maggiore. So di non conoscere nessun libro, procedura o pratica che possa trasformare uno dei primi tipi di programmatori nel secondo, tranne forse per molti di esperienza. Ma non ne sono nemmeno sicuro.

La linea di fondo è che la maggior parte dei programmatori farà fatica a superare il mediocre, alcuni riescono a essere OK (che è il posto in cui mi posizionerei e forse il 50% dei programmatori professionisti in (per esempio) l'industria IB), e una piccolissima minoranza sarà eccellente. Devo dire che nella mia lunga carriera non ho mai incontrato uno di questi eccellenti: -)

Penso che molte persone provino a ingegnerizzare le soluzioni. Prendono l'approccio "Adam & Eve" quando solo un po 'di più quello pratico semplificherebbe molto le cose.

Le lezioni specializzate non sono malvagie, sono naturali conseguenza del design del software sonoro.

Molti programmatori, a mio parere, non riescono a capire questo e non esiste un libro che io conosca che lo renda chiaro.

Un'altra cosa che sicuramente aiuta è TDD, che ti permette capire "come" userete la classe nella pratica e potete farlo molti casi salvano il giorno, perché mostra eventuali problemi / limitazioni all'inizio della giornata.

Infine, un'altra cosa MOLTO importante che cercherò se fossi in te sono gli schemi di progettazione. I modelli di progettazione sono il modo in cui le persone più intelligenti di te o me risolvono i problemi di programmazione. L'idea dietro i modelli, indovina un po '?, è che non devono essere usati come libri di cucina, ricette che semplicemente sbatti lì, ma pensierosamente e capendo il tuo prima e soprattutto il dominio delle applicazioni.

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

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

Immagina di avere un modulo in cui, quando viene premuto un pulsante, altri moduli devono essere aggiornati loro stessi. Questo è un tipico schema di "osservatore". Hai un soggetto e diversi osservatori, che si registrano con il soggetto. Perché hai bisogno di implementare un'interfaccia? Puoi semplicemente aggiungere i metodi, o meglio ancora, usa un'interfaccia per gli osservatori e un elenco generico per il soggetto. Ora hai il meglio di entrambi i mondi: indipendenza per gli osservatori e no cose whuzzy-whazzy sull'argomento.

Spero che abbia senso per te!

Andrea

Il problema della velocità di sviluppo e della leggibilità potrebbe verificarsi quando trascuriamo la necessità di astrazione. In alcune delle grandi basi di codice che ho lavorato, il singolo nemico più comune era l'ennesima quantità di classi specializzate che hanno funzionalità molto simili che fanno gonfiare il codice. Se facciamo un passo indietro e comprendiamo i requisiti nel loro complesso non come parti dell'applicazione, ci verranno in mente molte astrazioni.

Alcuni semplici passaggi che mi hanno aiutato

• Utilizza l'analizzatore di similarità (come Simian) per trovare i blocchi di codice duplicati attraverso la base di codice. Un sacco di codice duplicato significa meno astrazione.
• Monitora le dimensioni di classi e metodi, classi e metodi di grandi dimensioni significano pochi servizi o controller che diventano dei.
• Rendi obbligatori i test di unità / integrazione, ti dà fiducia nel refactoring e agisce anche come specifica.
• Retrospettiva quindicinale con l'azienda per capire se i termini tecnici / aziendali / di dominio che utilizzano si riflettono nei nomi delle classi. Questo aiuta a comprendere e ottenere nomi per collezioni di prima classe invece di rappresentare semplici insiemi ed elenchi. Alcune astrazioni che non abbiamo mai pensato emergeranno anche quando ci sediamo con gli uomini d'affari.