Nell'ingegneria del software, pochi approfondimenti sono acquisiti attraverso science . Invece, esperienza e credenze completamente infondate modellano le nostre decisioni.
Ciò è in parte dovuto alla giovane età del nostro campo (l'ingegneria del software come campo emerso alla fine degli anni '60), ma soprattutto a causa del fatto che la psicologia umana può essere abbastanza difficile da misurare.
Molte persone hanno cercato di eseguire studi per uccidere i dibattiti più controversi con i dati. La tipizzazione statica o la digitazione dinamica migliorano la produttività del programmatore? camelCase o snake_case più leggibile? I progetti che usano TDD finiscono più velocemente? Mentre alcuni di questi studi hanno prodotto risultati interessanti, molti di questi hanno problemi metodici:
- Dimensioni dei campioni molto piccole. Non puoi generalizzare da 20 probandi.
- Struttura campione non rappresentativa. Quello che risulta essere buono per gli studenti universitari che hanno appena completato il loro primo corso Java potrebbe non essere il migliore per te.
- Mancanza di gruppi di controllo. A quale livello di riferimento si confronta lo studio?
- Effetti molto sottili. I programmatori sono umani, il che significa che possono essere molto diversi. Potrebbe essere difficile individuare qualsiasi effetto significativo attraverso tutto questo rumore statistico.
Di conseguenza, molti studi sono presi più sul serio di quanto dovrebbero. In particolare:
- Per effetti deboli, potresti vedere più studi in conflitto.
- Gli studi tendono a essere citati da coloro che si sentono convalidati da quello studio, ignorando gli studi in conflitto.
- La maggior parte delle persone (incluso me) non ha mai letto l'abstract e ignora le carenze metodiche.
Per una discussione approfondita sugli studi su un singolo argomento, guarda Lingue statiche e dinamiche: una revisione della letteratura di Dan Luu .
Riassumendo: gli studi esistono ma tendono a essere quasi inutili. Per il momento, dovremo fare affidamento sulla nostra intuizione ed esperienza.
C'è un altro take away qui: approcci diversi non sono intrinsecamente superiori a un altro, o solo con un piccolo margine. Ho deciso che io preferisco kebap-case su snake_case su camelCase, ma questo non significa che convertirò tutti in snake_case: se c'è qualche effetto misurabile, è probabilmente trascurabile. Più importante di entrambe le convenzioni è coerente. Se lavoro su una base di codice CamelCase, uso solo camelCase.
Ed è così che vengono create le convenzioni di codifica: qualcuno scrive ciò che hanno scoperto essere le migliori pratiche, e quindi tutti si attengono a ciò.
Se c'è una regola veramente idiota nello standard di codifica che viola il buon senso (o è davvero inusuale), allora si può probabilmente sostenere che sia cambiato. Ma la maggior parte degli argomenti come la lunghezza della linea o le convenzioni di denominazione delle variabili o lo stile di parentesi non sono così importanti. Ho problemi più interessanti in attesa di essere risolto.