Come posso refactoring un code base mentre altri si impegnano rapidamente ad esso?

18

Sono su un progetto privato che alla fine diventerà open source. Abbiamo alcuni membri del team, abbastanza talentuosi con le tecnologie per creare app, ma non sviluppatori dedicati in grado di scrivere codice pulito / bello e, soprattutto, a lungo termine.

Ho deciso di ridefinire la base di codice, ma è un po 'ingombrante dato che qualcuno nel team in un altro paese con cui non sono in contatto regolarmente potrebbe aggiornare questa cosa completamente separata.

So che una soluzione è comunicare rapidamente o adottare migliori pratiche di PM, ma non siamo ancora così grandi. Voglio solo ripulire il codice e inserirmi bene in ciò che ha aggiornato. Usare un ramo sarebbe un piano adatto? Una fusione ottimale? Qualcos'altro?

    
posta Incognito 20.03.2012 - 13:03
fonte

6 risposte

35

Una cosa che spesso le persone non considerano è che un'architettura pulita non solo acceleri la manutenzione a lungo termine, ma accelera anche lo sviluppo in questo momento . Non cercare di isolare i tuoi cambiamenti dai tuoi colleghi fino a quando non sono "fatti". I tuoi cambiamenti li aiuteranno ad essere più produttivi e meno inclini a bug.

L'errore più frequente che si commette quando si intraprende un grande refactoring è di non fondersi abbastanza spesso, cercando invece di farlo in un "big bang". Il modo giusto per farlo è di rendere il refattore il più piccolo possibile, testarlo, quindi unirlo alla branca del tuo collega e insegnargli il cambiamento in modo che possa incorporarlo in futuro. Idealmente stai facendo una fusione al giorno, o almeno una alla settimana.

    
risposta data 20.03.2012 - 16:20
fonte
8

Non sei mai "non abbastanza grande per comunicare". Se le dita possono fare la digitazione, anche le tue labbra possono parlare. Alla fine della giornata il miglioramento tecnologico è dell'85% di comunicazione e del 15% tecnico. Solo perché preferiresti stare lì a programmare piuttosto che avere conversazioni difficili con qualcuno ... non significa che sia una buona idea. La comunicazione è in realtà il pezzo duro di ciò che stai cercando, ma non solo evitarlo.

    
risposta data 20.03.2012 - 14:12
fonte
4

Sì, un ramo è una buona soluzione per questo.

Ti suggerisco di iniziare a lavorare su questo ramo e assicurati che nel frattempo si applichi in modo pulito sulla percentuale attuale di% co_de (es. effettua rebase e fusioni di test a intervalli regolari per assicurarti di poter applicare facilmente le modifiche e i tuoi test passano ancora - anche guarda in HEAD per aiuto da git rerere con questo) . Quindi, una volta che hai finito rebase e unisci le tue modifiche nel tuo git .

Quanto prima inizi a lavorare su questo, tanto più che il cambiamento dell'architettura diventa sempre più un lavoro, tanto più freddo diventa il codice. Inoltre, potrebbero esserci molte istanze di codice manoscritto disseminate nella base di codice dove ad es. la tua nuova e brillante funzione di supporto potrebbe aver reso le cose molto più semplici.

    
risposta data 20.03.2012 - 13:12
fonte
3

Hai preso in considerazione l'opzione "Non farlo ancora?"

Pur facendo questo lavoro in un ramo separato è probabilmente l'approccio migliore, ti stai preparando per una massiccia fusione dolorosa lungo la linea.

Gli altri ragazzi stanno presumibilmente aggiungendo molte nuove funzionalità, modificando le funzionalità esistenti e possibilmente rimuovendo alcune funzionalità.

Una volta che il dev mainstream ha funzionato un po 'più lentamente in futuro, allora potresti trovarti in una posizione molto più semplice per il refactoring.

    
risposta data 20.03.2012 - 15:11
fonte
2

tl; dr - Sembra che sia ora di fare un passo verso i campionati più importanti. Mettere il rossetto su un maiale non lo rende più carino, a meno che tu non sia interessato a quel genere di cose ...

Il problema delle persone

Il primo problema è la sincronizzazione del commit. Se hai più persone che lavorano sullo stesso codice allo stesso tempo, hai solo bisogno di una regola per evitare problemi:

Rule 1: Always pull before you merge/rebase

Quando si tratta di DVCS, è difficile apportare modifiche a un ramo remoto (ad esempio il repository principale) e molto semplice apportare modifiche al locale. Ogni persona è responsabile di inserire le proprie aggiunte di codice nell'insieme più grande senza problemi. A meno che 2 persone non si impegnino allo stesso tempo, non dovresti sperimentare. Impegnare l'accesso all'origine / master remoto dovrebbe essere limitato a pochi sviluppatori e dovrebbero estrarre le modifiche dagli altri sviluppatori tramite i rami di monitoraggio remoto.

Il problema del codice

Come fai a sapere che le modifiche apportate non interrompono il codice?

Risposta semplice ... Scrivi test per dimostrare che non lo fanno. Se ignori la scuola di pensiero TDD (Test Driven Design), l'intero punto di test è aggiungere un livello di verifica che ti permetta di cambiare codice senza romperlo.

Rule 2: Don't make assumptions, write proofs (ie tests).

Oltre a questo, è necessario eseguire l'intera gamma di test prima di passare al master di origine / remoto.

Tieni i tuoi impegni più piccoli e concisi possibili. In questo modo, se hai bisogno di eseguire il backup di una modifica che ha rotto qualcosa in seguito, risparmierai dal dover implementare nuovamente le parti che non hanno infranto il codice.

Potresti aver bisogno di alcune ristrutturazioni organizzative prima

Se le soluzioni di cui sopra non possono essere facilmente applicate, ci sono probabilmente alcuni problemi con la struttura di sviluppo che devono essere affrontati per primi.

Il proprietario del progetto dovrebbe essere il gatekeeper. Se ci sono problemi di sincronizzazione del commit, probabilmente ci sono troppe persone con accesso di commit. Anche su progetti di grandi dimensioni come il kernel di Linux, solo una manciata di sviluppatori ha effettuato l'accesso al repository master di origine / remoto. Esistono in realtà più livelli di repository per gestire i commit. Invece di un modello di commit a livello singolo in cui tutti stanno spingendo le loro modifiche all'origine, il modello gerarchico ha gatekeeper che estraggono le modifiche e ne verificano la qualità prima dell'inclusione nel progetto. Il modello di commit gerarchico può scalare molto più grande e più efficace del modello a singolo strato senza sacrificare la qualità.

Per gli sviluppatori che non ottengono l'accesso al commit, dovrebbero imparare a creare i propri rami di tracciamento remoto (git e gitorious vanno bene per questo) in modo che gli sviluppatori che fanno abbiano accesso di commit possono facilmente tirare / integrare rami nell'origine. Se le modifiche sono piccole, le patch funzioneranno altrettanto bene.

La possibilità di estrarre le modifiche prima di unire / rebase presuppone che non stai sviluppando sul tuo ramo principale locale. Il modo più semplice per gestirli è fare un pull iniziale prima di iniziare a programmare, quindi fare tutto il lavoro su quel ramo. Il modo più difficile è ramificarlo appena prima di unire e ripristinare il master.

Definisci lo stile di codifica per il progetto nel suo complesso e fai seguire gli sviluppatori. Gli sviluppatori contribuenti dovrebbero scrivere un codice conforme agli standard / norme del progetto per ridurre al minimo la pulizia. Lo stile di codifica può essere una grande barriera per l'ego in un progetto aperto. Se non è impostato uno standard, tutti codificheranno nel loro stile preferito e il codebase diventerà molto brutto molto velocemente.

Il mito di "The Mythical Man Month"

Che ci crediate o no, i progetti open source più grandi / di maggior successo non sono gestiti come una democrazia. Sono gestiti come una gerarchia. Dichiarare che un progetto non può crescere efficacemente oltre gli 8-10 sviluppatori è ingenuo. Se fosse vero allora i mega-progetti come il Kernel Linux non esisterebbero. Il problema più profondo è che dare accesso a tutti rende la comunicazione effetiva troppo difficile da gestire.

Il problema del mitico mese dell'uomo può essere superato. Hai solo bisogno di gestire il tuo progetto come l'esercito. Ci sono molti livelli all'interno della gerarchia perché è risaputo che le singole persone sono davvero efficaci solo nella gestione delle comunicazioni con una manciata di persone. Finché nessun singolo individuo è responsabile della gestione del lavoro di più di 5-7 persone, il sistema può scalare indefinitamente.

Potrebbe limitare gli sviluppatori migliori / esperti a fare più integrazione e progettazione / pianificazione di livello superiore, ma non è una cosa negativa. Parte del potenziamento sta facendo la mossa per decidere che il progetto ha bisogno di un piano a lungo termine. Le persone ai massimi livelli che hanno il maggiore investimento (il tempo è anche una risorsa) nei progetti futuri dovrebbero essere incaricati di prendere le decisioni più importanti.

È bello sapere di un progetto open source che sta attraversando dolori crescenti. Congratulazioni e buona fortuna.

    
risposta data 20.03.2012 - 23:00
fonte
-1

clean/beautiful and most importantly long-term maintainable code.

Nella mia esperienza pulita / bella è il nemico del mantenibile. Bellissimo codice spesso:

  • Ha un livello sul framework che introduce un livello più alto di astrazione
  • Ottimizza il riutilizzo del codice, generando molte dipendenze
  • Cerca di risolvere il problema generico anziché quello specifico

D'altra parte, codice mantenibile:

  • Viene scritto direttamente sul framework, quindi tutti gli sviluppatori possono leggerlo
  • Ottimizza per un basso numero di dipendenze, quindi una modifica in un'area non ha alcun impatto su un'altra
  • Non tenta di risolvere più problemi di quanti ne abbia di
risposta data 21.03.2012 - 00:01
fonte

Leggi altre domande sui tag