Come si aggiunge la funzionalità a una classe inizialmente progettata in modo errato? [duplicare]

Question

Come si aggiunge la funzionalità a una classe inizialmente progettata in modo errato? [duplicare]

#1 da (15 voti)

3

Ho una classe di chirurgo che cambia costantemente

class Surgeon
{
   string name, discipline;
 public:
    Surgeon(string _name, string _discp) : name{_name}, discipline{_discp}{}
    void writeDir(string _dir);
    void readDir(string _dir);
}

Ora devo aggiungere le impostazioni di registrazione a Surgeon. Tenendo presente i principi SOLID questo mi costringe a tornare in classe Surgeon aggiungendo impostazioni di registrazione e modificare tutto nella classe del chirurgo. Ora, sono anche consapevole che l'attuale implementazione del software aggiunge già valore all'azienda. E il refattore non è necessario, ma per fare questo compito ho bisogno di rifattorizzare l'intera classe. Se aggiungo solo la funzionalità che funziona con il design attuale, sto semplicemente perpetuando un cattivo design.

Da dove proviene l'ingegnere software il maggior valore? Dovrei produrre codice che mostri i risultati rapidamente, ma è soggetto a errori in futuro o dovrei ritardare i risultati rapidi per produrre un buon codice che sia più robusto? Quale sarebbe il mezzo felice se ce n'è?

design engineering c++ software

posta user3904534 03.01.2018 - 21:36

fonte

1 risposta

Leggi altre domande sui tag design engineering c++ software

Cosa fare con le eccezioni derivanti dai bug? La ridenominazione variabile in tutta la soluzione produrrà un sacco di rumore nella colpa di git. Cosa fare?

score 15 · Answer 1

And refactor is not necessary, but in order to do this task right I need to refactor the whole class.

Questo è contraddittorio. Non è possibile affermare che il refactoring non è necessario specificando che la classe deve essere sottoposta a refactoring. Ti trovi in una situazione in cui, per seguire i principi SOLID, devi refactoring il codice esistente. Il fatto che "l'attuale implementazione del software apporti già valore all'azienda" è irrilevante: non si rifatta il codice esistente perché non ha valore; lo rifatti perché non corrisponde al nuovo design .

Should I produce code that shows results quickly but is prone to errors in the future or should I delay quick results to produce good code that is more robust?

Non c'è una risposta generale a questo.

Se è essenziale avere risultati visibili veloci per mostrarlo all'analista aziendale e iterare rapidamente in base al suo feedback, puoi farlo. Se lo fai, assicurati che l'analista aziendale (e possibilmente il project manager) comprenda le implicazioni, ovvero che stai facendo un prototipo , ovvero un codice che sarà gettato via per poter scrivere invece il codice di produzione.

Se non è necessario avere risultati visibili veloci o se sai che le persone con cui lavori non capiscono cosa significano i prototipi e che non appena vedono alcun risultato, ritengono che il tuo lavoro sia finito, fornire una stima in base a quanto tempo occorrerebbe per scrivere il codice di produzione dall'inizio. La scrittura del codice di produzione include il refactoring e il test: non sei pagato per digitare il codice, ma per progettare un software affidabile e funzionante.