Dare una presentazione su "stile di codice e modelli di progettazione" [chiuso]

La mia azienda (piccola, circa 40 persone in 3 uffici) occasionalmente organizza "seminari per sviluppatori" online in cui uno degli sviluppatori ospita una presentazione su un argomento tecnico. Non si tratta necessariamente del nostro lavoro, ma solo di aiutare tutti a migliorare le proprie capacità e capacità di comprensione.

Mi è stato chiesto di ospitare il prossimo, e l'argomento (scelto da un elenco che ho fornito) è lo stile del codice e i modelli di progettazione. So che quelle cose non sono così strettamente correlate, ma sopportano con me. Ho visto molti posti nella nostra base di codice che potrebbero essere migliorati, alcuni che potrebbero anche qualificarsi per DailyWTF, quindi voglio che questa presentazione sia il più efficace possibile. Il problema è che non so esattamente cosa coprire in un'ora.

La mia prima idea è quella di utilizzare il nostro codice come esempio, per portare a casa il punto di "per favore, applicalo sul tuo lavoro". Ma l'argomento è così ampio.

Alcune cose che non vanno nel nostro codice (PHP) includono:

• OO minimo. Ultimamente sta migliorando, ma ci sono ancora tonnellate di funzioni globali. Mi ci vuole un po 'per trovare le cose.
• Config globale (opinione immagino). Puoi trovare $ GLOBALS ['blah'] sparsi in quasi tutti i file.
• Stile controvento incoerente. Sembra minimo, ma in realtà questo ha causato un errore di sintassi che è stato portato all'origine cinque giorni fa, che non è stato ancora corretto fino a ieri.
• Costrutti inefficienti. Sono stato in grado di apportare alcuni miglioramenti di base che hanno ridotto del 70% il tempo di esecuzione in alcune aree.

Voglio che questa cosa sia il più utile possibile, senza sembrare condiscendente ai miei colleghi. Quindi su quali aspetti dello "stile" dovrei concentrarmi e quali modelli di design potrebbero essere più utili da spiegare?

Fai molta attenzione usando il codice reale in una presentazione di fronte alle persone che scrivono questo codice.

Nella migliore delle ipotesi, sconvolgerai la tua squadra puntando il dito davanti a tutti. E quello che otterrai invece di "Mi hai davvero aperto gli occhi" è "WTF di fronte a tutti? Hai persino guardato il tuo codice stupido ..."

Prendi un vero esempio ma modificalo o assicurati che non possa essere rintracciato a chiunque lo abbia scritto. O prendi il vero codice da persone che conosci ma prendi anche un po 'del TUO vecchio codice e gioca con l'umorismo e scherza con queste persone, stile standup :)

Per rispondere alle domande originali: tutto ciò che riguarda la leggibilità: funzioni con il minor numero di argomenti possibile, OOP, nome e commenti della variabile lunghi e dettagliati.

Immagino che tu abbia un sistema di tracciamento dei bug nella tua organizzazione. Estrarre alcuni dei bug più cattivi dal repository, vedere il report di correzione sul perché è accaduto (variabili globali andate male, funzioni che fanno cose che non erano destinate a ecc.) E quindi discutere stili di codifica e modelli di progettazione che avrebbero potuto aiutare a evitare questo problema .

E 'un lavoro duro per fare questo po' di ricerca, ma questo è il modo più forte per guidare a casa ciò che si sta presentando fa davvero il lavoro .

"ancora tonnellate di funzioni globali".

Innanzitutto, ottieni un elenco. Completo è l'ideale.

In secondo luogo, suddividere questo elenco in potenziali classi. Pensa alle definizioni delle classi.

Durante la presentazione effettiva, scegli la classe potenziale più grande, più ovvia, più evidente, meno discutibile che assorbirebbe un mucchio di quelle funzioni globali.

Come argomento di discussione. Hai un'idea Devi ottenere il consenso. E rispondi alle domande lungo la strada. E aiutali a capire perché si tratta di una singola classe di oggetti, non di un gruppo di funzioni casuali che condividono i globi.

Quindi, dopo aver discusso di questo al punto in cui comprendono solo questa lezione e come sei arrivato al contenuto ....

Accendi il proiettore.

Iniziare a digitare.

Correggi il codice. Rieseguire i test unitari.

Progetta modelli e stile di codifica e lavori da svolgere. Tutto in un unico pacchetto.

in 1 ora farai bene a capire a fondo le nozioni di base.

suggerisco di scegliere 3 cose da ciascun argomento e di concentrarmi su quelle; limitare le diapositive a 5-7 parole in modo che le persone ti ascoltino invece di leggere le diapositive; usa esempi inventati (quindi non calpestare le dita dei piedi, secondo i suggerimenti degli altri); dare riferimenti alla fine (gli URL sono meglio dei libri) come esercizio per coloro che vogliono saperne di più; pubblica le tue diapositive sulla tua intranet dopo la presentazione. (Per quanto riguarda il problema delle parentesi graffe, usa un formattatore di codice; probabilmente non è una battaglia che vale la pena combattere)

Argomenti suggeriti:

• Stile di codifica

  • Lo Zen di OOP in PHP: Coding With Style!
  • 5 motivi per cui le funzioni globali causano il cancro al codice
  • Cosa c'è in un nome? Convenzioni e buon senso (o non farmi pensare!)

• Modelli di progettazione

  • Alcuni modelli GoF nel nostro codice; un introduzione
  • I modelli sono solo strumenti, non vangelo
  • Il meglio e il peggio: Pattern e Anti-Pattern

nota: le configurazioni globali sono talvolta difficili da evitare; un semplice rimedio è mettere tutti i riferimenti ad essi in una funzione init

avvertenza: conosco solo PHP sufficiente per interrompere wordpress ed eseguire correzioni minori del sito web

Informazioni sull'uso del codice reale nella presentazione: se utilizzato, utilizzarlo solo per i buoni esempi, MAI i cattivi esempi. Per il male, crearne uno tuo o trovarlo sul web. Ciò consente ai tuoi colleghi di essere orgogliosi del loro lavoro e di ottenerne il riconoscimento. Evita anche lo scenario in cui possono essere arrabbiati / imbarazzati per essere stati individuati come cattivi sviluppatori.

Gli stili di codifica sono cattive abitudini. Difficile da eliminare. Il modo migliore per lasciare che qualcuno lasci cadere una cattiva abitudine? Fagli vedere in prima persona quanto sia brutto, disgustoso o dannoso.

Mostra loro codice errato, chiedi loro cosa c'è di male. Lascia che ci pensino un secondo, poi dai loro un "Aaahaaa!" momento mostrando loro un caso limite (problema di Fencepost, forse?) o un caso in cui il loro cattivo design crolla tutto il resto.

I tuoi ragazzi soffrono di regolari problemi di progettazione, a quanto pare. Mostra loro un esempio di come una funzione globale è cambiata in modo innocente, danneggiando altre funzioni a seconda di essa, ma non sapendo che è stata modificata. Mostra loro un classico problema di sincronizzazione con la variabile globale.

Fallo in modo divertente per coinvolgerli, invece di annoiarli o farli assumere posizioni difensive (chi è questo ragazzo che ci critica?); ad esempio mostrare loro una funzione che svolge il proprio lavoro in due passaggi (1- inserire il nome della moglie) (2-store it in global) (3-inserire il nome del marito e prendere il nome della moglie da global per archiviarlo nel database) (4- ridere come una cattiva sincronizzazione si traduce in uomini che hanno "nuove" mogli), poiché uno scherzo propone di scrivere una funzione di statistica del divorzio.

Credere può farsi un'idea dello stile di programmazione, perché programmiamo ciò che pensiamo, e quando il design della programmazione viene criticato alcune persone lo prendono come un insulto al loro modo di pensare e quindi alla loro intelligenza, quindi è necessario adottare un approccio divertente ad esso.

Assumi le tue cattive funzioni, nascondilo con alcune modifiche in modo da non mettere in imbarazzo il proprietario del codice e lavora e interagisci con il pubblico per migliorarlo. Risultato: il sistema di controllo del codice sorgente del mattino successivo sarà così occupato, quindi prendi un caffè e sorridi ai registri delle modifiche.