Come posso praticare modelli di progettazione e refactoring in modo deliberato? [chiuso]

7

Stavo leggendo il libro Refactoring to patterns e mi chiedevo come avrei potuto avere la possibilità di praticare le abilità, perché senza deliberare pratica su nuovi modi per refactoring e utilizzare modelli, le mie capacità non miglioreranno.

Ma il lavoro d'ufficio mi richiede di terminare ogni attività il più rapidamente possibile. Il più delle volte, la progettazione e l'architettura del progetto non sono controllate da me, posso solo seguire lo stile simile al codice esistente. A volte c'è un progetto con un cattivo design, ma c'è anche un altro sviluppatore la cui abilità progettuale è migliore di me e ha già l'intero piano per rifattorizzare il progetto, così che sto solo seguendo il suo piano. Come ottengo opportunità di praticare?

    
posta rwong 26.05.2011 - 07:01
fonte

3 risposte

6

Per essere sinceri non vedi l'occasione di venire a bussare alla tua porta. Se sei molto propenso a praticare l'abilità sarebbe fantastico se tu potessi venire con i tuoi disegni indipendentemente da ciò che ha il cosiddetto sviluppatore più abile . Basta lanciare le tue idee e fare una bella conversazione su come il mio sarebbe utile per questo progetto di design scadente. Forse falliresti nei primi tentativi ma impareresti molto e (anche il tuo cosiddetto collega di sviluppatori più abile avrebbe anche qualcosa da imparare da te).

In breve, metti anche i tuoi progetti sul tavolo e scopri quanto sei bravo o no, non c'è modo di confrontare le tue capacità.

    
risposta data 26.05.2011 - 07:13
fonte
3

Pratica, pratica, pratica. I progetti di hobbistica sono sicuramente una buona idea. E se vuoi imparare, è spesso meglio lavorare sul progetto open source di qualcuno altro , in questo modo puoi imparare dai pattern che impiegano.

Suggerisco di esaminare codice dojos e codice katas . L'idea alla base di questo concetto è che praticando su problemi di pratica gestibili ben definiti, sarai meglio equipaggiato quando i problemi si presentano nel tuo codice. (I siti web lo spiegano meglio di quello che ho fatto, sicuramente li controllo.)

Punto laterale: una cosa essenziale che non è proprio un modello è abitudini corrette quando si tratta di test.

Inoltre, ultimo commento: il lavoro d'ufficio richiede di terminare ogni attività il più rapidamente possibile. Se lavori troppo velocemente e crei molti bug, non hai completato l'attività , poiché dovrai tornare indietro in seguito. Questa è una rielaborazione. Se non prendi il tempo necessario per imparare il modo corretto di fare le cose, creerai più lavoro per te stesso a breve termine e non imparerai i modelli appropriati per migliorare a lungo termine. Vale la pena sia per te che per il tuo datore di lavoro che tu pratichino modelli di progettazione adeguati. (Detto questo, gli schemi di progettazione possono spesso essere sfruttati e abusati da persone che li praticano in modo eccessivamente o senza comprensione di fondo, ma questo è un punto a parte.)

    
risposta data 26.05.2011 - 07:42
fonte
1

Penso che tu abbia le seguenti opzioni:

  • Considera di esercitarti in orario non lavorativo: stai semplicemente al lavoro e prova a eseguire il refactoring del codice senza applicare il codice a VCS. Per fare pratica deliberata non è necessario impegnare le modifiche. Devi riprodurre una procedura finché non diventa la tua seconda natura.
  • Prendi in considerazione la padronanza delle abilità comunicative per discutere con i tuoi colleghi di ciò che il refactoring è più appropriato. Crucial Conversation è davvero utile per comprendere i meccanismi di una comunicazione.
  • Progetto per animali domestici: crea un progetto per animali domestici e fai pratica con le tue abilità. Non ha bisogno di essere molto utile. L'obiettivo è praticare le abilità di programmazione.
  • Considera di proporre i tuoi servizi in un progetto open source - questo è più vantaggioso per la pratica deliberata in quanto puoi ottenere un feedback
risposta data 26.05.2011 - 11:26
fonte

Leggi altre domande sui tag