Posso scrivere codice ... ma non posso progettare bene. Eventuali suggerimenti? [chiuso]

L'unico modo per diventare veramente bravi in qualcosa è provare, fallire in modo spettacolare, riprovare, fallire di nuovo un po 'meno di prima e nel tempo sviluppare l'esperienza per riconoscere quali sono le cause dei guasti in modo da poter gestire potenziali situazioni di fallimento più tardi. Questo è vero per imparare a suonare uno strumento musicale, guidare un'auto, o guadagnare qualche seria età PWN nel tuo sparatutto in prima persona preferito, in quanto è di imparare qualsiasi aspetto dello sviluppo del software.

Non ci sono scorciatoie reali, ma ci sono cose che puoi fare per evitare che i problemi sfuggano di mano mentre stai facendo esperienza.

• Identifica un buon mentore . Non c'è niente di meglio che essere in grado di parlare dei tuoi problemi con qualcuno che ha già pagato i suoi debiti. La guida è un ottimo modo per aiutare l'apprendimento rapido.
• Leggi , leggi di più, esercitati su ciò che hai letto e ripeti per tutta la vita della tua carriera. Ho fatto queste cose per più di 20 anni e continuo a imparare qualcosa di nuovo ogni giorno. Impara non solo sulla parte anteriore del design, ma anche su design emergente, test, best practice, processi e metodologie. Tutti hanno diversi gradi di impatto sul modo in cui i tuoi progetti emergeranno, prenderanno forma e, ancora più importante, su come dureranno nel tempo.
• Trova il tempo di Tinker . O sei coinvolto con un progetto skunkwork attraverso il tuo posto di lavoro, o fai pratica nel tuo tempo libero. Questo va di pari passo con la tua lettura, mettendo in pratica le tue nuove conoscenze e vedendo come funzioneranno queste cose. Questo è anche il materiale che rende possibile una buona discussione con il tuo mentore.
• Ottieni coinvolto in qualcosa di tecnico esterno del tuo luogo di lavoro. Questo potrebbe essere un progetto o un forum. Qualcosa che ti consenta di testare teorie e idee al di fuori della tua cerchia ristretta di pari, al fine di mantenere una nuova prospettiva sulle cose.
• Sii paziente . Riconosci che l'esperienza di guadagno richiede tempo e impara ad accettare il fatto che hai bisogno di arretrare per un po 'per imparare perché e dove hai fallito.
• Mantieni un diario o un blog dei tuoi compiti, i tuoi pensieri, i tuoi fallimenti e i tuoi successi. Questo non è strettamente necessario, tuttavia ho scoperto che può essere di grande beneficio per te vedere come ti sei evoluto nel tempo, come sono cresciute le tue abilità e i tuoi pensieri sono cambiati. Rientro nei miei diari ogni pochi mesi e guardo le cose che ho scritto 4-5 anni fa. È una vera scoperta per scoprire quanto ho imparato in quel momento. È anche un promemoria che mi sono sbagliato di tanto in tanto. È un promemoria salutare che mi aiuta a migliorare.

Bene, non esiste una mela d'oro per questo tipo di domanda, e penso che forse è proprio per ogni programmatore stesso trovare ciò che è giusto per lui. Ecco la mia versione, comunque.

potresti leggere libri sull'argomento. Grandi libri. Libri fantastici Ma trovo che questi libri ti aiutino solo una volta che hai provato a creare e progettare un'applicazione - e non ci sono riuscito.

Per me, è tutta una questione di esperienza. Quando ho iniziato come novellino ho letto libri su come progettare. All'epoca non ho capito molto del contenuto. Quando ho iniziato a lavorare e ho dovuto progettare personalmente le applicazioni, ho creato applicazioni molto complicate. Lavoravano, ma erano dolorosi da mantenere. Poi ho letto di nuovo quei libri - e questa volta li ho capiti meglio.

Ora continuo a commettere nuovi errori e ad imparare dai vecchi.

Smetti di progettare e impara a codice refactoring. Lo sviluppo incrementale con refactoring continuo e aggressivo si tradurrà in un prodotto finale molto più pulito rispetto a qualsiasi progetto iniziale.

Leggi di schemi, certo, ma prima di tutto leggi sugli anti-pattern. Riconoscere gli anti-schemi è importante, ed è più facile capire perché qualcosa non dovrebbe essere fatto in questo modo rispetto al perché dovrebbe.

Vedi link per esempio.

Scrivi il codice in modo che possa essere regolato rapidamente se i requisiti cambiano (che è molto comune nell'ambiente di produzione).

Sii super scettico sull'aggiunta di "un altro piccolo trucco". Un altro qui, un altro lì, e il codice diventa non modificabile.

Valore principio aperto / chiuso .

Scrivi test (come in TDD). Ti costringono a pensare al tuo design prima ancora di realizzarlo.

Sfoglia il codice dei progetti open source (quelli di dimensioni ragionevoli, cioè). Ero solito essere sorpreso - di solito - vedendo così tanti livelli di astrazione. Ora capisco che non è arte per l'arte, c'è un motivo per cui è fatto in questo modo.

Un principio che trovo molto importante per una buona progettazione è la decomposizione: se una classe è troppo grande (più, ad esempio, 300-400 linee di codice) suddividila in classi più piccole; se un metodo è troppo grande (per esempio più di 50 righe di codice) lo decomponi; se un progetto contiene più di 50 classi, decomponilo.

La chiave è stimare la dimensione del tuo sistema e costruire diversi livelli di astrazione (ad es. sottosistema, applicazione, progetto, modulo, classe, metodo) che ti permettono di scomporre il tuo codice in unità comprensibili con chiare relazioni tra loro e poche dipendenze .

È difficile, ciò di cui stiamo parlando è un'abilità di astrazione piuttosto che creare codice migliore, ma due cose ti renderanno migliore e una cosa ti renderà più felice:

"Meglio"

A) Trova il miglior designer che puoi e abbina il programma / fai un disegno insieme. Chiedigli di spiegare cosa stanno pensando mentre affrontano il problema, non accontentarti di "sembra giusto" e continua a scavare. Questo processo aiuterà anche il "mentoring"

B) Immagina tutto come singoli attori e conversazioni tra di loro. Ciascuno degli attori dovrebbe avere un unico ruolo / responsabilità e gruppi di loro gestiscono sistemi diversi. Se quella conversazione funziona e ogni attore si sente coerente e coeso, allora sei sulla buona strada.

E "Più felice"

C) Se hai fatto del tuo meglio e non succede ancora, non c'è niente di sbagliato nell'accettare che alcune persone non possono fare qualcosa. Potresti scrivere codice chiaro e brillante, ma non essere mai in grado di progettare o architetto. E allora? Non posso praticare sport fisici per il caramello, non sono bello e la mia guida in auto non sarà mai migliore della media. Revel e utilizza ciò in cui sei bravo.

Nella mia esperienza personale, leggere il codice degli altri è una buona fonte di "ispirazione". Voglio dire, cercare di capire i disegni degli altri e chiedersi perché fa le cose in quel modo?

puoi trovare molti progetti open-source per la ricerca.

comunque ti serve la pratica.

Non vivere nella paura

Cerca la semplicità

Ascolta i tuoi utenti

Prova molte idee

Crea qualcosa, quindi rendilo migliore

Lavorare su cose che aggiungono valore, abbandonare cose che non lo fanno

Impara a fare le domande giuste. Molto spesso migliorerai il tuo design osservando il problema da una diversa angolazione. In particolare questo ti aiuterà ad allontanarti dal concentrarti sulla risoluzione del problema in questione e cercare più soluzioni che risolvono più problemi correlati.