La differenza tra buone pratiche e buon senso?

C'è molta conversazione sulle migliori pratiche ¹ nello sviluppo del software. Ho visto almeno tre punti importanti discutere molto sia su SE che altrove:

• Cosa si qualifica come best practice e perché?
• Vale la pena discutere delle migliori pratiche in primo luogo, perché è ragionevole affermare che nessuna pratica è una "migliore" pratica?
• Quando dovresti rinunciare a una best practice - o forse la maggior parte delle best practice - perché non sembra applicabile o a causa di vincoli esterni (tempo, denaro, ecc.) Che rendono impraticabile il trade-off?

Qualcosa che sembra emergere molto meno spesso, ma più che mai, è una nozione di buon senso nello sviluppo del software. L'esperienza recente mi ha riportato di nuovo in mente questa nozione.

La mia impressione iniziale è che si tratta di una discussione diversa rispetto alle migliori pratiche, ma forse con qualche impollinazione incrociata.

Quando penso al buonsenso in generale, penso a una serie di regole che hai imparato o che ti hanno insegnato che ti danno una base per ragionare e prendere decisioni. Seguire il buon senso è un buon modo per evitare di sparare a tutta la gamba. Ma al di là di una base piuttosto bassa, il buon senso lascia il posto alla necessità di prendere decisioni educate e le decisioni istruite possono persino prevalere sul buon senso quando l'evidenza sembra abbastanza convincente. Potrei essere un po 'lento con la definizione qui, ma penso che sia abbastanza vicino da guidare il mio esempio.

Quando penso al buon senso nello sviluppo del software, penso a tutte le regole dell'igiene di base per impedire a una base di codice di decadere rapidamente in un pasticcio incomprensibile. Ad esempio, cose come: non usare una singola struttura globale per mantenere e comunicare lo stato all'interno di un programma non banale; non usare variabili / metodi / nomi di classi che sono semplicemente incomprensibili casuali; cose che probabilmente assomigliano molto a ciò che siamo chiamati a definire anti-pattern. Laddove applicare le migliori pratiche l'analogo pratico ai modelli di apprendimento, applicare il buon senso potrebbe essere visto come un analogo pratico dei modelli di apprendimento.

Con questo in mente, vorrei porre alcune domande per cui vedere le risposte degli altri potrebbe aiutarmi a ragionare su questo.

Altri credono che vi sia una nozione di buon senso nello sviluppo del software? Sarebbe interessato a conoscere il ragionamento in entrambi i modi.

In tal caso, vale la pena discuterne? È qualcosa che dovremmo spingere tanto quanto a volte facciamo con le migliori pratiche? Vale la pena spingere per qualcosa di ancora più difficile?

Se l'analogia con gli anti-pattern sembra ragionevole, la regola generale è che gli anti-pattern sono impiegati solo se non c'è altro modo, e anche allora solo in circostanze molto limitate. Quanto si dovrebbe essere flessibili nel consentire a una base di codice di deviare dal senso comune? Sembra irragionevole che la risposta sia "per niente", perché a volte l'opportunità richiede deviazioni. Ma sembra un diverso tipo di argomento rispetto a quando impiegare una "migliore pratica". Forse non lo è; se non la pensi così, mi piacerebbe sapere perché.

Questo è molto più aperto e forse degno di una domanda di follow-up tutta sua, che tipo di raccomandazioni indicheresti che sembrano questioni di buon senso?

Anche altri pensieri sono i benvenuti.

¹ Forse farei meglio a chiamarli "modelli di dominio comunemente ricorrenti", ma il nome "best practice" è abbastanza comune da far sapere a tutti cosa sono, anche se non sono d'accordo. Se la parte "migliore" ti disturba, immagina di aver sostituito le "migliori pratiche" con un suono meno autorevole.

Le migliori pratiche sono pratiche che hanno funzionato bene in un campo relativamente ampio di circostanze. Il problema con loro è che A) l'espressione a volte viene abusata per il marketing e B) come regole fisse, non sono abbastanza flessibili; nessuna serie di regole fisse dovrebbe essere seguita senza pensare se si applicano alla situazione attuale.

Le migliori pratiche sono ottime quando vengono fornite spiegazioni sul perché sono "migliori" e in quali circostanze dovrebbero essere utilizzate. Quindi puoi ragionare su quando non usarli.

Il problema con il "buon senso" è che è troppo flessibile - può essere usato per giustificare praticamente qualsiasi cosa, e non si può davvero avere una discussione razionale quando le persone non sono d'accordo ed entrambi affermano che la loro posizione è "buon senso". È bello avere ma scarsa come linea guida da seguire per una squadra.

Penso che tu l'abbia al contrario.

Quando insegno ai programmatori le basi della sicurezza, insegno sempre loro a usare best practices, eppure quando ho a che fare con esperti di sicurezza (o più programmatori "esperti di sicurezza") non ne discuterò mai best practices, anzi li violerò spesso.

Una definizione migliore sarebbe:

Le "migliori pratiche" sono di buon senso da parte degli esperti, come dovrebbero essere applicate dai non esperti.

Cioè, non puoi rivendicare il "buon senso" fino a quando non hai abbastanza esperienza in un determinato campo per capire i sottili compromessi; e quando lo fai, non dovresti più seguire ciecamente le "migliori pratiche" di cookie cutter.

Le "migliori pratiche" sono un segnaposto temporaneo fino a quando non si ha abbastanza esperienza per usare il proprio "buon senso".

Best practice -> "prima impari le regole". Esperienza -> "allora, impari quando e come romperli".

La volontà di sperimentare alternative (in codice non critico, ovviamente - preferibilmente progetti personali e gettate via) può aiutare a costruire l'esperienza di cui hai bisogno.

Il buon senso non è lo stesso dell'esperienza, ovviamente, e non sempre hai bisogno di molta esperienza per vedere il difetto nell'applicazione di una buona tecnica nel posto sbagliato - ma è molto facile costruire false razionalizzazioni sia per l'applicazione eccessiva che per applicare in modo insufficiente una tecnica, e poiché il "buon senso" qui chiaramente non è una conoscenza innata della programmazione, quel senso è chiaramente "comune" solo all'interno di gruppi particolari.

È molto facile "schierarsi". Impossibile da evitare, in effetti - a volte una parte ha davvero ragione, e l'altra ha davvero torto, e sarebbe irrazionale discutere di equilibrio. Il problema qui è che il vero inferno non sta pesando tanto su una best practice per rilevanza, ma quando due opinioni di best practice contrastanti si scontrano.

Affrontare questo probabilmente è molto più sulle abilità delle persone che sulle capacità tecniche. Sono molto cattivo :-(

Ciononostante, è ancora importante imparare dall'esperienza delle altre persone e dalla propria, ovvero scoprire quali sono le migliori pratiche, perché vengono utilizzate e quali sono i vantaggi (e gli svantaggi).

Mi sembra che questa domanda sia un inganno semantico. Se usiamo queste definizioni, allora non c'è dubbio:

Best Practice: un modo comprovato di risolvere un problema in un determinato dominio (ad es. Le best practice in tempo reale sono totalmente estranee alle best practice del database)

Senso comune: esperienza professionale che serve ad avvertire il programmatore di insidie ​​da evitare

Alla fine, una Best Practice è un modello di meta-design per risolvere una particolare congruenza di problemi e viene scelta in base alle esperienze del mondo reale, mentre Common Sense è una guida alla risoluzione dei problemi basata sull'osservazione generale attraverso molteplici insiemi di problemi.

Common sense = You.CommonSense

Best practices = Sum(Experts.Experience + Experts.CommonSense)

Tempi interessanti. La scorsa settimana questo articolo è stato pubblicato discutendo perché il buon senso non è necessariamente l'ideale in tutte le situazioni.

Il buon senso è squisitamente adattato per gestire il tipo di complessità che si presenta nelle situazioni quotidiane ... E poiché funziona così bene in queste situazioni, siamo propensi a fidarci di esso in tutte le situazioni

(le mie parole in grassetto)

Fondamentalmente - gli umani non sono bravi a usare il buon senso in settori come questo in cui non abbiamo sviluppato un sistema radicato, quindi dovremmo SEMPRE utilizzare un set documentato di standard e non fare affidamento sul nostro buon senso!

Il buon senso non corrisponde all'apprendimento di schemi anti, né è diverso o in contrasto con la migliore pratica.

Il primo problema con il buon senso è il suo nome: porta alla conclusione che è sia comune che sensibile. Come comunemente usato, è soggetto ad attacchi su entrambi i fronti. Usando il tuo esempio:

gli anti-schemi sono impiegati solo se non c'è altro modo, e anche solo in circostanze molto limitate

Comprendo che questo non è il modo in cui sorgono gli anti-schemi. Viene da un accrescimento di fattori culturali e sociali; di ignorare le migliori pratiche e standard per un periodo sostanziale; di ignorare i costi in futuro per ottenere benefici a breve termine, ad esempio per rispettare una scadenza utilizzando una soluzione abbreviata che è un incubo di manutenzione; ecc. Nessun corpo decide di adottare deliberatamente un anti-schema: crescono e basta.

Allo stesso modo, il senso comune è troppo spesso usato per significare "ciò che viene fatto comunemente" e giustificare la mancanza di pensiero, intuizione e duro lavoro nel risolvere ciò che è coinvolto nel fornire una soluzione. Viene anche usato come giustificazione per "è il modo in cui lo faccio, quindi ovviamente è buon senso" - e come difesa contro la revisione e le critiche.

Per quanto riguarda le migliori pratiche, i primi due paragrafi di Michael sono un eccellente riassunto di quali dovrebbero essere le migliori pratiche: una risorsa per aiutare tutti a migliorare ciò che fanno. Fornisce inoltre trasparenza delle decisioni (in particolare decisioni di progettazione) e la capacità di apprendere dagli altri. L'aspetto negativo delle migliori pratiche è quando genera una cultura della checklist - "Ho spuntato tutte le caselle, quindi quello che ho fatto deve andare bene" - senza applicare pensiero, cura e attenzione alla natura dell'applicabilità della checklist.

Questo è un argomento scivoloso che spesso si trasforma in una guerra religiosa.

Quasi ogni migliore pratica può essere contrastata con un caso valido per fare il contrario.

Alcune buone pratiche sono più "migliori" di altre. Le variabili di stato globali sono quasi sempre fatte meglio in un modo diverso e GOTO è di solito una cattiva idea, ma quando si entra negli argomenti pattern / anti-pattern o dati diretti / dati astratti diventa un po 'meno chiaro. Ancora di più quando inizi a parlare di metodologie e pratiche di sviluppo.

In alcune situazioni il buonsenso e le migliori pratiche sono persino in opposizione tra loro.

Non esiste un organo di governo delle migliori pratiche e nessun singolo gruppo, anche se esistesse, potrebbe definire ogni possibile "migliore" per ogni possibile situazione. Molte cose etichettate come best practice sono solo cattive attività di marketing nel tentativo di vendere strumenti o formazione per individui non informati.

Anche quando tutta la tua squadra concorda sul fatto che qualcosa è meglio, non è sempre possibile implementarlo in questo modo per vari fattori vincolanti.

IMHO devi usare le migliori pratiche come guida su cosa considerare più attentamente nella tua progettazione. Potresti avere un motivo valido per deviare, ma probabilmente devi assicurarti che tutti gli altri membri del team siano d'accordo prima di andare e costruire qualcosa di strano.

Alcuni degli argomenti sulle migliori pratiche dopo quel punto si riducono praticamente a non costruire qualcosa che il prossimo sviluppatore che deve lavorare su di essa odierà. Tutti odiano il codice che non è il loro stile e tutti danno la colpa a tutto ciò che lascia chiunque, quindi o lo spiegherai al prossimo sviluppatore dopo che si lamentano di qualcosa, oppure non sarai lì e parlerai male indipendentemente da come lo codifichi. Ciò rende tale preoccupazione per lo più irrilevante.

Il buon senso non sempre produce i migliori risultati. Le migliori pratiche, tuttavia, sono state provate. Ciò rende le migliori pratiche una fonte di informazioni più affidabile.

Le migliori pratiche non sono le migliori e il buon senso non è comune. ;-)

Sia per le migliori pratiche che per il buon senso, mi piace pensarle come schemi; Ricorda la definizione di un modello: una soluzione in un contesto che risolve le forze in un contesto risultante .

Per qualsiasi cosa tu voglia fare, dovresti conoscere il contesto a cui si applica, le forze che risolve e il contesto risultante che crea. Quindi, decidi sulla tua squadra quali sono gli schemi che utilizzerai generalmente. (Questo può essere formale o informale, ma in entrambi i casi è molto più grande del solo libro Gang of Four. Include idiomi linguistici e librerie di helper locali, non solo schemi pubblicati.)

Se senti, in base alla tua esperienza, che in una determinata circostanza, sarebbe meglio non usare un determinato schema, ma fare qualcos'altro, far sapere alla gente. Probabilmente il contesto o le forze sono diversi qui (o forse il contesto risultante sarebbe indesiderato.) Non mi interessa se si tratta di una riunione, un commento in codice o cosa, ma se chiarisci che hai rotto il modello di proposito , sarai miglia avanti.

La migliore pratica è ciò che ti insegnano a scuola, Il buon senso è ciò che il capo vuole da te. Il primo crea software che soddisfa determinati standard di eleganza, stile e simili. Quest'ultimo paga le bollette / fa i soldi in modo da essere pagato ogni settimana.

Una è l'arte, l'altra è un'attività, troppi di noi la dimenticano.

Per esagerare un po ': la differenza è che il senso comune è il pregiudizio, la migliore pratica è (dovrebbe essere) la scienza

Nella mia esperienza, il "senso comune" è usato quando non si vuole fornire prove o almeno argomenti per un modo di fare le cose. Ciò non significa che la strada sia necessariamente sbagliata, ma non significa nemmeno che sia buona.

Tra le cose che ho incontrato, che sono state razionalizzate come senso comune ci sono queste gemme.

• il metodo HTTP è in gran parte irrilevante, utilizzare GET quando si trasmettono pochi dati, utilizzare POST quando si trasmette di più (ovvero, troppo per l'URL)
• le funzioni non dovrebbero essere troppo piccole, perché è difficile ricordare cosa fanno. una grande funzione è preferibile a 5 più piccole, perché puoi leggerla come una sola
• il database e il server web DEVONO essere eseguiti sulla stessa macchina, altrimenti il ​​servizio web rallenterà. L'unico modo per ridimensionare è accelerare il codice con gli hack e rinunciando all'astrazione, in modo che la potenza di una macchina sia sufficiente.

La cosa divertente di "Common Sense" è che non è così comune: scegli due squadre e lascia che dichiarino ciò che loro sono "buon senso", e goditi le guerre di religione.

D'altra parte, come "Best Practice" prenderei in considerazione i modi di fare le cose, che hanno un po 'più di "peer review". Per considerare qualcosa una "best practice", mi aspetto che sia formulata in modo sufficientemente chiaro in modo che possa essere presentata come un concetto ("programmazione strutturata" è la migliore pratica, "goto sono confusi, evitarli" è buonsenso), e applicato più di una volta, con buoni risultati.