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

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.

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?

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.

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.