Quando gli hacker di codice diventano pericolosi? [duplicare]

Debito tecnico

Gli hacker non sono sempre "cattivi". Molte volte possono portarti fuori dalla porta e spedire un prodotto che rielaborare le cose per essere il modo "giusto" ucciderebbe il progetto. Costruire un software è come costruire un business - a volte devi avere un piccolo debito per ottenere un'enorme vittoria a breve termine, a scapito del pagamento delle cose in un secondo momento.

Fondamentalmente, quello che vuoi fare non è solo prendere in considerazione quanto tempo ti salverà nel breve periodo VS quanto ti costerà a lungo termine, ma anche quanti soldi / quanti caratteristiche / quanti più clienti vincerò facendo questo hack e spedizione in anticipo rispetto a quando aspetto e consegno il mio concorrente per primo.

A volte le spedizioni prima sono le migliori, a volte le spedizioni successive con un prodotto migliore sono le migliori, ma tutto dipende da molti fattori a cui solo tu puoi rispondere.

Non sto affatto sostenendo gli hack in tutte le situazioni. Proprio come qualsiasi debito, deve essere restituito, e l'intrest varia a seconda dell'hac in modo tale che alcuni con cui puoi convivere e altri richiederanno assolutamente molto più tempo per poter progredire e aggiungere funzionalità dopo il rilascio.

Dovrai sempre dover riscrivere.

sempre .

A volte prima, a volte più tardi.

Pianifica su di esso. Progetta in modo da poter riscrivere. Pratica Late Binding e gli altri SOLID principi.

E riscrivi il più presto possibile per mantenere basso il debito tecnico.

In breve, un "hack del codice" è sempre una cattiva idea.

Ricorda.

Dovrai sempre dover riscrivere.

Falla finita il più velocemente possibile. Un hack è solo un debito.

È sempre meglio ridisegnare la tua soluzione durante la fase di progettazione / sviluppo. Dopo averlo distribuito ai clienti, dovrai supportarlo, il che potrebbe implicare più "hack" o il refactoring che avresti dovuto fare in primo luogo.

Se sei davvero impaziente per il tempo, suppongo che dovrai hackerare qualcosa insieme, ma assicurati di dedicare più tempo per un corretto refactoring di quel codice. In futuro, ringrazierai te stesso e gli altri sviluppatori del tuo team.

Gli hacker di codice vanno bene per provare un'idea perché puoi farlo rapidamente e vedere se funziona.

Gli hacker di codice non sono corretti quando li hai spediti, perché dovrai rivederli in seguito o causare bug che ti costeranno più tardi di quanto sarebbe costato rimuoverlo in primo luogo. Provocano debito tecnico.

Gli hacker di codice sono pazzi quando in realtà diventano come le cose vengono fatte sempre. il debito diventa quindi così sbalorditivo che nessuno osa guardarlo e preferisce ancora un altro hack del codice.

quindi la domanda diventa,

1. preferisci soffrire un po 'tutto il tempo ma prova a placare i dolori più grandi in seguito.

2. o semplicemente falla ora e diventa l'eroe per pochi preziosi minuti al costo di un grande dolore in seguito.

Ricorda, più alto è il piedistallo dell'eroe più difficile è la caduta.

Perché le nuove specifiche vengono create quando hai superato la fase di progettazione? Le specifiche non dovrebbero cambiare una volta iniziato il codice. Essere in grado di modificare un progetto per soddisfare un requisito di sistema è completamente diverso.

Se stai riscrivendo lo stesso sistema più volte, dovresti chiedere "Cosa sto facendo male?"

Questa domanda è vaga per rispondere effettivamente alla domanda, l'unica risposta accettabile è quella di evitare "hack di codice" avendo buone specifiche e design accettabili.

Supponiamo che tu abbia 2 opzioni di hacking rapido e profondo refactoring. Tutto ciò di cui hai bisogno è di risolvere 2 equazioni per loro:

[Total Cost of The option] = [Cost of the implementation] + [Cost of the consequences, i.e. further support, problems related with further changes]

Ovviamente l'implementazione dell'hack è più economica di profondi cambiamenti architettonici. La sfida sarà nella stima di ulteriori costi delle conseguenze dell'hacking

Anche in un mondo ideale dovresti fare questo:

if cost of hack < cost of rewrite:
    hack
else:
    rewrite

, che è quello che a ogni manager sano di mente interessa, ma che è anche così indistinto e sfocato da essere completamente inutile . Questo è un calcolo che sarà influenzato da tutto, da incognite sconosciute nei calcoli della complessità dello sviluppo, dalla possibilità di lasciare le persone perché il codice è una palla di fango, alla capacità del marketing di far girare la decisione a proprio vantaggio.

L'esperienza può essere d'aiuto, ma aspettarsi un'enorme discrepanza nelle stime o nel pensiero di gruppo. La tua scommessa migliore è probabilmente quella di cercare frutta a basso impatto come nomi di variabili illeggibili e migliorare il codice un passo alla volta .

Gli hacker sono sempre una cattiva idea. MA se non sei il project manager, allora non è la tua preoccupazione se l'hack dovrà essere trasformato in una riscrittura lungo la linea. L'unica cosa che dovresti fare è spiegare perché hai bisogno di hackerare qualcosa dati i limiti di tempo / budget e che sei preoccupato delle conseguenze. Mantenere questa corrispondenza registrata. Il PM avrà quindi informazioni sufficienti per prendere una buona decisione e se insiste sull'hack, LUI è la colpa, non tu.

Ecco come funziona il gioco, piaccia o no.