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

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

Penso che ciò che devi fare sia più correlato a venderli sull'idea che a spiegarlo a loro. Le vendite riguardano solo la comprensione del problema del cliente e quindi mostrano come il tuo prodotto (o il metodo di sviluppo, qualunque sia) gli consentirà . Ogni persona ha esigenze diverse, quindi quelle che avvantaggiano una persona e ottiene loro eccitati possono benissimo lasciare un'altra persona fredda.

Per il tuo CEO il time-to-market potrebbe essere la chiave, per il tuo manager potrebbero essere programmi più prevedibili, per i tuoi colleghi di programmazione potrebbe essere una codifica più veloce (o più semplice test / documentazione / debug / qualunque), e per il tuo i clienti dell'azienda potrebbero essere ...?

Le vendite non avvengono automagicamente: devi fare uno sforzo concertato per capire il punto di vista dell'altra persona e poi capire come mappare le tue idee nel loro Happy Place ™. Una volta che sanno come loro trarranno beneficio personalmente da questa nuova cosa, spesso chiederanno: "Quanto costerà e quanto presto possiamo farlo?" Una volta che senti quelle parole magiche, sai che hai svolto 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 alla stessa domanda.

Mi troverei da un lato della discussione e da qualcun altro dall'altra parte e anche se ogni fibra del mio corpo mi ha detto che il design giusto è X, non potrei appoggiarlo usando le parole.

Peggio ancora è che a volte concederei il punto e lasciare che l'altra persona la implementasse a modo suo solo per far esplodere il disegno in faccia e poi penserei "Sì, questo è un perfetto esempio del perché non Non voglio farlo in quel modo, se solo potessi dimostrare questo codice a loro ".

Beh, non ho mai trovato la risposta, ma pochi giorni fa mentre sfogliavo 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, specialmente nelle unità di risposta alle emergenze e su come quei 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 pienamente logica di fronte a una tonnellata di incognite e variabilità che è così comune nello sviluppo del software? Gli autori sostengono che invece di tentare di giustificare ogni decisione, gli sviluppatori dovrebbero essere incoraggiati ad addestrare e migliorare i loro istinti, così alla fine essi "saprebbero" solo cosa fare.

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

1. Puoi provare a tirare il grado (ho finito per andare dal mio capo e chiedere un grado perché ero così stanco di questi argomenti senza uscita)
2. Puoi provare a fare lobby per consentire alla maggioranza del team di supportarti.
3. Se il progetto può permettersi (non c'è troppa perdita di produttività), quella che secondo te è una decisione sbagliata, lascia che l'altra persona vinca la discussione. Una delle due cose succederà:
   • In alcuni casi (spero molto piccola porzione), la tua intuizione sarà sbagliata e finirai per imparare qualcosa. Buon per te.
   • Nella maggior parte dei casi (ancora ... si spera), tu e la persona che sosteneva il design "cattivo" capirai esattamente perché è male; dopo tutto il senno di poi è sempre 20/20. Spero che questa sarà una lezione per quella persona che forse sai di cosa stai parlando e la prossima volta penseranno due volte a discutere il loro caso.

Bene, questa risposta non è propriamente specifica per la programmazione come si potrebbe pensare. Devi riportarlo alle cose che capiscono.

Se si tratta di qualcosa come la composizione sull'ereditarietà, probabilmente devi solo dire che attualmente forse il 90% degli sviluppatori considererebbe questa una best practice (una supposizione sfrenata, basata in parte sul fatto che il 100% degli sviluppatori è d'accordo su quasi nulla) e tu sei d'accordo e saresti felice di entrare nel perché.

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

Generalmente funziona meglio con il management rispetto agli sviluppatori, che probabilmente ti faranno andare giù nella tana del coniglio per spiegare se stai davvero sostenendo un buon design e come lo sai. C'è qualcosa di encomiabile in questo, ma significa che devi impiegare molto tempo a meno che non ti fidi abbastanza di te per prendere la parola per queste cose, almeno provvisoriamente. Per quanto riguarda il lato positivo, potrebbero convincerti che hai torto, il che batte 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 è più testabile, allora è praticamente lo stesso del primo esempio. Se non sono d'accordo sul fatto che sia desiderabile essere più testabili, allora devi riportarlo alle cose che capiscono. Molto probabilmente si tratterà di gestione, e si può parlare di costi di sviluppo più bassi a lungo termine, meno QA, processi più prevedibili (poiché la lunghezza dei cicli ripetuti di QA è difficile da prevedere), ecc.

Penso che parte del problema sia che sottovaluti quanto sia difficile convincere una squadra ad essere d'accordo con te su qualcosa di controverso, anche se ti capita di essere corretto (e naturalmente potresti non esserlo). La programmazione è in parte un esercizio sociologico e potreste aver bisogno di pianificare il tempo per buttare giù alcune di quelle bufere di coniglio, dal momento che un grande design che nessuno capisce o ottiene è raramente un grande progetto nella pratica. Quindi non pensare che quel tempo sia sprecato, consideralo una parte necessaria del successo del tuo progetto. Anche se sarebbe molto più semplice se si potesse saltarlo in qualche modo.

Essere l'unica voce del cambiamento non è mai una cosa facile. La prima sfida è di solito portare altre persone a bordo con te (speriamo che nella tua azienda ci sia qualcuno che ha una mentalità più aperta del resto). Se riesci a catturare 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 per spiegare alle persone sia fornendo esempi concreti di errori passati commessi in progetti nei quali sono stati coinvolti attivamente (ad esempio "Hai mai provato a eseguire il debug di questa cosa? È stato così per anni e nessuno sa come risolverlo .. "). Meglio ancora, applicando quelle "nuove" idee e principi di design a un progetto piccolo / trial e potendo mostrare il successo ottenuto alla fine.

A seconda dell'atteggiamento degli altri nella tua azienda, i cambiamenti potrebbero venire rapidamente, o potrebbe essere come cercare di nuotare attraverso la melassa. Alcuni manager sono completamente immobili, a meno che non abbiano una solida statistica / prova di fronte a loro, dove altri sono desiderosi di stare al passo con le ultime riflessioni.

Potrebbe essere necessario provare diverse tattiche a seconda di chi hai a che fare; Suggerire che il denaro / tempo / sforzo possa essere risparmiato e la qualità potrebbe essere migliorata è un buon modo per attirare l'attenzione dei dirigenti non tecnici; e la promessa di semplici test automatizzati fa appello a un bel po 'di sviluppatori che di solito non sopportano di passare giorni interi a scorrere gli stessi fogli di calcolo di test ripetutamente.

Dipende dal pubblico! Come sviluppatori abbiamo sviluppato un'intuizione per il codice buono e cattivo e usato termini emotivi vaghi come "code smell", "brutto codice", "bellissima soluzione". Funziona solo quando comunichi con altri sviluppatori con la stessa mentalità. Cerca di spiegare al tuo CEO non tecnico che dovresti investire x ore uomo per rendere il codice "più bello" che molto probabilmente fallirà in modo spettacolare.

Devi essere in grado di dimostrare che un determinato miglioramento del design sarà

• risparmiare denaro per l'azienda
• guadagna soldi per la società

Ad esempio, che cosa significa attenersi al principio della responsabilità unica? Se ogni classe ha una singola responsabilità, rende molto più facile individuare e correggere i bug, e rende più facile aggiungere funzionalità e miglioramenti. Meno tempo per correggere bug e aggiungere funzionalità = denaro risparmiato.