Come aiutare i programmatori a utilizzare le classi condivise esistenti, invece di reinventarle? [duplicare]

Le classi esistenti sono ben organizzate? Se si guarda ad una libreria ben progettata, è generalmente abbastanza facile capire se esiste una classe o un metodo per fare qualcosa perché la classe esiste più o meno dove ci si aspettava che fosse o meno. D'altra parte, molte librerie mal progettate non sono organizzate in un modo che abbia senso per le persone che cercano di usarle, il che rende difficile scoprire le funzionalità. Ad esempio, se hai un cestino di oggetti "utility varie", sarà molto difficile per le persone trovare quello che stanno cercando.

Gli sviluppatori senior stanno aiutando gli sviluppatori junior ad apprendere la base di codice o semplicemente a lanciarli ai lupi ea catturare le cose una volta che il codice è già stato sviluppato ed è pronto per la revisione? Se assegnerò un'attività ad uno sviluppatore junior, mi aspetterei che, se so che ci sono pezzi di codice che possono essere sfruttati, menzionerei la loro esistenza. Ha senso nel whiteboarding iniziale della soluzione che lo sviluppatore senior menzioni che lo sviluppatore junior dovrebbe usare il nuovo framework di gestione dei messaggi appena promosso o che la classe di generazione di file esiste già e deve solo essere cablata.

Gli sviluppatori e i project manager si basano sulle prime indicazioni che le ruote vengono reinventate? Se uno sviluppatore junior ottiene un'attività che mi aspetto di prendere un paio di giorni perché il 90% del codice è già stato scritto e le classi appropriate devono essere chiamate e lo sviluppatore stima che ci vorranno 2 settimane, questo dovrebbe indicare una strong possibilità che lo sviluppatore junior stia progettando di costruire ruote che già esistono. Quando accade questo tipo di disconnessione, è utile capire perché c'è una divergenza nelle stime. Mentre il codice è in fase di sviluppo, lo stato riporta le riunioni stand-up e le chatter generali possono farti sapere che uno sviluppatore sta spendendo più tempo su qualcosa di quel che "dovrebbe", il che spesso indica che stanno reinventando la ruota. Uno sviluppatore senior che origlia uno sviluppatore minore che cerca di risolvere un problema con il salvataggio di file dovrebbe sospettare che lo sviluppatore minore non stia utilizzando la ben collaudata classe di salvataggio dei file e offra assistenza.

Oltre a ciò, puoi certamente generare ulteriore documentazione che aiuta le persone a usare la tua biblioteca di classi in modo più efficace. Un wiki che attraversa attività comuni e spiega il modo in cui desideri che quelle attività vengano gestite in un nuovo sviluppo, ad esempio, può essere un'ottima risorsa. La mia preferenza sarebbe quella di considerare i miglioramenti del processo in primo luogo semplicemente perché un'altra fonte di documentazione in un ambiente che ha problemi con il processo di sviluppo tende a diventare un'altra cosa che diventa obsoleta una volta che l'entusiasmo iniziale si attenua. Ma se stai facendo tutto il possibile dal punto di vista del processo, la documentazione aggiuntiva può essere molto utile.

Oltre a "progettare bene le tue librerie e metterle in un luogo logico dove le persone si aspetterebbero da loro", la revisione è in realtà un modo di condividere la conoscenza. Prima la recensione di sviluppatori più esperti, meglio è. Hai preso in considerazione la programmazione delle coppie? È ottimo per condividere rapidamente molte informazioni su codifica, progettazione e dominio. È, infatti, una recensione molto presto.