Come apprendo l'approccio giusto per implementare una mezza funzionalità? [chiuso]

12

Sono a capo di un team di sviluppo e desidero pubblicare il nostro prodotto il più spesso possibile (fornitura continua).

In molti casi, dobbiamo implementare una funzione che richiede più tempo per essere implementata rispetto al tempo che intercorre tra le versioni. Voglio ancora che le persone eseguano il loro codice su base giornaliera (integrazione continua).

Molte volte l'implementazione di una nuova funzione richiede la modifica delle funzionalità esistenti e, naturalmente, le funzionalità esistenti devono ancora funzionare, anche se la nuova funzione non è ancora terminata.

Se lo sviluppatore utilizza l'approccio giusto , può modificare attentamente le funzioni esistenti e tutto ciò non costituisce un problema.

Tuttavia, qual è l'approccio giusto in realtà? La mia mente in sintonia con la programmazione mi dice cosa fare per ogni singolo caso, ma ho bisogno di saperne di più e ho bisogno di materiale di lettura che possa leggere e riferire ai membri del team. O qualsiasi altro metodo di apprendimento del modo giusto per imparare questo approccio farà.

Questa è la domanda. Come faccio a garantire che i membri del team apprendano l'approccio giusto per implementare una mezza funzionalità?

Ho cercato persone che affermano di avere strategie in merito, ma non l'hanno ancora trovato, tranne che le persone scrivono alcuni pensieri casuali sull'argomento. Forse non sto usando le parole di ricerca giuste o forse nessuno ha formulato alcuna guida autorevole su questo.

    
posta Niels Brinch 10.09.2013 - 10:00
fonte

4 risposte

14

Prendo una visione diversa dalle altre risposte già qui. Sono d'accordo con te che desideri integrare le modifiche degli sviluppatori il prima possibile e continuare a testare il mix combinato di codice.

Tuttavia, non sono d'accordo sul fatto che il suo diritto di imbarcare codice sia stato sviluppato stamattina, solo perché stiamo uscendo questo pomeriggio. Questa è una ricetta per i clienti delusi.

La soluzione è di avere rami nella struttura di controllo della versione e di avere un processo separato per promuovere i delta verificati dal ramo di sviluppo al ramo di rilascio.

In questo modo ottieni il meglio da entrambi i mondi. Avete sviluppatori che fanno un'integrazione continua, e i vantaggi che ne derivano, avete regolarmente la spedizione di codice stabile al cliente, e avete un nuovo processo che verifica le funzionalità completate nel ramo di sviluppo, e se superano il test le rendono parte del prodotto rilasciato .

Ci sono due strumenti che sono familiari che supportano bene questo tipo di processi. Se la tua struttura di sviluppo è semplice, git, con git-flow implementa una buona struttura di ramificazione che funziona bene in team di piccole e medie dimensioni (forse 20 sviluppatori).

Per i team di sviluppo più grandi o dove è necessaria una strategia di ramificazione più complessa per supportare più "spin" del tuo prodotto, accurrev è il migliore che ci sia. Gli sviluppatori non coinvolti nella gestione delle modifiche si lamenteranno che è più difficile della versione secondaria ecc ... ma supporta ambienti di sviluppo complessi.

    
risposta data 10.09.2013 - 16:48
fonte
6

Qui ci sono due problemi: uno sta implementando una mezza funzione; l'altro è mantenere il prodotto di spedizione funzionante durante lo sviluppo continuo.

Implementazione di mezza funzionalità

Un solido design globale aiuterà in questo. Ciò consente di implementare la funzione con i suoi confini chiaramente definiti, ad esempio API per bit di codice adiacenti, aspettative sulle strutture dati e una comprensione di come e quando verrà chiamato il codice implementato.

I test possono includere versioni del codice simulate per le altre parti della funzione; questo aiuta a rendere più fluida la transizione quando implementi la seconda metà.

Mantenimento del funzionamento del prodotto di spedizione

Qui ci sono alcune opzioni:

  1. Disattiva la funzione nel prodotto spedito. Solo perché il codice è nel prodotto non significa che debba essere eseguito o presentato agli utenti. Lo svantaggio è che non fornirai un valore incrementale ai tuoi utenti e non riceverai feedback.
  2. Rivela i bordi della funzione ai tuoi utenti. Mostra ciò che hai e fornisci indicazioni su cosa succederà.
  3. Consenti agli utenti di passare tra funzionalità nuove e vecchie. Ciò a volte richiede la manutenzione di due percorsi di codice che sono pronti per l'utente finale.

Infine, se hai problemi con una di queste soluzioni, valuta se hai diviso la funzione lungo i confini corretti. Se hai tagliato le cose in un modo diverso, sarebbe più facile separarle?

    
risposta data 10.09.2013 - 15:06
fonte
1

How do I make sure team members learn the right approach to implement half a feature?

Insegnando loro. (Duh)

L'apprendimento coinvolgerà l'iterazione: provare qualcosa, vedere come funziona e quindi modificare il loro approccio per ottenere risultati migliori. Per questo genere di cose, vorrei sostenere le revisioni di design / codice. Si arriva a vedere come viene progettata / implementata la mezza caratteristica e si ha l'opportunità di dare un feedback. "Questo e quello non funzioneranno perché romperanno il nostro CI, che dire di XYZ?", "Ottimo lavoro qui, è davvero pulito."

Fare le recensioni come una squadra aiuterà tutti a imparare ciò che già intuitivamente sai.

    
risposta data 10.09.2013 - 15:33
fonte
1

La cosa più importante che ti aiuterà qui è avere una buona separazione delle preoccupazioni in modo che, per quanto possibile, un'area di codice non interferisca con un'altra.

Questo è un posto in cui l'uso di Dependency Injection e la programmazione dell'interfaccia sono di grande aiuto, così puoi avere la tua attuale implementazione di ISupportingFeature sul sito e poi quando devi creare INewFeature che dipende da una diversa implementazione, puoi solo sviluppare con la nuova implementazione e mantenere quello esistente in produzione fino a quando non è ben collaudato e pronto per l'uso. Supponendo che il tuo DI funzioni da un sistema di configurazione di qualche tipo, questo ti permetterà di avere lo stesso codice in parallelo nel tuo sistema e di usare sempre codice stabile.

In realtà questo approccio di configurazione è descritto da Martin Fowler come Attiva / disattiva funzionalità

Naturalmente, il problema sorge solo se si sta implementando tutto del codice tutto del tempo. Questo è esattamente il tipo di scenario per il quale sono state progettate le feature branch e sebbene riconosca che Mr. Fowler li disapprova, non so se sono così male, specialmente se sono create e utilizzate in un modo programmato e pensato attraverso modo.

    
risposta data 10.09.2013 - 10:55
fonte