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

Dirigo un team di sviluppo e desidero rilasciare il nostro prodotto il più spesso possibile (consegna continua).

In molti casi, dobbiamo implementare una funzionalità che impiega più tempo a implementare rispetto al tempo tra le versioni. Voglio ancora che le persone impegnino il loro codice su base giornaliera (integrazione continua).

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

Se lo sviluppatore utilizza l' approccio giusto , può regolare attentamente le funzionalità esistenti e tutto quanto sopra non è un problema.

Tuttavia, qual è attualmente l'approccio giusto? La mia mente sintonizzata dalla programmazione mi dice cosa fare per ogni singolo caso, ma ho bisogno di saperne di più e ho bisogno di materiale di lettura che posso leggere e riferire ai membri del team da leggere. O qualsiasi altro metodo per imparare il modo giusto per imparare questo approccio farà.

Quindi questa è la domanda. Come posso assicurarmi che i membri del team imparino l'approccio giusto per implementare mezza funzionalità?

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

Prendo una visione diversa dalle altre risposte qui già. Concordo con te sul fatto che desideri integrare le modifiche degli sviluppatori il più presto possibile e continuare a testare il mix combinato di codice.

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

La soluzione è disporre di rami nell'albero di controllo della versione e disporre di 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. Hai sviluppatori che fanno l'integrazione continua e i vantaggi che ne derivano, disponi regolarmente di codice che spedisce regolarmente al cliente e hai un nuovo processo che verifica le funzionalità completate nel ramo degli sviluppatori e se superano i test li rendono parte del prodotto rilasciato .

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

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

Ci sono due problemi qui: uno sta implementando mezza funzionalità; l'altro sta mantenendo il prodotto di spedizione funzionante durante lo sviluppo continuo.

Implementazione di mezza funzionalità

Un forte 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 di dati e comprensione di come e quando verrà chiamato il codice implementato.

I test possono includere versioni simulate del codice per le altre parti della funzione; questo aiuta ad attenuare la transizione quando vai a implementare la seconda metà.

Mantenere il prodotto di spedizione funzionante

Ci sono alcune opzioni qui:

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 valore incrementale ai tuoi utenti e non riceverai feedback.
2. Rivela i bordi della funzione ai tuoi utenti. Mostra quello che hai e fornisci alcune indicazioni su ciò che verrà.
3. Consenti agli utenti di passare tra funzionalità nuove e vecchie. Questo a volte richiede di mantenere due percorsi di codice pronti per l'utente finale.

Infine, se riscontri problemi con una di queste soluzioni, considera se hai suddiviso la funzionalità lungo i limiti giusti. Se tagliassi le cose in un modo diverso, sarebbe più facile smontare?

Come posso assicurarmi che i membri del team imparino l'approccio giusto per implementare mezza funzionalità?

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, raccomanderei recensioni di design / codice. Puoi vedere come la mezza funzionalità è progettata / implementata e avere l'opportunità di dare un feedback. "Questo e quello non funzioneranno perché romperanno il nostro CI; che ne dici di XYZ?", "Ottimo lavoro qui, è davvero pulito."

Fare le recensioni in gruppo aiuterà tutti a imparare ciò che già sai intuitivamente.

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 luogo in cui l'utilizzo dell'iniezione delle dipendenze e la programmazione per l'interfaccia aiutano davvero, in modo da poter avere la tua attuale implementazione di ISupportingFeature sul sito e quindi quando devi creare INewFeature che dipende da un'implementazione diversa, puoi semplicemente sviluppare con nuova implementazione e mantenere quella esistente in produzione fino a quando non sarà ben collaudata e pronta per essere pubblicata. Supponendo che il tuo DI stia funzionando su un sistema di configurazione di qualche tipo, questo ti permetterà di avere lo stesso codice in parallelo nel tuo sistema e di utilizzare codice stabile in ogni momento.

In effetti, questo approccio alla configurazione è descritto da Martin Fowler come Feature Toggle.

Naturalmente, il problema si pone solo se si distribuisce tutto il codice tutto il tempo. Questo è esattamente il tipo di scenario per cui sono stati progettati i rami delle caratteristiche e anche se riconosco che il signor Fowler si acciglia su di loro, non so che sono così cattivi, specialmente se sono creati e utilizzati in un modo pianificato e pensato- attraverso il modo.