Questa è fondamentalmente una scelta a lungo termine e a breve termine.
-
È possibile implementare una funzione in un'ora eseguendo hack sporchi,
-
Oppure puoi passare la settimana prossima a studiare i bisogni reali degli utenti / del tuo capo, tradurli in requisiti, rifattorizzare il codice per accogliere il codice di base per la nuova modifica, scrivere test, implementare le modifiche e documentare il nuovo codice.
La settimana meno un'ora che ottieni immediatamente ha un costo a lungo termine. Costa denaro ogni volta che qualcuno (o tu in sei mesi) deve leggere il codice. Costa denaro quando qualcosa si rompe, e nessuno può trovare la ragione del problema. Costa denaro quando devi implementare nuove modifiche, ma non puoi, perché la base di codice diventa troppo legacy con cui lavorare.
Come gestirlo?
Dicendo al tuo capo il tempo necessario per fare il cambiamento. No, non puoi farlo in un'ora, perché l'unica cosa che puoi fare in un'ora è un attacco rapido, e tu sei un programmatore professionista, non un tipo veloce di hacks.
Incontrerai spesso la pressione dei tuoi superiori. Ricorda che la durata che fornisci è non negoziabile . Se il capo desidera che la funzione venga implementata per domani, digli che non è possibile farlo . Immagina se il tuo capo dica a Boeing che ha bisogno di viaggiare da Seattle a Hong Kong in venti minuti. Chiedere di implementare la funzione di una settimana in un'ora è simile.
Ricorda che sei un programmatore professionista, e probabilmente il tuo capo non lo è. Questo crea una situazione interessante in cui potrebbe sembrare che il tuo capo abbia una scelta, ma in effetti, sei quello che prende le scelte tecniche - il che significa anche che è tua responsabilità intraprendere scelte intelligenti che rendono la tua azienda competitiva . È facile: ciò che il tuo capo desidera è alta qualità, prezzo basso e programma breve, tutti e tre allo stesso tempo. Poiché ciò che vuole non è possibile , sta a te trovare il giusto equilibrio.
Devi sempre essere consapevole che il tuo capo potrebbe non sapere le cose che conosci, quindi non parlargli in termini tecnici. Se spieghi che puoi fare qualcosa in una settimana, o la stessa cosa in due giorni, ma questo aumenterà il debito tecnico, per la maggior parte delle persone non tecniche significa: "Posso farlo in una settimana, o in due giorni se Mi sforzo. " Non sanno quale sia il debito tecnico, quindi interpretano la parte che hanno capito. Il tuo capo non sa cosa sia il test, o perché lo stile di codifica comune è importante, quindi non preoccuparti di questi aspetti. Non dovrebbe aver bisogno di scegliere tra una copertura di codice mirata del 95% o una copertura del codice mirata al 40%: ancora una volta, questa è la tua responsabilità come programmatore principale (o unico) della società.
Allo stesso modo, il tuo capo non sa se una funzione dovrebbe richiedere un'ora o una settimana. Ho smesso di contare i casi in cui i miei clienti erano veramente convinti che un progetto di sei mesi possa essere svolto da una persona in meno di una settimana e i casi in cui erano convinti che un cambiamento avrebbe richiesto settimane di sviluppo, mentre consisteva semplicemente di cambiare un valore di una costante e ricompilare.
Negozia e proponi soluzioni. Se il tuo capo desidera orari più brevi, suggerisci di rimuovere questa funzione o quella, o di rendere questa cosa più basilare. O trovare un modo creativo per soddisfare le esigenze dei clienti riducendo al minimo lo sviluppo personalizzato. Alcuni problemi possono anche essere risolti senza scrivere alcun codice. Il tuo capo non dovrebbe saperlo; probabilmente, non sa nemmeno esattamente di cosa tratta la programmazione.