Jak nauczyć się właściwego podejścia do wdrożenia połowy funkcji? [Zamknięte]

Kieruję zespołem programistów i chcę wypuszczać nasz produkt tak często, jak to możliwe (Continuous Delivery).

W wielu przypadkach musimy wdrożyć funkcję, której wdrożenie zajmuje więcej czasu niż czas między wydaniami. Nadal chcę, aby ludzie codziennie zatwierdzali swój kod (ciągła integracja).

Wiele razy implementacja nowej funkcji wymaga zmiany istniejącej funkcji, a istniejące funkcje oczywiście nadal muszą działać, nawet jeśli nowa funkcja nie jest jeszcze ukończona.

Jeśli programista zastosuje właściwe podejście , może ostrożnie dostosować istniejące funkcje, a wszystkie powyższe nie stanowią problemu.

Jakie jednak właściwe jest właściwe podejście? Mój własny dostrojony umysł programistyczny mówi mi, co robić w każdym indywidualnym przypadku, ale muszę się więcej nauczyć i potrzebuję materiałów do czytania, które mogę przeczytać i polecić członkom zespołu do przeczytania. Lub zrobi to każda inna metoda uczenia się właściwego sposobu uczenia się tego podejścia.

Więc to jest pytanie. Jak upewnić się, że członkowie zespołu nauczą się właściwego podejścia do wdrożenia połowy funkcji?

Szukałem osób twierdzących, że mają strategie w tym zakresie, ale jeszcze ich nie znalazłem, z wyjątkiem osób piszących kilka przypadkowych przemyśleń na ten temat. Być może nie używam odpowiednich słów wyszukiwania lub być może nikt nie podał w tej sprawie żadnych miarodajnych wskazówek.

Mam już inne zdanie na temat innych odpowiedzi tutaj. Zgadzam się z tobą, że chcesz jak najszybciej zintegrować zmiany od programistów i nadal testować kombinację kodu.

Nie zgadzam się jednak z tym, że jego prawo do wysyłania kodu zostało opracowane dziś rano, tylko dlatego, że wypuszczamy je dziś po południu. To przepis na rozczarowanych klientów.

Rozwiązaniem jest posiadanie gałęzi w drzewie kontroli wersji oraz oddzielny proces promowania zweryfikowanych delt z gałęzi developerskiej do gałęzi wydania.

W ten sposób uzyskasz to, co najlepsze z obu światów. Deweloperzy wykonują ciągłą integrację, a korzyści, które z tego wynikają, zapewniają stabilną wysyłkę kodu do klienta regularnie, a także nowy proces testowania ukończonych funkcji w branży deweloperskiej, a jeśli przejdą testy, czynią je częścią wydanego produktu .

Są dwa znane mi narzędzia, które dobrze obsługują tego rodzaju procesy. Jeśli twoja struktura programistyczna jest prosta, to git z git-flow implementuje dobrą strukturę rozgałęziającą, która działa dobrze w małych i średnich zespołach (być może 20 programistów).

W przypadku większych zespołów programistycznych lub tam, gdzie potrzebna jest bardziej złożona strategia rozgałęziania w celu obsługi wielu „obrotów” Twojego produktu, dokładność jest najlepsza na rynku. Programiści niezaangażowani w zarządzanie zmianami będą narzekać, że jest to trudniejsze niż pod-wersja itp. ... ale obsługuje złożone środowiska programistyczne.

Występują tutaj dwa problemy: jeden wdraża połowę funkcji; drugim jest utrzymanie produktu wysyłkowego w ciągłym rozwoju.

Wdrażanie połowy funkcji

Pomoże w tym silny nadrzędny projekt. Pozwala to na implementację funkcji z jasno określonymi granicami - np. Interfejsy API do sąsiednich bitów kodu, oczekiwania dotyczące struktur danych oraz zrozumienie, w jaki sposób i kiedy zostanie wywołany zaimplementowany kod.

Testy mogą obejmować wymyślone wersje kodu dla innych części funkcji; Pomaga to wygładzić przejście, gdy idziesz do wdrożenia drugiej połowy.

Utrzymanie produktu wysyłkowego w działaniu

Istnieje tutaj kilka opcji:

1. Wyłącz funkcję w wysyłanym produkcie. To, że kod znajduje się w produkcie, nie oznacza, że ​​należy go wykonać lub przedstawić użytkownikom. Minusem jest to, że nie zapewnisz użytkownikom dodatkowej wartości i nie otrzymasz opinii.
2. Ujawnij użytkownikom krawędzie funkcji. Pokaż, co masz, i podaj wskazówki, co ma nadejść.
3. Pozwól użytkownikom przełączać się między nową i starą funkcjonalnością. Czasami wymaga to utrzymania dwóch ścieżek kodu, które są gotowe dla użytkownika końcowego.

Na koniec, jeśli masz problemy z którymkolwiek z tych rozwiązań, zastanów się, czy podzieliłeś funkcję wzdłuż właściwych granic. Gdyby pokroić rzeczy w inny sposób, czy łatwiej byłoby je rozdzielić?

Jak upewnić się, że członkowie zespołu nauczą się właściwego podejścia do wdrożenia połowy funkcji?

Ucząc ich. (duh)

Uczenie się będzie obejmować iterację: próbowanie czegoś, zobaczenie, jak to działa, a następnie modyfikowanie ich podejścia, aby osiągnąć lepsze wyniki. W przypadku tego rodzaju rzeczy zalecałbym recenzowanie projektu / kodu. Zobaczysz, w jaki sposób zaprojektowano / wdrożono półfunkcję i masz okazję wyrazić opinię. „To i to nie zadziała, bo zepsują nasz CI; co powiesz na XYZ?”, „Dobra robota tutaj, to naprawdę czyste”.

Robienie recenzji jako zespołu pomoże wszystkim dowiedzieć się, co już intuicyjnie wiesz.

Najważniejszą rzeczą, która pomoże ci tutaj, jest dobry podział problemów, aby w miarę możliwości jeden obszar kodu nie kolidował z innym.

Jest to miejsce, w którym bardzo pomocne jest zastosowanie wstrzykiwania zależności i programowania interfejsu, dzięki czemu można mieć bieżącą implementację ISupportingFeature na stronie, a następnie, gdy trzeba utworzyć INewFeature, która zależy od innej implementacji, można po prostu rozwinąć za pomocą nowe wdrożenie i utrzymywanie istniejącego w produkcji, dopóki nie zostanie dobrze przetestowane i gotowe do uruchomienia. Zakładając, że Twój DI pracuje nad jakimś systemem konfiguracyjnym, pozwoli ci to na równoległe używanie tego samego kodu w systemie i używanie stabilnego kodu przez cały czas.

W rzeczywistości takie podejście do konfiguracji jest opisane przez Martina Fowlera jako przełączanie funkcji.

Oczywiście, problem pojawia się tylko wtedy, gdy wdrażają wszystkie kodu wszystkim czasu. Jest to dokładnie taki scenariusz, dla którego zaprojektowano gałęzie funkcji i chociaż przyznam, że pan Fowler marszczy brwi, nie wiem, czy są one takie złe, szczególnie jeśli są tworzone i wykorzystywane w sposób zaplanowany i przemyślany. po drodze.