Continua a codificare il modo sbagliato per rimanere coerente? [duplicare]

4

Per semplificare le cose, diciamo che sono responsabile del mantenimento di due applicazioni, AwesomeApp e BadApp (sono responsabile di più e non di quello che non è il loro vero nome).

AwesomeApp è un progetto greenfield su cui ho lavorato con altri membri del mio team. È stato codificato utilizzando tutte le parole d'ordine di fantasia, Multistrato, SOA, SOLID, TDD e così via. Rappresenta la direzione in cui vogliamo andare in squadra.

BadApp è un'applicazione utilizzata da molto tempo. L'architettura soffre di molti peccati, ovvero tutto è strettamente accoppiato tra loro e non è raro ottenere un errore di dipendenza circolare dal compilatore, è quasi impossibile fare un test unitario, classi grandi, codice duplicato e così via. Abbiamo un piano per riscrivere l'applicazione seguendo gli standard stabiliti da AwesomeApp, ma ciò non accadrà per un po '.

Devo andare su BadApp e correggere un bug, ma dopo aver trascorso mesi a programmare ciò che considero corretto, davvero non voglio continuare a perpetuare pratiche di codifica sbagliata. Tuttavia, il modo in cui AwesomeApp è codificato è molto diverso dal modo in cui è codificato BadApp. Temo che l'implementazione del modo "corretto" possa causare confusione per altri sviluppatori che devono mantenere l'applicazione.

Domanda: è meglio mantenere la codifica nel modo sbagliato per rimanere coerenti con il resto del codice nell'applicazione (sapendo che verrà sostituito) o è meglio codificare nel modo giusto con una comprensione potrebbe causare confusione perché è molto diversa?

Per darti un esempio. Esiste una grande classe (1000+ linee) con diverse funzioni. Una delle funzioni è calcolare una data basata su un valore enumerato. Attualmente la funzione gestisce tutti i vari calcoli. La funzione non fa affidamento su altre funzionalità all'interno della classe. È autonomo. Voglio suddividere la funzione in funzioni più piccole (per lo meno) e inserirle nelle proprie classi e nascondere quelle classi dietro un'interfaccia (al massimo) e utilizzare il modello factory per creare un'istanza delle classi data. Se l'ho appena suddiviso in funzioni più piccole all'interno della classe, seguirebbe lo standard di codifica esistente. I passaggi extra devono iniziare a seguire alcuni dei principi SOLID.

    
posta bwalk2895 03.07.2012 - 20:02
fonte

5 risposte

4

La coerenza vale meno della qualità ogni volta. Se i tuoi altri sviluppatori su BadApp non sanno come programmare bene, addestrarli o licenziarli.

Oppure, se il tuo capo non considera queste due alternative, chiama il cacciatore di teste.

Modifica: ho avuto la mia impressione che stavi suggerendo che gli altri sviluppatori che lavorano su BadApp avrebbero avuto un problema con un buon codice. Se no, allora, beh, c'è davvero nessun motivo per non iniziare bene la codifica. La coerenza è preziosa solo se sei coerente con qualcosa che vale la pena essere.

    
risposta data 03.07.2012 - 20:09
fonte
4

Penso che il tuo pericolo nel "riparare" BadApp come mantieni è che farà perdere tempo e sforzi per spendere meglio su GoodApp finché non sarà il momento di BadApp V2.0.

Vorrei:

  1. Avere una riunione di gruppo e elencare le differenze tra i due. Questo aiuta tutti (compresi i "vecchi studenti" a comprare ciò che è buono.
  2. Riconoscere che lascerai parte delle vecchie cose (se funziona) così com'è e lascerai le briciole di pane per te stesso su ciò che deve essere corretto. Puoi usare il tuo sistema di biglietteria o anche commenti di tipo "TODO" esteso nel codice. Dopo il tempo questi si accumulano e la migrazione è meno problematica.
  3. Quando il rewirte di BadApp arriverà, la gestione impegna le risorse appropriate in base a ciò che hai identificato sopra ... LOL Voglio solo scrivere quello, non avrei potuto dirlo con una faccia seria: -)
risposta data 03.07.2012 - 20:26
fonte
1

Il codice di refactoring non sempre è sempre buono e produttivo. Ho avuto un collega che è un programmatore brillante ma non è mai riuscito a finire l'app su cui stava lavorando. Con ogni nuovo bug ha visto molti errori nel programma e ha provato a modificare alcune strutture per correggere il bug. Alla fine è stato licenziato.

Se ci sono cambiamenti che richiedono il 30-40 percento in più di tempo necessario per correggere il bug, allora direi che cambi il codice. Nel momento in cui voi e il vostro team trovate il tempo / la persona per rifattorizzare completamente il codice, sarà molto più facile perché molto è già stato fatto. Se stai aggiungendo una nuova porzione di codice a quell'app, la aggiungi correttamente. Non aver paura che qualcuno non lo capisca.

Ma se con ogni bug proverai a riscrivere un grande pezzo di codice, non otterrai nulla. È meglio fare piccoli cambiamenti e attendere il GRASSO refactoring, o non toccare il vecchio codice brutto ma funzionante.

    
risposta data 03.07.2012 - 20:32
fonte
1

Se fossi al tuo posto, suggerirei alla squadra di concentrarsi sul refactoring del codice, o almeno di avere qualcuno che ha assegnato il refactoring al codice. Dovrebbe essere abbastanza ovvio che a lungo andare pagherà.

Non vergognarti mai di correggere il codice rotto !

    
risposta data 03.07.2012 - 20:10
fonte
0

Ciò che può venire in mente è un'analisi dei costi su BadApp, per vedere se vale la pena entrare e aggiornare il codice a standard migliori, o se è semplice riscrivere l'applicazione è meglio. Oppure, ci possono essere soluzioni fuori dallo scaffale per fare parte delle funzioni di BadApp e riscrivere / aggiornare il resto.

Un approccio potrebbe essere quello di avere uno sviluppatore o due passare attraverso il codice in BadApp e delineare ciò che deve essere modificato / aggiornato (questo potrebbe essere parte o un risultato dell'analisi dei costi). Mantieni quella lista, e poi ogni volta che devi entrare in BadApp, prendi anche una delle funzioni di riscrittura e completi quella. Estende il periodo di tempo per l'aggiornamento di BadApp allo standard, ma alla fine sarà almeno MediocreApp.

    
risposta data 03.07.2012 - 20:17
fonte

Leggi altre domande sui tag