Come spiegare perché le scelte di design sono buone? [chiuso]

Dato che sono diventato uno sviluppatore migliore, trovo che gran parte delle mie capacità progettuali provengono più dall'intuizione che dall'analisi meccanica. Questo è fantastico Mi permette di leggere il codice e di sentirlo più velocemente. Mi permette di tradurre i disegni tra lingue e astrazioni molto più facilmente. E mi permette di fare le cose più velocemente.

Il rovescio della medaglia è che trovo più difficile spiegare ai compagni di squadra (e peggio, alla direzione) perché un particolare design sia vantaggioso; soprattutto i compagni di squadra che sono in ritardo sulle migliori pratiche. "Questo design è più testabile!" o "Dovresti favorire la composizione rispetto all'eredità". andare oltre le loro teste e condurre nella mia tana di coniglio cercando di indurre tutti nell'ultimo decennio di progressi nell'ingegneria del software.

Ci riuscirò meglio con la pratica ovviamente, ma nel frattempo comporta un sacco di tempo sprecato e / o cattivo design (che porterà a perdere tempo a ripararlo in seguito). Come posso spiegare meglio perché un determinato design è superiore, quando i benefici non sono completamente evidenti per il pubblico?

Questo potrebbe non rispondere direttamente alla tua domanda, ma potrebbe condurti in una direzione interessante.

Penso che ciò che devi fare sia più legato alla vendita sull'idea che alla spiegazione a loro. Le vendite consistono nel capire qual è il problema del cliente e quindi mostrare loro come il vostro prodotto (o metodo di sviluppo, qualunque cosa) ne trarrà vantaggio . Ogni persona ha esigenze diverse, quindi quelle cose che avvantaggiano una persona e le eccitano possono benissimo lasciare un'altra persona fredda.

Per il tuo CEO il time-to-market può essere la chiave, per il tuo manager potrebbe essere una pianificazione più prevedibile, per i tuoi colleghi di programmazione potrebbe essere una codifica più veloce (o test / documentazione / debugging / qualunque cosa più facili) e per i clienti della tua azienda potrebbe essere ... ?

Le vendite non avvengono in modo automatico: devi fare uno sforzo concertato per comprendere il punto di vista dell'altra persona , e poi capire come mappare le tue idee nel loro Happy Place ™. Una volta che sanno come si potranno personalmente beneficiare di questa nuova cosa, spesso chiedono: "Quanto costerà e quanto tempo possiamo farlo?" Una volta che senti quelle parole magiche sai di aver fatto bene il tuo lavoro di vendita.

Non ho davvero una soluzione alla tua domanda, ma qualche tempo fa ho affrontato esattamente lo stesso dilemma e stavo cercando di rispondere esattamente a questa stessa domanda.

Mi troverei da un lato dell'argomento e qualcun altro dall'altro lato e anche se ogni fibra del mio corpo mi ha detto che il design giusto è X, non ho potuto sostenerlo usando le parole.

Peggio ancora è che a volte ammetterei il punto e lascerei che l'altra persona lo realizzasse a modo suo solo per farmi esplodere il design in faccia e poi avrei pensato: "Sì, questo è un esempio perfetto del perché non volevo per farlo in quel modo. Se solo potessi dimostrare loro questo codice allora. "

Bene, non ho mai trovato la risposta, ma pochi giorni fa mentre stavo sfogliando Lean Software Development: An Agile Toolkit, Mi sono imbattuto in qualcosa di interessante che potrebbe suggerire che la risposta in realtà non esiste. Una sezione del libro parlava di leader in altri campi, in particolare nelle unità di risposta alle emergenze e di come tali leader prendessero decisioni. Quando c'è un incendio o qualcuno ti sta sparando, quei leader non si siedono mai e discutono pro / contro con i loro compagni di squadra. Invece, usano l'intuizione, che è stata sviluppata attraverso la formazione e l'esperienza per aiutarli a prendere decisioni. Lo stesso vale per la nostra professione: come si può prendere una decisione completamente logica di fronte a tonnellate di incognite e variabilità così comuni nello sviluppo del software? Gli autori sostengono che invece di tentare di giustificare ogni decisione, gli sviluppatori dovrebbero essere incoraggiati a formare e migliorare il loro istinto in modo che alla fine "sapessero" semplicemente cosa fare.

L'unico modo in cui ho scoperto di superare questi argomenti è quello di creare una comprovata esperienza del mio lavoro. Mostrare al management e agli altri membri del mio team che le decisioni di progettazione che prendo nel mio codice danno come risultato un codice più facile da mantenere, estendere e più affidabile. Lo fai ripetutamente e la gente ti noterà. A quel punto, la tua opinione, che potrebbe basarsi solo sul tuo istinto, avrà un peso molto più elevato rispetto a oggi. Questa strategia ha funzionato con il 90% + della mia squadra incluso il mio capo. Sfortunatamente, potresti trovare uno o due ragazzi completamente testardi e rifiuteranno di vedere qualsiasi cosa a modo tuo. A quel punto, hai poche opzioni:

1. Puoi provare a salire di rango (ho finito per andare dal mio capo e chiedere un rango perché ero così stanco di questi argomenti senza uscita)
2. Puoi provare a fare pressioni affinché la maggior parte del team ti sostenga.
3. Se il progetto può permettersi (cioè non troppa perdita di produttività), quale secondo te è una decisione sbagliata, lascia che l'altra persona vinca l'argomento. Accadrà una delle due cose:
   • In alcuni casi (si spera in una porzione molto piccola), il tuo intuito sarà sbagliato e finirai per imparare qualcosa. Buon per te.
   • Nella maggior parte dei casi (di nuovo ... si spera), tu e la persona che sostenevi il design "cattivo" capirai esattamente perché è cattivo; dopo tutto il senno di poi è sempre 20/20. Spero che questa sia una lezione per quella persona che forse sai di cosa stai parlando e la prossima volta ci penseranno due volte a discutere del loro caso.

Bene, questa risposta non è così specifica per la programmazione come potresti pensare. Devi riportarlo a cose che capiscono.

Se si tratta di qualcosa di simile alla composizione rispetto all'eredità, probabilmente devi solo dire che attualmente forse il 90% degli sviluppatori considererebbe una best practice (una supposizione sfrenata, basata in parte sul fatto che il 100% degli sviluppatori concorda su quasi nulla), e tu sono d'accordo e sarei felice di approfondire il perché.

Cerco di essere il più onesto possibile su ciò che è controverso e quale percentuale di sviluppatori sarebbe d'accordo con me.

Questo generalmente funziona meglio con il management rispetto agli sviluppatori, che probabilmente ti faranno andare nella tana del coniglio spiegando se stai davvero sostenendo un buon design e come lo conosci. C'è qualcosa di encomiabile in questo, ma significa che devi dedicare molto tempo. A meno che non si fidino di te abbastanza da prendere la tua parola per tali cose, almeno provvisoriamente. Sul lato positivo, potrebbero convincerti che ti sbagli, il che batte la fredda, dura realtà che ti convince lungo la strada.

Per cose come un design che è più testabile, se non sono d'accordo sul fatto che sia più testabile, è praticamente lo stesso del primo esempio. Se non concordano sul fatto che è auspicabile essere più verificabili, è necessario riportarlo alle cose che comprendono. Probabilmente si tratterebbe di una gestione e si può parlare di costi di sviluppo inferiori a lungo termine, meno QA, processi più prevedibili (poiché la lunghezza dei cicli di QA ripetuti è difficile da prevedere), ecc.

Penso che parte del problema sia che sottovaluti quanto sia difficile convincere una squadra a concordare con te su qualcosa di controverso, anche se ti capita di essere corretto (e ovviamente potresti non esserlo). La programmazione è in parte un esercizio sociologico e potrebbe essere necessario pianificare il tempo per effettivamente andare giù in alcune di quelle buche di coniglio, poiché un grande disegno che nessuno capisce o si lascia dietro è raramente un grande disegno in pratica. Quindi non pensare a quel tempo sprecato, pensalo come una parte necessaria del successo del tuo progetto. Anche se sarebbe molto più semplice se tu potessi in qualche modo saltarlo.

Essere l'unica voce del cambiamento non è mai una cosa facile. La prima sfida è di solito coinvolgere altre persone con te (si spera che ci siano alcuni nella tua azienda che siano più aperti rispetto al resto). Se riesci ad attirare l'attenzione di un paio di altri sviluppatori / manager senior per unirti alla tua crociata, quelle voci combinate saranno sempre più difficili da ignorare per il resto.

Trovo che un buon modo di spiegare alle persone sia fornire esempi concreti di errori passati commessi in progetti in cui sono stati attivamente coinvolti (ad esempio "Hai mai provato a eseguire il debug di questa cosa? È stato così per anni e nessuno sa come aggiustalo.."). Meglio ancora, applicando quelle "nuove" idee e principi di progettazione a un progetto di piccole dimensioni e riuscendo a mostrare il successo alla fine.

A seconda degli atteggiamenti degli altri nella tua compagnia, il cambiamento potrebbe arrivare rapidamente, o potrebbe essere come cercare di nuotare attraverso il tradimento. Alcuni manager sono completamente immobili a meno che non dispongano di solide statistiche / prove di fronte a loro, dove altri sono piuttosto desiderosi di stare al passo con le ultime idee.

Potrebbe essere necessario provare diverse tattiche a seconda di chi hai a che fare; Suggerire di risparmiare denaro / tempo / sforzo e migliorare la qualità è un buon modo per attirare l'attenzione di gestori non tecnici; e la promessa di facili test automatici fa appello a un sacco di sviluppatori che di solito non riescono a sopportare di passare giorni a correre ripetutamente negli stessi fogli di calcolo dei test.

Dipende dal pubblico! Come sviluppatori abbiamo sviluppato un'intuizione per il codice buono e cattivo e usiamo vaghi termini emotivi come "odore di codice", "codice brutto", "bella soluzione". Funziona solo quando si comunica con altri sviluppatori con la stessa mentalità. Prova a spiegare al tuo CEO non tecnico che dovresti investire x ore lavorative per rendere "più bello" un codice che molto probabilmente fallirai in modo spettacolare.

Devi essere in grado di sostenere che qualsiasi dato miglioramento del design lo farà

• risparmiare denaro per l'azienda
• fare soldi per l'azienda

Ad esempio, qual è il motivo per aderire al principio della responsabilità singola? Se ogni classe ha una singola responsabilità, sarà molto più facile individuare e correggere i bug e sarà più facile aggiungere funzionalità e miglioramenti. Meno tempo per correggere i bug e aggiungere funzionalità = denaro risparmiato.