Codice buggy esistente o uno nuovo di zecca? (Dalla prospettiva temporale)

Come mi è stato detto: "Una soluzione all'80% nel tempo è meglio di una soluzione al 100% troppo tardi". L'avrei finito usando la libreria legacy e consegnato un aggiornamento più tardi. È importante pianificare questo aggiornamento in anticipo, idealmente ora. Come accennato da ElYusubov, Design by Contract è una buona parola chiave. Potresti mantenere l'interfaccia della biblioteca, in questo modo ci sarebbe un cambiamento di tranquillità, anche in altri progetti. Se l'interfaccia stessa è così imperfetta e arrugginita, potrebbe essere utile un Bridge .

Prenderò in considerazione la scrittura di una serie di test unitari per la libreria in questione, che esercitano solo la funzionalità di cui si ha bisogno dalla libreria (ma lo fanno completamente), e quindi vediamo se la libreria funziona correttamente solo per ciò di cui hai bisogno o se fai scattare abbastanza bug per renderlo inutilizzabile.

Se non hai ora un set di unittest da cui puoi facilmente creare la tua libreria.

Come hai anche accennato, prima riprendi il tuo progetto e prova a consegnare in tempo il prima possibile. Tuttavia , mentre consegna il progetto replace dependencies alla tua cosiddetta "libreria buggy" tramite introduction del Design per contratto principio.

In alcuni termini è chiamato Programmazione con contratti , dove a contract definisce semplicemente i requisiti di una particolare classe; in realtà non controlla l'implementazione della classe. Lo scopo di un contratto è quello di assicurarsi che le specifiche progettuali previste siano soddisfatte e non in conflitto tra loro. In altre parole, un contratto aiuta a identificare i difetti di progettazione.