Buon design: quanta hackyness è accettabile? [duplicare]

Attendi fino a quando non hai circa tre hack a causa dello stesso problema e poi refactoring.

Se stai solo evitando una singola hack, allora sospetto che tu non abbia effettivamente abbastanza informazioni per determinare la migliore soluzione al problema. Sospetto che sarai in grado di trovare una soluzione migliore ritardando la sua implementazione fino a quando non si manifesteranno più problemi della soluzione corrente.

Fondamentalmente, il ritardo darà più tempo per raccogliere informazioni e quindi produrrà un codice migliore quando lo farai. Tuttavia, il ritardo tenderà anche a peggiorare la situazione. Quindi, dovresti tenere d'occhio la situazione e quando è chiaro che sta peggiorando, dovresti tentare di risolverlo.

In primo luogo, parla con un manager e (io) sosterrò per "fallo bene". Tuttavia, il tuo datore di lavoro probabilmente non vuole pagarti per cambiare tutto quel codice quando c'è una scorciatoia. In questa situazione, inserisco l'hack in una funzione o macro ben definita e lo documento molto chiaramente.

Prima di tutto essere pragmatici a un certo punto o l'altro è una buona cosa. Non sembra esserci alcun pericolo immediato nell'affrontare A diverso da quello che non è il "modo giusto per farlo". Finché documenta chiaramente il odore di codice può essere accettabile.

Quello che devi fare è pesare i pro ei contro sia a breve che a lungo termine

• È il tempo che dedicheresti a fare un buon rapporto qualità-prezzo per il tuo cliente?
• Hai il tempo di farlo o potresti creare più valore spendendolo su qualcos'altro
• Quanto è probabile che soffrirai della "minore flessibilità" e di quanti sforzi extra ti porteranno.
• Puoi posticipare il refactoring fino a quando non ti imbatti nel problema della "flessibilità inferiore"

Per quanto riguarda le linee guida generali. Ti sei imbattuto nella tipica trappola di rilevamento di un difetto di progettazione troppo tardi, in cui ora è diventato così costoso da correggere che quasi non puoi più farlo. Non è sempre possibile prevenirlo, ma cose come le revisioni del codice e persino la programmazione delle coppie riducono le possibilità che ciò accada. Dai anche un'occhiata a questa pagina wiki sul refactoring del codice e qualunque cosa tu faccia ... "refactoring in anticipo, refactor spesso"

Purtroppo questo tipo di codice accade nel progetto che ha fretta ..

Se hai il tempo e a lungo termine dà più benefici, allora sicuramente esegui il refactoring.

Se possedevi interamente la società e dovevi pagare qualcun altro per la soluzione, A o B, quale sceglieresti?

Di solito vado evitando l'hacky, ma un rapporto 1000/1 di sforzo è un caso estremo. Se sei sicuro l'hack è il primo gradino lungo una china scivolosa, quindi evita l'hack se hai tempo (e se non fai presto il tempo), ma se non dovessi dire di fare lo hack e forse funzionerà benissimo - il futuro potrebbe sorprenderti.

Se fai lo scribacchino allora cambia idea, sei solo una linea di codice che sta peggio di prima (a quanto ho capito). Se scrivi 7500 linee di codice e si scopre che tutto ciò che fanno è sostituire 1, non puoi recuperare il tempo.

Inoltre, 1.000 nuove righe di codice potrebbero aggiungere più complessità di una riga di codice hacky.

Se i numeri cambiano nel tempo e si fa un caso migliore per scrivere il centralino di messaggistica, il mio consiglio cambierebbe, ovviamente.

Non farlo se possibile

Il problema con l'aggiunta di 1 hack è che apre le porte per inserirne un altro e un altro e alla fine ti ritroverai con una struttura fragile e fragile che è praticamente l'antitesi di ciò che stai cercando di costruire. - Estremamente ottimistico

Assunzione di debiti tecnici

Il problema con quello che ho appena detto è che è una torta nel cielo, non sempre abbiamo il lusso della soluzione perfetta o del tempo. Tuttavia, se puoi sottolineare al tuo capo che si assumerà un debito tecnico significativo con il "trucco". Possono accantonare il tempo più tardi per rimborsare il debito tecnico prima che diventi un problema troppo grande e ostacola lo sviluppo futuro.

Non è questo IMO complesso. Stai valutando il tempo risparmiato facendo l'hack contro il rischio che A. potresti doverlo fare comunque alla fine, quindi l'hacking era uno spreco e B. L'hack ha maggiori probabilità di causare problemi di manutenzione lungo la pista.

Non esiste una regola che devi sempre refactoring quando richiesto.

Un trucco è accettabile. Gli hack Five-ish dello stesso tipo indicano uno schema che probabilmente dovrebbe essere indirizzato a un livello superiore. Sembra inoltre che tu abbia scontato il costo nascosto di riscrivere una grande quantità di codice e tutti i bug che introdurrai.

E: è davvero un hack? Dalla tua descrizione, le classi non possono funzionare da sole [poiché hai bisogno di un "pannello di controllo dei messaggi"], quindi perché pensi che accoppiarle in un modo breve e diretto sia sbagliato?

Se hai tempo e copertura del test, esegui la riscrittura. Certo, l'alternativa potrebbe essere una linea per te, ma cosa succede se vinci la lotteria e lasci il lavoro domani? La tua sostituzione saprà di quella linea critica nascosta tra le altre 7500? E quanto tempo ci vorrà per rielaborare 7500 linee comunque? Due, tre giorni? Sembra che tu sappia cosa stai facendo, in realtà non è altro che un compito di refactoring (più grande del solito).

Ovviamente, se stai andando contro una scadenza, allora piano A è la strada da percorrere. Assicurati di documentare sia l'hack sia "il modo giusto" che avresti fatto se avessi avuto il tempo. Poi, si spera, avrai la possibilità di retrocedere il DTRT dopo il rilascio.