Che cose da rifattorizzare prima [duplicato]

Question

Che cose da rifattorizzare prima [duplicato]

#1 da (1 voti)

-3

Capisco che questa sia una domanda selvaggia e totalmente aperta ma volevo solo sapere che sto abbaiando sull'albero giusto.

Ho ereditato una vasta base di codice di molte soluzioni e servizi, e mentre sto imparando a programmare in C #, ASP MVC e javascript hanno notato un carico di problemi con il codice esistente.

Sono stato incoraggiato a rifattorizzare il codice esistente mentre estendevo anche la base di codice che non ha quasi nessun test e qualche documentazione limitata. Ad esempio, una app ha schede ma ogni scheda è una vista parziale individuale che ha masse di javascript non formattati e decisioni prese all'interno della vista e utilizza una cache per memorizzare le sessioni tra le schede.

Mi chiedevo se avrei dovuto aggiungere test il più possibile, refactoring del javascript e trarne vantaggio nell'app esistente, riscrivendo l'app principale e arrivando a un punto in cui posso trasferire il javascript riscritto e le altre parti in una nuova scrittura migliore schede sito web utilizzando i miei test.

I programmatori precedenti vanno dal principiante al bene ma sono stati codificati sotto pressione, ma ora la società è molto più consapevole dei vantaggi di un buon codice e di un'ottima compagnia per cui lavorare e ne vale la pena.

Qualcuno ha un'esperienza simile?

projects-and-solutions mvc

posta Andrew Day 08.08.2018 - 22:30

fonte

1 risposta

Leggi altre domande sui tag projects-and-solutions mvc

UML Class Diagram HashMap Data Type Come gestire gli errori in un sistema distribuito

score 1 · Accepted Answer

Utilizza un sistema di controllo del codice sorgente e, se è già in uno, crea un nuovo ramo per il tuo lavoro di refactoring.
Avrai bisogno di qualche forma di test per sapere se hai rotto qualcosa. Come affrontarlo dipende dalla natura di ciò che fa il tuo software ereditato. Se è pratico trovare input di esempio e convalidare tali output, è possibile creare un sistema di test di regressione. Se è qualcosa come una GUI, questo è - sebbene ancora possibile - molto più difficile. Forse solo una procedura di test scritta da fare su ogni versione?
Se crei un sistema di test di regressione, anche il sistema CI può essere di aiuto
Esegui il codice tramite un formattatore automatico (come il formato clang). Se dozzine di programmatori diversi hanno attraversato il codice, probabilmente hai dozzine di variazioni stilistiche. Questo rende inutilmente difficile leggere. Standardizza e automatizza lo standard.
Se hai qualche tipo di test di regressione o test manuale, usa uno strumento di copertura del codice per avere un'idea approssimativa di quali parti del codice sono solo inutilizzate. Se si è evoluto nel tempo, e da programmatori immaturi, forse c'è un sacco di codice morto. Non ha molto senso nel rifattorizzare il codice che non funziona mai. SNIP SNIP!
A questo punto, hai fatto la parte facile, e hai bisogno di ottenere informazioni specifiche su cosa fa il codice, cosa fa male e cosa vuoi correggere. Ma a questo punto, hai una buona infrastruttura per fare le riparazioni.

Un problema con un sacco di codice, specialmente il codice errato, è che manca di modularità. IMPOSE MODULARITY .

Come imporre la modularità :

(qui stiamo ricevendo C # specifico)

Crea tutto ciò che puoi farcela con privato. Separa il pubblico dal privato. Mi piace rinominare i membri privati in modo che finiscano con un _, in modo che la lettura visivamente ovvia del codice sia un riferimento pubblico e privato.

Quando vai in giro a provare a fare il refactoring, una buona LUCE GUIDA, stai riducendo l'API pubblica. Cerca dove le cose sono fatte in modo ridondante o con molta verbosità e cerca come cambiare le API in modo che ci siano meno, e meglio, e più semplici API pubbliche.

E - di tanto in tanto rimandano allo strumento di copertura. Guarda quale codice viene effettivamente utilizzato. Se trovi che il tuo refactoring porta a più codici morti - bene! TAGLIA TAGLIA! E puoi concentrarti sul refactoring delle parti del sistema che sono più utili.

Questo dovrebbe essere un buon inizio (dato che non ho guardato il codice).