In che modo induci le persone a valutare l'astrazione e la flessibilità rispetto al “solo farlo”?

Question

A volte ho difficoltà con altre persone che desiderano risolvere un problema quando desiderano saltare le interfacce ufficiali e accedere direttamente ai dettagli di implementazione sottostanti.

Sostengono che ciò consentirà loro di risolvere il problema più rapidamente. Sostengo che così facendo la nostra architettura diventerà più strettamente accoppiata e difficile da modificare con l'emergere di nuovi requisiti.

Sottolineo tutto il lavoro che ha riguardato il design attuale e la filosofia del design e il valore della flessibilità, il costo del tentativo di mantenere e modificare il codice fragile, il valore dell'incapsulamento e del nascondere i dati e le architetture a strati e essere robusti in modo che piccoli cambiamenti nelle specifiche portino a piccoli cambiamenti nel codice. E dicono " Ma questo sarebbe più facile. & Quot;

Come gestite queste persone?

Answer 1

Convincili che prendere scorciatoie è una falsa economia.

Spiega che lo sforzo iniziale codifica è inferiore al 30% dello sforzo iniziale di sviluppo e inferiore al 10% (nella mia esperienza) dello sforzo complessivo del progetto (inclusa la manutenzione).

Se rimangono non convinti e hai l'autorità per farlo, allora dì loro di farlo a modo tuo. Se non hai l'autorità, non fare nient'altro. Alla fine il tuo supervisore, se vale qualcosa, lo riconoscerà e sarai quindi nella posizione di autorità.

Answer 2

Falli lavorare su alcuni codici legacy che correggono i bug in esso. Questo è praticamente il modo in cui la maggior parte delle persone che conosco hanno imparato queste lezioni davvero preziose ... nel modo più duro.

Answer 3

" facile " quando? Ora, quando tutto non è in uno stato di flusso? O tra tre mesi, quando i requisiti del cliente sono cambiati e hanno una "soluzione" che non è più una soluzione?

Non sono molto interessato alla struttura e alle regole per il bene della struttura e delle regole, ma è bene sapere A) chi guida la barca B) quali sono le regole e C) perché abbiamo scelto di farlo in questo modo .

Nel mio negozio non ci piace dover riscrivere il codice perché abbiamo rovinato e hardcoded un sacco di cose o creato una fragile "soluzione" al problema. Tende a non essere più difficile seguire l'approccio più flessibile una volta che la gente si rende conto che ridurrà le frustrazioni in seguito quando le cose saranno capovolte da una serie di modifiche ai requisiti. Codifichiamo per il 'lungo raggio' non per il 'bisogno oggi', in genere, quindi il design è realizzato per un motivo e il design è seguito per lo stesso motivo .

Ho trascorso una settimana della mia vita (7 giorni consecutivi) riscrivendo un modulo perché ero in modalità 'get it done quick'. Sette giorni di estenuante tempo, 10-12 ore al giorno nel modo giusto, a fine partita, quando avrei potuto guardare il Super Bowl. Quello puzzolente. Ho imparato una lezione lì. È possibile che anche i tuoi "amici" debbano sperimentare quel tipo di apertura degli occhi.

Buona fortuna!

Answer 4

In realtà odio prendere l'opinione dissenziente su questo, ma ...

Per citare Van Halen (citando il cliché), "c'è un tempo e un posto per tutto." Anche se di certo non incoraggio a scrivere male, mai, a volte devi solo farlo e trovare quel mezzo felice tra robusto / duraturo e hackerato / documentato. (La parte documentata è particolarmente importante, su due fronti: uno, che indichi chiaramente che qualsiasi cosa tu stia facendo è fatta semplicemente nell'interesse di farlo e sta prendendo alcune scorciatoie; e, due, un'idea approssimativa su quale potrebbe essere il modo più corretto di affrontare il problema.

Come programmatori, ci sforziamo spesso di scrivere il codice perfetto (beh, alcuni di noi lo fanno), e talvolta perdiamo di vista il quadro generale - ci sono molti motivi per cui potrebbe essere ok (a un livello) giocare veloce e sciolto con il codice, riducendo al minimo l'impatto che avrà lungo la strada.

Non utilizzare questo come giustificazione: la regola 80/20 si applica qui, ovviamente. Il più delle volte vuoi assolutamente schiacciare qualsiasi scorciatoia lungo queste linee; ma a volte ...

Answer 5

Mostrali! Lascia che facciano un piccolo modulo in " Ma questo sarebbe più facile. & Quot; stile mentre lo fai nel modo giusto. Quindi chiedi loro di apportare da 2 a 5 modifiche ai requisiti (devono essere loro ad apportare le modifiche) e di organizzare un contest a tempo sull'attuazione delle modifiche. Potrebbero volerci un giorno o due ma lo capiranno. In caso contrario, avrai la stessa discussione su ogni nuovo progetto o attività.

Answer 6

Potresti provare un'analogia su di loro ....

Le regole degli scacchi sono piuttosto semplici. Puoi insegnarli a un bambino: "il cavallo si muove in questo modo", "il castello si muove in questo modo", ecc.

Se questo è tutto ciò che sai, puoi giocare a scacchi e probabilmente divertirti, ma qualcuno con una conoscenza più approfondita del gioco ti pulirà la tavola ogni volta. Ti batterai così tanto che non sarà nemmeno più divertente, perché non avrai idea di come lo stiano facendo.

Lo stesso principio si applica alla programmazione. Conoscere la sintassi della lingua e alcune semplici strutture dati è sufficiente per farti funzionare un programma, ma non avrai molta fortuna con un'applicazione su larga scala che deve sopravvivere a più cicli di rilascio.

Gli scacchi hanno impostato aperture, strategie di attacco, ecc. Abbiamo modelli di design.

Answer 7

La cosa migliore è probabilmente promuoverli alla direzione in modo che non possano fare così tanti danni.

Answer 8

Il problema è che la maggior parte delle persone non conosce nemmeno la progettazione del software oltre ai concetti più elementari e allo sviluppo dello stile di trascinamento della selezione. Per ogni sviluppatore che ricerca ed educa se stesso su tutti i migliori nuovi concetti e tecnologie, ce ne sono dieci che vanno a casa e non guardano un PC. Devi insegnare loro.

Answer 9

Ho progettato un sistema grande e complicato circa cinque anni fa. Ho trascorso i successivi cinque anni iniettandomi in ogni progetto che riguardava il "mio" sistema per impedire ai barbari di rovinare la mia architettura. Finché ho esercitato una pressione costante e inarrestabile sono stato in grado di mantenere l'architettura abbastanza pulita, ma stavo combattendo una battaglia persa. Ecco perché:

1) La maggior parte delle persone viene giudicata se ha svolto il lavoro oggi . Nessuno è mai stato rimproverato perché hanno tagliato un angolo (o due) tre anni fa per ottenere un progetto fuori dalla porta in tempo. D'altra parte, molte persone sono state rimproverate per non aver portato i progetti fuori dalla porta in tempo.

2) Potresti voler mantenere il sistema in ordine perché hai un senso di proprietà sul codice, sull'applicazione o sugli utenti, ecc. Molte persone non avranno un senso di proprietà e quindi sono troppo felici di hackerare qualcosa in modo che possano essere fatti con esso. Puoi condurre un cavallo all'acqua, ma non puoi fargli interessare.

3) Se fai convinci tutti a mantenere correttamente il codice, entreranno a far parte nuove persone e dovrà essere istruito su come fare le cose nel modo giusto. Quindi, anche se hai successo, puoi sentirti come se stessi fallendo perché stai sempre combattendo la stessa battaglia contro nuovi avversari.

4) In realtà potresti avere torto. Sarebbe sensato dal punto di vista finanziario che Microsoft dedichi il doppio delle ore del programmatore a rendere MS-Paint robusto e gestibile? A volte un brutto sistema combinato è buono abbastanza. La maggior parte dei buoni programmatori ha difficoltà a capirlo, ma di solito è perché sono buoni programmatori.

5) Giuro che ci sono alcune persone che provano piacere perverso nell'hacking delle cose insieme perché possono farlo più velocemente, o saranno le uniche a capirlo, o hanno un bisogno infantile di infrangere le regole. Non puoi ragionare con queste persone e più tempo trascorri a discutere con loro, più si avvicina la scadenza del progetto, il che ti costringerà comunque a hackerare qualcosa insieme.

6) Ci sono buone probabilità che tu capisca il sistema meglio di loro. Quello che ti sembra un brutto hack potrebbe sembrare "camminare leggermente". a una persona che non ha familiarità con il sistema. O lo sforzo extra per rendere robusto il codice proteggerà il programmatore da un problema che non ha mai avuto prima e quindi non riesce a grok. Non impari a controllare i codici di ritorno fino a quando qualcosa non va storto perché non hai controllato un codice di ritorno. A quel punto smette di essere "lavoro extra" e inizia a essere "richiesto lavoro".

Se hai un team di sviluppo piccolo e stretto è possibile. Ma quanto più grande è l'organizzazione, tanto meno è probabile che tu abbia successo. Se riesci a convincere un negozio IT di 250 persone ad apprezzare il fare le cose piuttosto che fare le cose velocemente, i tuoi poteri di persuasione sono leggendari.

Answer 10

http://catb.org/jargon/html/L/LART.html SCNR, ecc. Pp;)

Answer 11

Di 'loro di leggere (non che lo faranno mai) Teoria dell'incapsulamento: http://www.edmundkirwan.com/