Un altro modo per esprimere la codifica 'sporca'

Credo che tu intenda tecnico debito .

Per spiegare, la soluzione "sporca" è una soluzione che crea molto debito. L'altra soluzione è quella che non lo fa. Spiegare quale sia il debito tecnico è molto meglio che confrontare soluzioni "cattive" e "buone".

Fondamentalmente, trovare un nome per la soluzione "sporca" potrebbe non essere un problema. Perché anche questa soluzione "sporca" potrebbe avere i suoi meriti. Ancora peggio, potrebbero esserci più di due soluzioni, alcune più "sporche" di altre. È molto meglio confrontare queste soluzioni sulla base di quanto impegno e di quanto debito tecnico esse affrontano. E se la persona comprende il debito tecnico, diventa più facile distinguere tra le soluzioni probabilmente multiple.

I don't mean 'dirty' as in uncommented and untabbed code, but simply as in faster, hackishy code.

Che ne dici di tape duct tape programming?

link

In base alla tua descrizione, credo che trasmetta bene i vantaggi del tuo approccio.

D'altra parte, se si tratta di prototipazione (come suggerito da @mouviciel in un commento), c'è ancora il concetto di proof-of-concept .

Se hai dimostrato che il codice hackish è effettivamente più veloce, basta documentare che è stato scelto per motivi di prestazioni. Vorrei documentarlo come un commento nel codice. Per fare questo è necessario sviluppare e testare entrambe le soluzioni

Se è stata creata una soluzione rapida e sporca per motivi di costi immediati, presentala come tale. Si noti che introduce il debito tecnico che potrebbe dover essere ripagato in seguito. È stata la mia esperienza che in alcuni casi la soluzione rapida e sporca spesso costa di più per testare e preparare la produzione di una soluzione opportunamente codificata. Questo è il caso in cui i pagamenti per interessi anticipati sul debito tecnico superano il costo del debito tecnico.

In altri casi, le soluzioni rapide e sporche finiscono per includere più codice che una soluzione opportunamente codificata. Possono essere più difficili da capire e correggere quando necessario (parte del debito tecnico).

Sii chiaro dei costi (inclusi i tempi di consegna e l'affidabilità) di entrambe le soluzioni.

Se ci sono problemi con la soluzione rapida e sporca, rispedirli al dispositivo d'avviamento con un calendario appropriato per la soluzione. Questo può aiutarli a capire il costo di ciascun approccio. Anche un buon mentoring e recensioni di codice possono essere appropriate.

Il problema nel dire dirty o hackish è che è probabile che pensino al tuo codice come un crawl spaziale sporco. Se è più economico e nessuno lo vedrà comunque, perché dovrebbero interessarsene? È necessario chiarire che la soluzione hackish è più simile a una base instabile. Se è necessario aggiungere alla "costruzione", sarà necessario correggere la fondazione (a un costo maggiore rispetto alla sua creazione definitiva) o ricostruirla del tutto.

Se vuoi essere sicuro che gli individui non tecnici e attenti al business comprendano ciò che stanno scegliendo, comunica in termini di tempo / costi .

Piuttosto che descrivere i metodi di programmazione, utilizzerei un termine per descrivere il tipo di prodotto che stai producendo. Darei opzioni di quality code o throw-away code e descriverò queste ultime come non scalabili e non manutenibili. Questo rende chiaro che aggiungere al codice sarà più costoso che riscriverlo. L'unica ragione per scegliere una soluzione del genere è se sei sicuro che il pezzo che stai costruendo non cambierà mai e sei disposto a pagare la differenza se ti sbagli.

Considerate anche che, a meno che i responsabili delle decisioni non siano anche programmatori, non capiranno fino a che punto le vostre scorciatoie da hacker ostacolino il cambiamento in futuro. Solo tu lo sai. Quindi potrebbe essere meglio se ottieni da loro l'importanza stimata, la longevità e la probabilità di cambiamento per un pezzo e prendi le decisioni tecniche da solo.

I termini comuni sono picchi, prova di concetti e prototipi.