Nel contesto del refactoring, a volte ti imbatti nel termine "approccio dal basso verso l'alto", il che ha senso in un modo in cui si modificano le parti mobili più piccole prima durante il refactoring.
Tuttavia non ho mai sentito parlare di "refactoring dall'alto" e non riesco a trovare alcuna risorsa sull'argomento, quindi mi stavo chiedendo se effettivamente esiste o se è un ossimoro.
Esiste una definizione formale di refactoring bottom up vs. refactoring dall'alto ?
Penso che l'approccio dall'alto in basso sia più una riprogettazione di un semplice refactoring .
Dalla mia esperienza refactors sono in qualche modo una riorganizzazione del codice esistente. È un re-design su scala ridotta. Quindi ottieni caratteristiche complesse che soddisfano già le loro proposte ma non sono sufficientemente flessibili e difficilmente riutilizzabili. E hai diviso la sua funzionalità in sottoprocessi piccoli. Il modo migliore per farlo è quello che hai indicato, con l'accesso dal basso verso l'alto .
Tuttavia, se stai affrontando un profondo cambiamento di queste funzionalità e queste modifiche hanno un impatto importante su tutto il progetto o almeno su gran parte della sua attività. Nelle parole di ordine, se le modifiche sono abbastanza profonde da permetterti di riprogettare il modo in cui il tuo codice soddisfa i requisiti aziendali, il modo migliore è vedere l'avviso dall'alto. Passando dalla questione globale fino al modo specifico per risolverlo. Inizio pagina . Come bozze di ciò che dovrebbero essere. Non entrare nei dettagli. Una volta impostata la strategia e il nuovo design, puoi accedere nuovamente ai dettagli con la strategia bottom up fullfiling the core.
Guarda il peoblem dall'interno (b-u) o dall'esterno (t-d) o punti di vista alternativi fino a raggiungere la soluzione.
Uso l'empt dall'alto in basso per prototipi o mock-up. In questa fase ho impostato le high-line. Poi nella fase di sviluppo vado nei dettagli. È anche facile delegare compiti ai junior.
Top Down è quando si prende l'intero problema e lo si suddivide in problemi sempre più piccoli finché non si arriva a in basso dove si trovano molti dettagli di implementazione reali.
Bottom Up è quando crei molti piccoli blocchi dettagliati che sono generalmente utili e che possono essere assemblati insieme per risolvere problemi sempre più grandi.
Top-down è utile per analizzare e capire come un grosso problema può essere suddiviso in aree di responsabilità e produce la struttura complessiva di un software. Uno svantaggio è che tende a produrre codice specifico per attività in fondo che è generalmente difficile da riutilizzare in altre applicazioni.
Bottom Up, d'altra parte, è spesso l'approccio che i costruttori di biblioteche adottano. È interamente focalizzato sulla produzione di piccoli componenti che sono il più generici e riutilizzabili possibile all'interno delle loro specifiche aree di utilità.
Quando (ri) progettiamo un intero sistema, entrambi gli approcci sono importanti. Inizialmente l'approccio Top Down ti fornirà una struttura logica specifica per l'applicazione. Una volta che è stato raggiunto, l'approccio Bottom Up può essere applicato laddove vengono affrontate le specifiche di basso livello. Questo potrebbe significare localizzare librerie rilevanti che sono ben adattate per risolvere problemi di livello inferiore o imbarcarsi su una soluzione basata su librerie interne.
Il punto è che il codice di implementazione effettivo dovrebbe essere il più possibile riutilizzabile. In questo modo, la creazione di applicazioni successive dovrebbe diventare progressivamente più economica. A tal fine, l'approccio Top Down non può che portarti così lontano e, a quel punto, l'approccio Bottom Up colma le lacune con qualcosa di meno specifico per l'attività corrente ma più utile per le attività in generale.
Leggi altre domande sui tag refactoring terminology