Dopo aver parlato con altre persone al lavoro e scavando da solo, ho scoperto che la denominazione fa o rompe l'approccio di molti piccoli metodi, e alcuni credono che il tuo collega non sia pazzo. Il principio della sorpresa minima è molto importante.
Con più oggetti c'è più spazio per introdurre codice ed effetti collaterali. Se vuoi sorprendere qualcuno, più classi significano più costruttori (possibilmente blocchi di inizializzazione statici e altre strutture simili) e più variabili di istanza. Se vuoi nascondere il codice e offuscarlo, più oggetti sicuramente ti aiutano. Mentre ogni singolo metodo e persino oggetto possono essere semplici, la loro grande somma tende ad essere più complessa. Inoltre se hai qualcosa come Spring che può anche introdurre effetti logici / collaterali aggiuntivi che hanno a che fare con il codice, è anche peggio ......
Anche nominare. Un problema che ho riscontrato è spesso un metodo che dice DoesX, ma in realtà il metodo fa x, y, z, a, b, c. Quindi ho difficoltà a ragionare su cosa fa qualsiasi codice. In pochi metodi giganti, osserveresti i metodi e vedrai un mucchio di codice che fa cose inaspettate che i tuoi occhi potrebbero notare ed essere come il WTF. Probabilmente dovresti individuare il codice per y, z, a, b, c. Leggendo gli oggetti split leggerai il codice che dice DoesX e prima supponi che faccia X. Poi più tardi quando ancora non capisci cosa sta succedendo e inizi a leggere tutto ciò che alla fine arrivi a DoesX e vedi oh sta facendo y, z, a ,avanti Cristo. Ma se i metodi sono denominati correttamente, allora le cose funzionano meglio perché spesso puoi capire cosa sta succedendo senza nemmeno leggere i metodi. Se DoesX fa semplicemente X, puoi andartene senza leggerlo a meno che X non sia rotto.
Ho notato che sebbene usiamo Java, e tramite il cablaggio Spring qualsiasi oggetto può essere realmente collegato a un'interfaccia, tendono a saltare tra le classi usando la navigazione di Eclipse. Se c'è un'interfaccia, tendono a usare eclissi per mostrare tutte le implementazioni (generalmente solo 1) e poi saltare ad essa. In realtà, Spring potrebbe implementare un'implementazione da qualche altra libreria o fare qualcosa che non ti aspetti (cosa che in pochissimi casi accade), ma in generale si basano solo su cose da fare nel modo previsto. Ho persino trovato un'estensione di implementazione aperta per farmi fare clic su un metodo su un'interfaccia e passare automaticamente alla versione della classe di implementazione. Ancora alcuni posti sono un disastro e non funzionano come previsto. Ma quelli sono generalmente considerati codici errati e candidati per una riscrittura. Inoltre ci sono alcune tecniche di progettazione che sono conoscenze comuni in azienda, quindi riconoscere queste tecniche aiuta anche a capire. Non sono documentati da nessuna parte, ma dopo essere stati come il WTF e averli letti, vedo di nuovo la stessa tecnica e la riconosco immediatamente. Ancora una volta ... qualcuno potrebbe fare cose inaspettate per pasticciare con te.
Martin Vejmelka è una sorta di test unitario menzionato come un modo per sapere che il codice sta funzionando bene. Ho intervistato in un luogo che utilizzava test unitari come questo, come modi per affermare il codice che stava facendo. Quando si eseguiva il debug della propria tecnica, era necessario pensare a quali asserzioni dovevano essere errate perché il comportamento si verificasse, quindi creare test unitari con il comportamento previsto che non riesce, quindi correggerli. Al mio posto attuale hanno dei test unitari ma non coprono tutto il codice, e soffrono anche di enormi quantità di indirezione, rendendo la lettura dei test unitari impegnativa come leggere il codice, e talvolta anche più difficile.