Quando non si sposta un codice "C style" in "C ++ o Object Oriented"?

Question

Quando non si sposta un codice "C style" in "C ++ o Object Oriented"?

#1 da (5 voti)

3

Contesto

Io sono (parte del team A) lo sviluppo di una funzionalità che dipende dalle nuove API fornite dal team B. Le vecchie API (fornite anche dal Team B) sono presenti e questo è il modo in cui vengono utilizzate nel nostro codice. .

int someFunction() {
 //-- lots of code here
 oldAPI.func1();
 //-- lots of code again
 if (something)
     oldAPI.func2();
 else oldAPI.func3();
 //lots of code
 // ans so on
 }

Avevamo bisogno di completarlo rapidamente, quindi ho appena modificato il flusso esistente per utilizzare newAPI e testato con alcune chiamate segnaposto.

Poco dopo aver completato ... la squadra B ci ha informato che ci vorrà più tempo.

Ora ho due opzioni ...

Opzione 1 : aspetta che la squadra B sia completata; spingere il tuo codice lungo / dopo di loro

Opzione 2 : fai in modo che il tuo codice supporti sia vecchio che nuovo; basato su una configurazione.

se scegliamo l'opzione 2; ci sono due approcci ...

Approccio 1 : modula il tuo codice; e usa il polimorfismo nel tuo codice.

 class API_BASE {virtual funct1(),func2(),func3()};
 class API_OLD : API_BASE {funct1(),func2(),func3()};
 class API_NEW : API_BASE {funct1(),func2(),func3()};

Approccio 2 : utilizza la logica condizionale semplice

if (newAvailable)
    useNew();
else 
    useOld();

Domande

Se le possibilità di supportare più flussi in futuro sono molto meno (diciamo il 15%); ma è necessario sostenerli per qualche tempo (diciamo alcuni mesi), modificheresti un codice scritto in modo procedurale per supportare gli OOP? Vedo il vantaggio di manutenibilità, leggibilità e codice facile da estendere. Ma qual è il modo intelligente?
Nella base di legacy legacy ... qual è il momento ideale per il codice refactoring? Tocca un file una volta all'anno e passa all'altro. Fornire che ho tempo ... dovrei refactoring un codice stabile / in esecuzione, o dovrei farlo quando c'è un reale bisogno di refactoring (come definire che non lo so)
Nelle grandi società di software ... la squadra lavora nei propri confini. Se la squadra A completa il suo lavoro, vuole anticipare la produzione e annunciare al mondo (mgmt, team b) ecc. Che abbiamo finito. Fino a quando non avremo tutto pronto (vale a dire la parte A e la parte B), per l'utente finale (QA / cliente) non ci sono modifiche alla funzionalità. È un buon modo di pensare? dovrei concentrarmi di più sulla mia parte e lasciare che mgmt si preoccupi di un'immagine più grande?

design project-management c++ object-oriented-design legacy

posta vikrant 13.03.2014 - 05:40

fonte

1 risposta

Leggi altre domande sui tag design project-management c++ object-oriented-design legacy

Come creare moduli configurabili? Barra di avanzamento per numero sconosciuto di elementi

score 5 · Answer 1

Opzione 1.

Il team B ha pubblicizzato l'API e la sua stima del programma. Li hai presi in parola, hai progettato le specifiche di progettazione dell'interfaccia. Il gioco è fatto, ora sei disponibile a lavorare su altre attività nel backlog. Non è colpa tua se la loro stima del programma non è stata perfetta.

Entrambi gli approcci all'Opzione 2 rendono il tuo codice più dettagliato e meno gestibile. Questa è l'ULTIMA cosa che vuoi fare.

Se hanno tirato le loro stime a causa della pressione politica (succede, troppo spesso), hanno bisogno di equipaggiare e prendere le loro medicine - e così fa il pagliaccio che ha applicato la pressione.

Per rispondere alle tue domande:

Fai bene la prima volta e poi LASCIA. Heinlein ha messo questo come "Scrivi, finisci ciò che scrivi, poi LASCIAVI SOLO E INVIATELO PER PUBBLICARE". Aveva ragione.
Refactor quando NON SEI nel mezzo di una spinta per finire qualcos'altro, come lo sei ora, quando l'intera base di codice NON è in flusso, come adesso. In altre parole, NON ORA.
L'attenzione deve essere rivolta al completamento delle parti e all'integrazione delle parti. Se la parte A è terminata, la squadra A può essere assegnata per aiutare la squadra C nella parte C. Una volta terminata la parte A, la squadra A non dovrebbe continuare a scimmiottarla solo perché la squadra B è in ritardo.

Probabilmente non sono le risposte che volevi sentire, ma sono le risposte che, si spera, massimizzano le probabilità di spedizione effettiva del prodotto funzionante.