Come guida, mi trovo regolarmente ad affrontare situazioni in cui so che un particolare problema dovrebbe essere affrontato o fatto (o non fatto) in un modo particolare. Di solito scelgo una delle seguenti opzioni per gestire la situazione.

• Detti che non risolveremo / non risolveremo il problema in un modo particolare.
• Lascia che facciano l'errore, perché l'esperienza dell'errore è preziosa. Iff non costerà molto tempo / denaro.
• Spiega perché c'è un problema. Usa gli esempi per convincere l'altra persona.

Non ho quasi mai dettato un programmatore. Penso che sia cattiva forma, cattive maniere e indicativo di altri problemi. Se c'è una situazione di rottura / correzione, non abbiamo davvero il tempo di parlare del problema, riguarda l'unica volta in cui sovrascriverò qualcuno e dirò loro cosa fare (non farlo). Potrei anche ignorare qualcuno se non riesco a convincerli del costo, e il costo è significativo. Vedo quelle situazioni come i miei difetti.

Occasionalmente faccio in modo che i programmatori commettano i propri errori. In realtà ho trovato un'esperienza di apprendimento che è il miglior insegnante se vedono le conseguenze di ciò che hanno fatto.

Di solito provo a spiegare il problema usando un esempio. Provo a sottolineare il costo o l'impatto negativo. Alcuni saranno concreti, mentre altri costi potrebbero essere deboli (per esempio il morale della squadra). Incoraggio la dialettica; Voglio che litighino anche per i loro punti. In quei casi in cui i benefici fuori pesano i costi del problema sarò influenzato.

Caratterizzare il problema può essere la parte difficile. La maggior parte dei problemi è un problema perché hanno un impatto o un costo negativo. Alcuni sono facili da evidenziare e pertanto solitamente è facile convincere le persone che sono un problema. Alcuni problemi hanno un leggero impatto negativo in corso o costi e possono essere difficili da vedere. Altri ancora che potresti conoscere sono un problema, ma potresti non essere in grado di spiegarne il motivo.

Ho avuto un grande successo nell'insegnare altri programmatori quando ho un buon esempio che mostra il costo del problema. Anche con costi di gestione contenuti, un esempio è molto importante per aiutare almeno gli altri a capire cosa stai guardando e perché. Non essere in grado di spiegare perché qualcosa è un problema è male. A volte risulta che non è davvero un problema, altre volte lo è. In entrambi i casi l'onere è sul programmatore per fare un argomento convincente.

Ci sono molti motivi per cui le migliori pratiche non vengono sempre seguite:

Non vita o morte

La sfortunata verità dello sviluppo web è che in molti casi i prodotti che sviluppiamo non implicano la vita o la morte. Pertanto, alcune delle migliori pratiche intese a produrre prodotti di qualità e mantenibili al 100% non sono sempre rispettate.

Modifiche tecnologiche veloci

La tecnologia cambia a un ritmo incredibile. Qual è una buona pratica oggi potrebbe non essere una buona pratica in sei mesi. Le migliori pratiche riguardano il continuo chiedersi a te stesso come un'organizzazione ciò che puoi fare meglio.

Obiettivi aziendali

Molte volte, gli obiettivi di progettazione di un progetto possono dettare che la velocità è una necessità per entrare in un nuovo mercato. In alcuni casi, la differenza tra fermarsi ad annusare le rose e assicurarsi che tutte le tue ipotetiche t siano incrociate e io sono punteggiate può significare che i tuoi concorrenti stanno innovando.

Nel frattempo, hai un prodotto che ritieni sia giusto per il mercato, ma non lo sai perché non lo hai ancora pubblicato.

Sebbene il rilascio anticipato di questo prodotto possa comportare una manutenzione costosa, a volte la domanda è più costosa, con la perdita di un contratto o di un'opportunità di mercato o dopo aver eliminato alcuni problemi in seguito.

Cultura aziendale

Questo a volte coincide con gli obiettivi di business. Alcune aziende, come le start-up, ne fanno un punto di essere i primi ad entrare in un mercato. Ciò comporta un livello di spietatezza come sviluppatore, perché l'obiettivo tenuto nella tua mente deve sempre essere velocità, velocità, velocità.

In sintesi, stai chiedendo quali sono le nostre migliori pratiche, ma sembra anche che tu chieda, indirettamente, che cosa fanno gli altri per mantenere le migliori pratiche.

La linea di fondo è che se sono coinvolti obiettivi aziendali, è meglio non dondolare la barca. Ma se è la pigrizia o la mancanza di consapevolezza, o se è solo il tempo di aggiornare alla più recente best practice, allora il meglio che puoi fare è continuare a educare gli altri e usare le tue capacità di persuasione per creare supporto.

Una delle abilità più importanti per uno sviluppatore è la capacità di comunicare le proprie idee e di essere un leader tecnico. Senza grandi comunicazioni, andare avanti con la tua agenda sarà più difficile di quanto non sia già.

Buona fortuna!

La programmazione di coppie è una tecnica specificamente progettata per facilitare il trasferimento di questo tipo di informazioni.

In un ambiente di programmazione a coppie, il più esperto dei due programmatori ha accesso diretto a un sistema live e può segnalare errori e problemi mentre si presentano - dando l'opportunità di evidenziare le conseguenze negative e comunicare più facilmente ciò che è stato appreso attraverso l'esperienza.

Mostra Them The Pain

Hai imparato dall'esperienza. L'esperienza deriva dal dolore degli errori. Mostrami i punti deboli e ci sono buone probabilità che impari le stesse lezioni.

buona fortuna!

Non penso che sia una lacuna di esperienza tanto quanto la riluttanza di qualcuno a imparare o accettare cose nuove.

Il rovescio della medaglia è che la persona che "insegna" è davvero pessima nella comunicazione e non può dimostrare efficacemente perché una metodologia è migliore di un'altra.

Mi rendo conto che è piuttosto lungo quindi farò una versione tl; dr. Abbiamo bisogno di interrompere l'hand-waving e di utilizzare esempi concreti.

Quindi posso riguardare ciò che hai detto. Sono entrato in una guerra di fuoco involontaria e sono stato accusato di essere un troll quando ho chiesto sulla mailing list di Alt.NET che qualcuno mi spiegasse che cosa ha reso Nibernate nella loro esperienza un O / RM migliore rispetto al Entity Framework originale. Nessuno poteva dare una risposta migliore di "è solo".

Dopo che EF ha introdotto il codice prima, ho visto la differenza. Questo era ciò a cui gli utenti di nibern sono abituati da un po 'di tempo. Una volta che non devi eseguire trucchi per togliere l'O / RM, il codice scorre molto meglio.

Attualmente sto scrivendo un libro su MVVM perché vedo lo stesso problema. Ci sono molte persone che la guardano e dicono "Io proprio non capisco, perché dovrei passare attraverso tutti quei guai?" Ce ne sono altri che fanno il pieno su MVVM senza capire pienamente perché lo stanno facendo (e in molti casi ho visto finire male). Il mio obiettivo è fornire loro l'esperienza di "scoprire" MVVM da soli.

Ho usato questo approccio per aiutare a introdurre schemi per gli sviluppatori junior. Li ho avviati con un modello di base per implementare le funzionalità e lasciarli arrivare alla codifica. Alla fine qualcuno avrebbe detto "Sai che mi sto davvero stancando di fare [X]". E ho colto l'occasione per presentarli a un modello che risolveva il loro problema.

È difficile discutere i vantaggi di un particolare approccio allo sviluppo senza avere un esempio concreto di pori. Il codice è già abbastanza astratto senza fare molti gesti.

Se guardi Acquisizione di modelli Dreyfus per le competenze c'è una grande differenza tra un principiante e un esperto. Indipendentemente da quanta esperienza hai nel software, c'è sempre qualcosa in cui sei un principiante. Quando tu (o io) come novizio ci avviciniamo a qualcuno che è un esperto di quella specifica competenza e chiediamo loro di spiegare perché fanno le cose nel modo in cui lo fanno, può essere difficile per l'Esperto capire da dove vieni. L'esperto ha probabilmente dimenticato da tempo com'era prima di iniziare a fare le cose come fa lui. La discussione può essere frustrante al meglio. Nel peggiore dei casi (come entrambi abbiamo visto) si trasforma in una guerra di fiamme.

Il modo di affrontare il problema è che molti di noi capiscano che c'è un salto di qualità da inesperto ad esperto e assumono una posizione meno antagonistica quando si discutono le idee. Il modo migliore per consolidare la tua conoscenza è aiutare qualcun altro a raggiungerlo.

Ho sempre preferito utilizzare i momenti "Considera i seguenti". Cioè, ponete loro una domanda che dimostri come / quando la pratica X si rompe. Quindi, dedica loro un po 'di tempo per pensare a come sistemarlo, prima di offrire una migliore pratica Y. Trovo anche utile evidenziare alcuni dei limiti di Y, ma mostrare comunque che rende più facile fare di più.

Tutti i modelli e i metodi hanno i loro punti di rottura in cui non sono più utili - alcuni si rompono prima di altri (causando più dolore prima).