Come supportare le decisioni di progettazione? [chiuso]

Fai domande basate sull'esperienza

Il mio strumento più potente è quello di porre domande basate sull'esperienza. Quando il programmatore junior arriva con un progetto e vedi un problema con come funzionerà nella realtà, fai la domanda "come funzionerà, dato l'X elemento della realtà?" Non dire - "questo non funzionerà a causa dell'elemento X della realtà".

Spesso questo ha concluso la discussione senza conflitti mentre l'ingegnere junior torna al tavolo da disegno.

Sii aperto alla risposta

Una volta che hai fatto la domanda, sii aperto a sentire una risposta. Gli sviluppatori junior mi hanno insegnato molto sulle nuove tecnologie di cui non sapevo abbastanza. Non credo sulla parola - faccio anche le mie ricerche - ma a volte vedono cose che non conosco. Sii aperto alla risposta al tuo problema del mondo reale - potrebbero semplicemente sorprenderti.

Entra nella grande immagine del progetto

Una delle mie più grandi battaglie è di solito gli sviluppatori che vogliono fare il proprio modello per la progettazione che è al di fuori del modello utilizzato nel resto della base di codice. Potrebbe, in effetti, andar bene solo in termini di quell'area isolata, ma è incredibilmente diversa rispetto al resto della base di codice, e la mia esperienza mi dice che sarà un incubo di manutenzione.

A questo punto, spingo lo sviluppatore a vedere l'immagine grande con qualche altra domanda:

• Stai dicendo che tutto il codice dovrebbe essere refactored in questo modo?
  • Se sì, allora quanto costerebbe? Continueremo a rispettare il programma?
  • Se no, allora perché quest'area è così straordinariamente unica che dovrebbe funzionare diversamente dalla soluzione tipica?
• Quali sono i vantaggi di questo rispetto al modo esistente di implementare le cose?
• Quale sarà l'impatto quando qualcuno che non è te lo deve mantenere?

Questo non vuol dire che ogni nuova idea di implementazione sia cattiva ... ma c'è un valore nel non modificare una quantità nota e gli sviluppatori devono pensarci prima di cambiare i modelli midstream.

Qual è la cosa peggiore che può succedere?

Non c'è insegnante come esperienza. Se l'ingegnere junior sta sviluppando qualcosa di centrale e critico nei confronti del problema, in nessun modo lascerò volare un progetto radicale senza un sacco di controllo del team. Ma se l'ingegnere lavora in un prototipo, uno strumento o qualche altra area laterale, può essere una buona opportunità per provare qualcosa che suona strano, ma potrebbe funzionare - dopo tutto, devi provare cose nuove a volte ...

Gli sviluppatori junior tendono a ridurre drasticamente l'ingegnere o l'ingegnere di una soluzione.

Nessun risultato è desiderabile. L'unico modo per trovare una via di mezzo è l'esperienza del mondo reale nel fare questi estremi e vedere i disastri che sono i risultati di entrambi gli estremi.

Il risultato finale generale di entrambi gli estremi è l'impossibilità di manutenzione.

I progetti Over engineered introducono complessità non necessarie, codice extra per eseguire il debug e scrivere casi di test per e da comprendere e mantenere. Ciò porta a incubi di manutenzione.

I progetti in fase di progettazione non sono abbastanza flessibili da adattarsi facilmente ai nuovi requisiti in un dato intervallo temporale, se non del tutto. Questa è l'altra estremità dello spettro di manutenzione.

L'equilibrio che deve essere raggiunto è difficile da insegnare a qualcuno senza alcuna portata o comprensione di questi risultati. L'esperienza ti dà quella prospettiva per sapere quando abbastanza è sufficiente il design e sapere quando stai facendo troppo poco.

Alla fine, sottoporre a engineering una soluzione è meno rischioso e meno costoso da un punto di vista commerciale , perché è più vicino al principio "non ne avrai bisogno" (YAGNI) . E se non hai mai veramente bisogno del design più complesso, non hai sprecato centinaia di ore uomo.

Se sei sotto tecnico e hai bisogno di riprogettare per aggiungere nuove funzionalità, hai solo una breve quantità di tempo che viene espulso e il lavoro è stato rifatto.

Dove settimane trascorse a implementare un design troppo complesso che non porta mai frutto, non solo hai perso quelle settimane in cui le paghi ripetutamente per mantenere il codice che non è appropriato.

Una buona regola è Se profuma di qualcosa che è eccessivamente complicato e sarà un incubo di manutenzione per qualcuno nuovo della code base, non farlo.

La capacità di prendere decisioni di progettazione è ciò che distingue l'ingegneria del software dalla programmazione.

Importanti decisioni di progettazione dovrebbero essere prese sulla base di fatti e dati e dovrebbero supportare gli obiettivi di progettazione.

È possibile eseguire analisi delle opzioni per aiutare a prendere decisioni importanti. Per eseguire un'analisi, in primo luogo decidere su criteri misurabili (o stimabili) che è possibile utilizzare per basare la vostra decisione su. Per il software, questi criteri possono includere il costo (risorse necessarie per sviluppare, distribuire, configurare e mantenere un progetto specifico), le prestazioni (il progetto rispetterà i vincoli di tempo e memoria), il rischio (il progetto può essere implementato in modo tale da lavoro), sicurezza (la sicurezza del supporto progettuale). Altri criteri da considerare includono scalabilità, adattabilità, portabilità, flessibilità, estensibilità, ecc.

Quindi, valuta le opzioni di progettazione in relazione ai fattori che hai deciso di utilizzare per prendere la decisione.

Si noti che l'analisi delle buone opzioni richiede tempo e impegno, ma dovrebbe essere utilizzata per importanti decisioni di progettazione.

Se un anziano può fornire una buona ragione per cui il design è ragionevole, e difendere eventuali problemi che potrebbe avere, uno junior intelligente lo seguirà. Quando un anziano dice "Ho fatto questo in passato" senza ulteriori spiegazioni, un juniores sente "Ho fatto questo in passato ed è stato così intelligente che è finito su The Daily WTF".

Molti anziani oggi si sono ribellati anche alla generazione precedente. Guarda la cascata. Guarda i no-test, qualunque sia lo sviluppo. Guarda il design goto. Le idee che hanno scardinato i vecchi standard sono venute in seguito perché molti degli sviluppatori senior hanno avuto un nuovo sguardo alle stravaganti metodologie dei loro senior quando erano juniores.

Detto questo, per ogni grande idea che ha un giovane, ci sono cento idee terribili. È il lavoro di un anziano per la maggior parte del tempo a dire "Bel tentativo, ma non sarà fattibile a causa di X e Y". Senza quel feedback, tuttavia, un giovane assumerà spesso di aver incontrato uno dei dinosauri "goto" di cui hanno letto sul Daily WTF. Questo non descrive la maggior parte degli anziani, quindi dai un motivo per vedere come sei arrivato a un particolare schema. Mostra loro che hai imparato abbastanza in 20 anni per avere una conoscenza molto più approfondita del design, spiegando in realtà come è meglio ciò che stai facendo. Juniors non ha l'esperienza per "solo sapere" quale sia lo schema giusto. Loro (noi) abbiamo bisogno di sapere perché.