La differenza tra le migliori pratiche e il buon senso?

Le migliori pratiche sono pratiche che sono state trovate per funzionare bene in un campo di circostanze relativamente ampio. Il problema con loro è che A) l'espressione a volte è 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 buone pratiche sono grandi quando vengono fornite spiegazioni 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 reclamano il loro la posizione è "senso comune". È bello avere ma povero come linea guida per una squadra da seguire.

Penso di averlo indietro.

Quando insegno ai programmatori le basi della sicurezza, insegno sempre loro a usare best practices , e tuttavia quando si tratta di esperti di sicurezza (o più programmatori esperti di sicurezza) non parlerò mai di best practices , infatti lo farò spesso li violano.

Una definizione migliore sarebbe:

"Best Practices" are common sense from experts, as should be applied by non-experts.

Cioè, non si arriva a reclamare "buonsenso" finché non si ha abbastanza esperienza nel campo dato per comprendere i sottili compromessi; e quando lo fai, non dovresti più seguire ciecamente le "migliori pratiche" del taglia-biscotti.

Le "best practice" sono un segnaposto temporaneo finché non hai esperienza sufficiente per utilizzare il tuo "buon senso".

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

La disponibilità a sperimentare alternative (in codice non critico, ovviamente - preferibilmente progetti personali e throw-away) può aiutare a costruire l'esperienza necessaria.

Il buonsenso non è lo stesso dell'esperienza, ovviamente, e non hai sempre bisogno di molta esperienza per vedere il difetto nell'applicare una buona tecnica nel posto sbagliato - ma è molto facile costruire false razionalizzazioni per entrambi -applicare e sottovalutare una tecnica, e poiché "senso comune" qui chiaramente non è una conoscenza innata della programmazione, tale senso è chiaramente "comune" solo all'interno di particolari gruppi.

È molto facile "schierarsi". Impossibile, in effetti, evitare - a volte una parte ha ragione, e l'altra è davvero sbagliata, e sarebbe irrazionale discutere di equilibrio. Il guaio qui è che il vero inferno non è tanto la valutazione di una buona pratica quanto la pertinenza, ma quando due opinioni contrastanti di buone pratiche si scontrano.

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

Ciononostante, è ancora importante imparare dall'esperienza di altre persone e anche da te - cioè scoprire quali sono le migliori pratiche, perché sono usate e quali sono i vantaggi ( e svantaggi).

Mi sembra che questa domanda sia un inganno semantico. Se usiamo queste definizioni, non ci sono dubbi:

Best Practice: un modo sperimentato sul campo per risolvere un problema in un dato dominio (cioè le best practice in tempo reale sono totalmente estranee alle best practice del database)

Common Sense: esperienza professionale che serve ad avvisare il programmatore di insidie per evitare

Alla fine, una Best Practice è un modello di meta design per risolvere una particolare congruenza di problemi ed è scelta sulla base di esperienze del mondo reale, mentre Common Sense è una guida alla risoluzione dei problemi basata sull'osservazione generale su più set di problemi.

Common sense = You.CommonSense

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

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

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

(le mie parole in grassetto)

Fondamentalmente - gli umani non sono bravi nell'usare il buon senso in aree come questa in cui non abbiamo sviluppato un sistema radicato, quindi dovremmo SEMPRE utilizzare una serie documentata di standard e non fare affidamento su il nostro buon senso!

Il buon senso non corrisponde all'apprendimento di modelli anti, né è diverso da, o in contrasto con le migliori pratiche.

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

anti-patterns are only employed if there is no other way, and even then only under very limited circumstances

Sono a conoscenza del fatto che questo non è il modo in cui si presentano gli anti-modelli. È da un accrescimento di fattori culturali e sociali; di ignorare le migliori pratiche e le norme 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 shortcut che è un incubo di manutenzione; ecc. Nessun corpo si propone di adottare deliberatamente un anti-modello - semplicemente crescono.

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

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

Questa è una tesi di scivolosità che spesso si trasforma in una guerra religiosa.

Quasi tutte le migliori pratiche possono essere neutralizzate con un caso valido per fare il contrario.

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

In alcune situazioni il buon senso e le migliori pratiche sono persino in contrasto 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 marketing che cercano di vendere strumenti o corsi di formazione personale non informati.

Anche quando il tuo intero team è d'accordo sul fatto che qualcosa è il migliore, non è sempre possibile implementarlo in questo modo per diversi fattori vincolanti.

IMHO devi usare le migliori pratiche come guida su cosa considerare più attentamente nel tuo progetto. Potresti avere un valido motivo per deviare, ma probabilmente devi assicurarti che tutti gli altri membri del team siano d'accordo prima di andare a 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 esso odierà. Tutti odiano il codice che non è il loro stile e tutti danno la colpa a chiunque se ne vada, quindi o lo spiegherai al prossimo dev dopo che si lamenteranno di qualcosa, o non ci sarai e si parlerà male indipendentemente da come lo si codifica. Ciò rende questa preoccupazione per lo più irrilevante.

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

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

Per le migliori pratiche o il buon senso, mi piace pensare a loro come a modelli; Ricorda la definizione di un pattern: una soluzione in un contesto risoluzione delle 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 i modelli che utilizzerai in genere. (Può essere formale o informale, ma in entrambi i casi, è molto più grande del semplice libro Gang of Four. Questo include idiomi linguistici e librerie di helper locali, non solo modelli pubblicati.)

Se ritieni, basandoti sulla tua esperienza, che in una certa circostanza, sarebbe meglio non usare un dato schema, ma fare qualcos'altro, far sapere alla gente. Probabilmente il contesto o le forze sono diverse qui (o forse il contesto risultante sarebbe indesiderato.) Non mi interessa se si tratta di un incontro, un commento di codice o cosa, ma se si rende chiaro che si è 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 formarti. Il primo crea un software che soddisfa determinati standard di eleganza, stile e simili. Quest'ultima paga le bollette / fa i soldi, quindi vieni pagato ogni settimana.

Uno è arte, l'altro, troppi di noi lo dimenticano.

Per esagerare un po ': la differenza è Common Sense è Prejudice, Best Practice è (dovrebbe essere) Science

Nella mia esperienza, 'Common Sense' viene usato quando non si vuole fornire una prova o almeno argomenti per un modo di fare le cose. Ciò non significa che il modo sia nettamente sbagliato, ma non significa che sia buono.

Tra le cose che ho incontrato, quelle sono state razionalizzate perché il buon senso sono queste gemme.

• il metodo HTTP è in gran parte irrilevante, usa GET quando trasmetti pochi dati, usa il POST quando trasmetti di più (vale a dire molto 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
• il database e il server web devono essere eseguiti sulla stessa macchina, altrimenti il webservice rallenterà. L'unico modo per ridimensionare è accelerare il codice tramite hack e abbandonando l'astrazione, in modo che sia sufficiente la potenza di una macchina.

La cosa buffa di "Common Sense" è che non è così comune: scegli due squadre e lascia che loro dichiarino che cosa sono "buonsenso" e goditi le guerre di religione.

D'altra parte, come "Best Practice" prenderei in considerazione modi di fare le cose, che hanno un po 'più di' peer review '. Per considerare qualcosa una "best practice", mi aspetterei che fosse formulata in modo abbastanza chiaro da poter essere presentata come un concetto ("la programmazione strutturata" è la migliore pratica, "il gotos è confuso, evitali" è un buon senso) e applicato più di una volta, con buoni risultati.