Come si imposta un ragionevole limite di tempo in alcune missioni esplorative?

Esprimerò un'opinione possibilmente controversa qui.

And as the coder, how much time is it reasonable to spend preening the code?

Quasi nessuno se me lo chiedi! Ho visto aziende assumere nuovi team di sviluppatori per mantenere codebase legacy in modi che andavano oltre il trattare il legacy codebase come qualcosa di più di una scatola nera - come qualcosa da attraversare nei dettagli dell'implementazione ... e dopo un decennio la nuova squadra non era ancora così vicino come gli autori originali del codice. Nel frattempo, mentre tentavano di sondare e sondare i dettagli dell'implementazione del codice legacy, il software diventava sempre più buggato in funzionalità esistenti e vecchie, non in quelle nuove, poiché gli sviluppatori stavano cercando di modificare il vecchio codice che non potevano comprendere così come gli autori originali.

Questo è per codice non banale, ovviamente, e generalmente codice che non è stato progettato esattamente contro standard ragionevoli.

A mio parere, tale codice legacy dovrebbe essere trattato come una libreria opaca, da chiamare, non modificata. Il vecchio codice, a condizione che non stia funzionando verso la completa obsolescenza, dovrebbe sempre più trasformarsi in una scatola nera - un pacchetto stabile destinato a essere usato, non modificato. Le interfacce dovrebbero essere identificate ed estratte, laddove possibile, dovrebbero essere creati test di correttezza e le implementazioni non devono essere toccate, né pienamente comprese a meno che non richiedano assolutamente modifiche (es: sono buggy) ... a che punto se sono buggy e spesso ho bisogno di aggiornamenti per i dettagli di implementazione, prenderei in considerazione la sostituzione di quella sezione inaffidabile del codice legacy con qualcosa di nuovo (stessa interfaccia ma nuova implementazione) come potenzialmente più veloce di sperare che qualche nuovo sviluppatore sia in grado di comprendere il vecchio codice che l'autore originale non ha 'anche scrivere correttamente e testare correttamente. Cercare di comprendere il codice che non funziona nemmeno correttamente scritto da qualcun altro molto tempo fa è spesso un tentativo infruttuoso. È come cercare di capire come funziona un motore a combustione invertendo la progettazione di uno rotto il cui design è sempre incline a far esplodere a caso il motore.

Per quanto riguarda la capacità di decifrare il codice, spesso lo vedo come una funzione dell'interfaccia. Un'interfaccia ben documentata in cui ogni funzione non causa più di un singolo effetto collaterale produrrà spesso un'implementazione che è proporzionalmente facile da capire. Nel frattempo un'interfaccia controintuitiva che, di per sé, è difficile da capire e da usare, avrà spesso implementazioni che sono proporzionalmente difficili da comprendere. Che cosa dovrebbe fare qualcosa per tutti i possibili casi di input è la prima cosa da capire prima di capire come funziona, e alcune interfacce sono in realtà così complesse con così tanti disparati effetti collaterali che è difficile persino rispondere alla domanda "cosa" senza sollevando ulteriori "e se?" domande per casi limite difficili. In tal caso, l'implementazione sarà in genere senza speranza da decifrare come interfaccia.

Naturalmente a volte un'interfaccia chiara e ben documentata può ancora utilizzare un algoritmo molto complesso per l'implementazione, ma relativamente parlando, il codice sorgente sarà spesso relativamente più facile da capire se l'interfaccia è facile da capire. La prima cosa che vorrei fare prima di entrare nei dettagli di implementazione di qualcun altro è studiare l'interfaccia necessaria per interagire con il loro codice e costruire idealmente un test per verificare le mie ipotesi e per assicurarmi che l'interfaccia soddisfi correttamente i suoi requisiti documentati. Se l'interfaccia è semplice e posso facilmente comprenderla, spesso sarà anche il codice che implementa l'interfaccia e, in caso contrario, poiché l'interfaccia è così chiara e facile da capire, ci vorrà poco tempo per inventare un nuovo implementazione che soddisfa gli stessi requisiti.

Per quanto riguarda l'ultima domanda sul tempo richiesto, vorrei prima fare tutte le cose sopra menzionate. C'è un anticipo di tempo necessario, variabile ma non troppo variabile per capire come fare la prossima stima se l'obiettivo è familiarizzare con una base di codice legacy.

Devi distinguere due diverse domande qui.

1. Quanto tempo è necessario per comprendere e gestire il vecchio codice base? È difficile da prevedere e in gran parte fuori dal tuo controllo. Puoi fare solo stime basate sulla tua esperienza precedente e altrui. Le persone ottengono un po 'meglio in questo, più esperienza hanno con il codice legacy, ma la stima avrà sempre un ampio margine di errore.

2. Quanto tempo vale la pena da spendere per questo? Questa domanda ha una risposta piuttosto chiara. Puoi permetterti solo di dedicare del tempo a gestire il vecchio codice, a patto che non sia più il tempo di quello che avresti bisogno di sostituirlo con un nuovo codice. Per essere sicuri, le stime per i nuovi progetti software sono anche incerte, ma non sono neanche lontanamente così incerte come le stime sul grande vecchio software sconosciuto. Pertanto, dovresti stabilire le migliori stime dei costi di riscrittura e di ristrutturazione e confrontare semplicemente i costi.

Consente di confrontare questo con l'autore originale del programma. L'autore originale (ce ne possono essere più di uno, ma ne ipotizziamo uno per il momento) probabilmente ha speso centinaia se non migliaia di ore su un programma di lavoro ben congegnato utilizzato da molte delle dimensioni di 10.000 righe.

Idealmente lo scopo di leggere attentamente il codice è imparare da esso e diventare un po 'più fluido con la conoscenza dell'interazione di detto programma. Qual è il massimo che potresti mai sperare di ottenere facendo così? Bene, la luce alla fine del tunnel è come fluente come lo stesso autore originale. La mia idea è che la parte più difficile della scrittura del codice sia innanzitutto la comprensione del codice che stai scrivendo. La parte di scrittura vera e propria è solo un semplice esercizio di digitazione, non di più. Quindi il tempo che impiega a essere fluente come l'autore originale è il tempo impiegato dall'autore per scriverlo (meno il tipo impiegato per scriverlo, il che è quasi trascurabile).

Quindi, se l'autore originale ha impiegato 1000 ore per scriverlo, ci vorranno almeno 1000 ore per diventare fluenti nel programma di quell'autore. Ovviamente non vorrai dedicare quella quantità di tempo, e fortunatamente per te, più devi imparare dal codice, più impari. Ciò significa che se dedicherai la metà di quelle 1000 ore, conoscerai molto più del 50% del programma. Saprai quasi il 99%. Allo stesso modo, se dedichi il 10% di quel tempo (100 ore), dovresti sapere vicino al 95%.

In definitiva si tratta di decidere quanto è necessario conoscere il programma che determina quanto a lungo dovresti dedicare ad apprenderlo, ma se l'ultimo punto è diventare un esperto, l'1% è un buon punto di partenza. Nel caso di 1000 ore, ciò equivale a 10 ore o poco più di un giorno in modo da diventare fluente almeno al 50%.

Supponendo che non ci siano problemi da risolvere nel programma e avere il tempo di dedicare, più dedichi a imparare come funziona, meglio sarà, naturalmente, ma il tempo è denaro dopotutto. È mia opinione personale che l'1% è un compromesso ragionevole. Se sei fluente al 50%, significa che hai una probabilità del 50% di sapere dove controllare o sapere dove si trova il problema quando si verifica un problema.

Ovviamente puoi semplicemente affrontare ogni problema come uno scienziato che studia una grande scatola nera, ma non lo consiglierei per essere veramente efficace. Come si suol dire, "settimane di programmazione possono farti risparmiare ore di pianificazione."