Ho più di 20 anni di esperienza e sono profondamente pigro. Lavoro su molte piattaforme.
Il modo in cui leggo e capisco il codice di qualcun altro è principalmente con le dita.
Perché sì, sono il bambino a cui viene sempre detto di non guardare con le dita. Sto per sempre toccando i segni che dicono di non toccare.
Ho la fortuna di lavorare in un negozio dove facciamo test. Quando arriva il momento per me di capire il codice di qualcun altro, non lo leggo. Lo gestisco Lo collaudo. Corro i vecchi test per questo. I più piccoli che riesco a trovare. Scrivo nuovi test per questo. Faccio domande a riguardo. Sfido il codice in tutti i modi in cui riesco a pensare. Da qualche parte lì dentro trovo il tempo per leggerlo e ridere delle bugie che chiamiamo commenti. Solo una volta che ho fatto tutto ciò, comincio a pensare che potrei capirlo. Questo è quando comincio a refactoring. Lo cambio per essere qualcosa di diverso da quello che era, pur non cambiando ancora quello che fa. Lo faccio per rendere più semplice l'aggiunta di una nuova funzione o per prepararmi a far sparire un vecchio bug. Dopo aver aggiunto test che mostrano le mie intenzioni, apporto le mie modifiche. Cerco anche altre piccole modifiche da apportare in modo che possa lasciarlo un po 'più bello di come l'ho trovato. Poi vado a fare qualcos'altro e, per un po ', dimentico che questo codice esiste.
La capacità di farlo è perché mi interessa dei test. I test mi aiutano a leggere il codice. I test non dimostrano che il tuo programma fa ciò che dovrebbe fare. Mostrano cosa fa in realtà. Devi capire se questo è quello che dovrebbe fare.
Quando sei nuovo è così allettante da trovare modi di pensare pigri. Uno dei più dannosi è concentrarsi sulla meccanica e sulla struttura. È molto meglio concentrarsi sulle idee. Per aiutarti in questo, lascia che ti insegni un modello davvero valido per sapere quando apprendi i test. Si chiama oggetto umile .
Qualcuno della mentalità meccanica / strutturale insisterà su ogni classe, ogni metodo, sarà sotto esame o insisterà sul fatto che il test non funzioni ed è una perdita di tempo. Diranno che l'unico buon numero di copertura del codice è del 100% o che la copertura del codice è una fantasia inutile e irraggiungibile. Tutto ciò è vero, per qualcuno che la pensa in questo modo.
Il modello di oggetto umile appena fuori ammette che esiste una cosa difficile da testare il codice. Questo è molto salutare da capire. A volte il problema non sei tu. È il codice richiesto dal problema.
Nulla è completamente non testabile, ma piuttosto che lanciare ogni magico trucco di derisione e riflessione sul codice per testarlo così come lo è l'umile modello di oggetto che si aspetta che noi facciamo un po 'di re-architecting. Modifichiamo il codice per separare il comportamento testabile dal codice di colla strutturale non interessante che francamente non ha bisogno di test. Perché? Perché il test riguarda la comprensione del codice.
Questo è esattamente il motivo per cui visualizzazioni e relatori non sono la stessa cosa. Le view, supportate dai presentatori, hanno rimosso il loro interessante comportamento. Non sono altro che noiosi codici strutturali. Le decisioni interessanti stanno accadendo tutti nei presentatori. Testiamo i presentatori. Non testiamo le visualizzazioni.
Le visualizzazioni e i presentatori non sono gli unici posti in cui lo facciamo. Tutto ciò che ha una meccanica noiosa deve essere cablato può beneficiare del modello di oggetto umile. Parlando con il DB, un servizio, un chip, un driver, tutto può finire con questa stessa dinamica. Offri loro il cablaggio di cui hanno bisogno e raschia via qualsiasi comportamento interessante che l'app deve esibire in un bel modulo testabile che dimostra che il comportamento è quello di cui abbiamo bisogno.
In questo modo è possibile incorporare qualsiasi comportamento necessario nel codice testabile indipendentemente da qualsiasi esigenza meccanica o strutturale di creare codice difficile da testare. In questo modo puoi concentrarti sulla tua vera idea.
Ci sono molte cose da studiare per aiutarti a sviluppare le tue capacità di test, ma capire perché non tutti i grumi di codice accolgono i tuoi sforzi di test, o anche i loro bisogni, sono in cima alla mia lista.