Proste sposoby na poprawę jakości wydania w środowisku RAD

Trochę tła - jesteśmy małym zespołem (z 5) programistów RAD odpowiedzialnych za wewnętrzne tworzenie oprogramowania w dużej firmie niezwiązanej z oprogramowaniem. „Oprogramowanie wewnętrzne” różni się od aplikacji komputerowej .NET używającej serwera MSSQL jako zaplecza skryptów Python działających w tle do dokumentów i szablonów MS Word - zoo technologii.

Cały zespół składa się z wszechstronnych osób, które są w stanie uzyskać wymagania od użytkowników, kodować je, testować i wdrażać w środowisku produkcyjnym. Gdy oprogramowanie jest w produkcji, opiekuje się nim inny zespół, ale zazwyczaj łatwo jest nam interweniować, jeśli coś pójdzie nie tak.

Jak dotąd wszystko brzmi dobrze, ale jest problem - będąc zespołem RAD musimy często wydawać i nie ma dnia bez wydania nowych wersji jednej lub dwóch aplikacji (lub może to być skrypt, zaktualizowany dokument tekstowy , Aplikacja konsolowa C ++ itp.) Do produkcji. Przeprowadzamy testy programistyczne, a także angażujemy użytkowników końcowych, pozwalając im uruchamiać oprogramowanie w środowisku UAT ...

... ale błędy i tak wkradają się do produkcji. Użytkownicy rozumieją, że te błędy i okazjonalna niestabilność to cena, którą płacą za szybkie uzyskanie tego, czego chcą, ale jednocześnie skłoniło nas to do myślenia - być może moglibyśmy ulepszyć nasz rozwój lub praktyki wydawnicze w celu poprawy stabilności oprogramowanie i zmniejsz liczbę błędów, które wprowadzamy, dodając nową funkcjonalność.

Dobrze, że tak naprawdę nie mamy zbyt wiele procesów, więc powinno być łatwo zacząć się poprawiać, co złe - będąc małym zespołem RAD, tak naprawdę nie mamy zbyt wiele czasu i zasobów do wdrożenia coś dużego, ale zastanawialiśmy się nad następującymi inicjatywami i chętnie przyjmiemy wszelkie opinie, porady, wskazówki i sugestie.

1. Obecnie niektóre aplikacje są wypuszczane na produkcję bezpośrednio po testach programistycznych, omijając testy akceptacyjne użytkowników. Praktykę tę należy przerwać, a nawet niewielka zmiana musi zostać przetestowana przez użytkownika końcowego. Każda aplikacja będzie miała dedykowany beta-tester wybrany spośród użytkowników końcowych. Dopiero po przetestowaniu wersji beta nowa wersja jest promowana ze środowiska testowego do produkcyjnego.

2. Nie przeprowadzamy recenzji kodu - ale zaczniemy robić recenzje kodu, zanim jedno z nas sprawdzi zestaw zmian. Myślałem również o „recenzji wdrożenia” - w zasadzie jeden z programistów musi usiąść obok drugiego, obserwując, jak wykonuje / wdraża oprogramowanie (kopiowanie plików binarnych, aktualizowanie konfiguracji, dodawanie nowej tabeli do bazy danych itp.) - zwykle tylko zajmuje 5–10 minut, więc nie zajmie dużo czasu „przeglądu wdrożenia”.

3. Jak zminimalizować czas wycofywania, gdy udowodniono, że nowe wydanie jest na tyle błędne, że można je wycofać z produkcji i zastąpić dobrą poprzednią wersją. Przechowujemy historię wszystkich wydań (jako pliki binarne), aby ułatwić powrót o jedną wersję wstecz - i chociaż jest to szybkie „nadpisywanie nowo wydanych plików binarnych poprzednimi wersjami”, nadal jest to proces ręczny, który jest podatny na błędy i czasami wymaga „co, jeśli wycofanie zakończy się niepowodzeniem i sprawi, że system nie będzie nadawał się do użytku zamiast buggy”.

Właśnie w tym momencie skończyły się nasze pomysły i chcielibyśmy poznać Twoją opinię na ich temat. Jeśli podzielisz się kilkoma prostymi poradami dotyczącymi ulepszenia wersji / procesu tworzenia - to byłoby niesamowite.

+1 za dotknięcie świetnego tematu. Kiedy opracowujemy linię rozwojową „Często zwalniaj wczesne wydawanie”, rzeczy nabierają prawdziwego tempa, a wraz z rozwojem pędu powstaje wiele takich problemów (jak to opisałeś), z którymi w przeciwnym razie nie jesteśmy zbyt przygotowani, aby sobie z nimi poradzić. Najgorszy strach pojawia się, gdy ludzie postrzegają prędkość jako wroga dobrej pracy.

Widziałem bardzo ograniczoną literaturę na ten temat, jednak to, co praktykujemy, zdecydowanie pomaga:

1. Skuteczne śledzenie
błędów Usprawnij śledzenie błędów - nie tylko utrzymujemy listę błędów i znaczników, ale po zamknięciu musimy zdefiniować pewne rzeczy, takie jak „czy problemy były powtarzalne?”, Czy jest to trwałe rozwiązanie lub work fix? ”,„ jaka jest podstawowa przyczyna ”problemów? Pozwala to wiedzieć, co się stało, kiedy ten błąd był widoczny po raz ostatni. Jest to kluczem do tego, aby błędy nie powtarzały się często.

2. Zdefiniuj kluczowe punkty
awaryjne Wszyscy wiemy, że pojawią się błędy, więc będziemy musieli zapewnić skuteczny powrót, który działa najczęściej. Wielokrotnie finalizujemy (w naszym przypadku około 1 na 10) najczęstsze wydanie, które działa wszędzie w najbardziej niezawodny sposób. Całkowita liczba wydań może być wiele, ale jeśli coś pójdzie nie tak, wycofania są wybrane i nie musisz się cofać. Jednym z najprostszych sposobów, aby poznać najlepszą rezerwę, jest sprawdzenie, które najwcześniejsze wydanie było najdłużej produkowane bez większych problemów.

3. Wyróżnij ryzykowne i stabilne lub małe poprawki błędów
Kiedy wiemy, że mamy poważne zmiany w algorytmie, bardziej prawdopodobne jest, że błędy pojawią się w scenariuszach, które nie są wszystkie przewidziane. Gdzie są czasy, kiedy problemy są bardzo małe (lub dobrze zrozumiane), a także niewielkie ryzyko. Czy nie klubowi taką funkcjonalność i proste błędy w tych samych wersjach. Zawsze najpierw należy naprawić mniejszy błąd, który musi iść tam, gdzie jest to wymagane. Twórz dedykowane wydania specjalnych zestawów funkcji, w najlepszym wypadku możesz wycofać tę funkcję, ale wszystkie inne ważne błędy są nadal dostępne w poprzedniej wersji.

4. Rozgałęzienie dla znaczącego rozwoju funkcji
Wszystko, co wiąże zmiany, które ma wpływ na projekt, musi być wykonane osobno dla oddziału. Większy rozwój nie kończy się szybko w porównaniu do mniejszych błędów. Jeśli wprowadzimy zatwierdzenia pośrednie, w których „częściowa” praca związana z funkcją, która nadal nie jest używana - jest potencjalnym regionem wprowadzania błędów; błędy, które nie powstałyby, gdyby pełna praca dla funkcji zakończyła się atomowo - stąd są to błędy, których nie musielibyśmy rozwiązać, gdyby istniały gałęzie.

5. Zawsze planuj wydanie oparte na tematyce
Wiele razy pojawia się wiele różnych błędów w różnych wydaniach - ale najlepiej jest organizować błędy (i funkcje), które wpływają na podobne moduły, ułatwiają powtarzanie pracy i minimalizują liczbę błędów pochodzących z tej pracy. Zawsze przygotowuj mapę drogową wydania z dużym wyprzedzeniem; błędy wciąż się pojawiają - i to w różnych wydaniach docelowych, aby optymalnie mieć dobrą grupę błędów, które można razem zlikwidować w dobrym wydaniu. Połączenie podobnych błędów zawsze daje lepszy wgląd w sprzeczne scenariusze.

6. Rozszerz każdą nową wersję najpierw na kilku klientów.
W naszym przypadku widzimy przetestowanie jej najpierw w kilku witrynach, a wszystkie inne witryny są stosowane w wersji tylko wtedy, gdy jest na nią zapotrzebowanie. Wiele razy niektórzy (lub większość) użytkowników przeskakiwali tylko ze stabilnego wydania do innego tylko stabilnego wydania.

7. Testowanie regresji
Wzdłuż linii zbieranych błędów - zbuduj kombinezon regresji. Również, jeśli to możliwe, zaznacz krytyczne błędy i przetestuj je jako najważniejsze, które stają się minimalnymi kryteriami kwalifikacyjnymi do przetestowania, zanim kandydat do wydania rzeczywiście stanie się wydaniem.

8. Zatrzymaj się i zastanów się
Kiedy wiele rzeczy dzieje się na pełnych obrotach, powinien być czas na przerwy - wstrzymaj się i wypuść wersje, które nie są funkcjonalnie lepsze. W rzeczywistości mają od jakiegoś czasu wakacje wydawnictw. (czas trwania jest odwrotnie proporcjonalny do częstotliwości). Na przykład wiele razy mamy tak zwane wersje „oczyszczania”, które nie osiągają niczego nowego z punktu widzenia funkcjonalności - ale to pomaga w utrzymaniu kodu w utrzymaniu. Większość takich wydań to świetne punkty zwrotne, które prawie nigdy nie przypominają sobie wcześniejszej historii.

9. Być może najbardziej dziwne
jest to, że często jest trudne do wdrożenia, ale z pewnością jest dobrą sztuczką. Zamień właściciela niektórych modułów. Kiedy ludzie proszeni są o recenzje kodu, nie ma wiele z tej praktyki. Ale kiedy musisz poważnie uporać się z tym nowym kodem, kiedy wymieniasz autorów, potencjalne „złe” dolegliwości szybko zostają zauważone, zanim zaczną zanieczyszczać kod. Oczywiście zmniejsza to szybkość - ale jeśli robisz to często, istnieje szansa, że ​​ludzie opanują różne części kodu i dowiedzą się o całym produkcie, który z drugiej strony jest bardzo trudny do nauczenia.

10. Na koniec
naucz się często wracać do tablicy. Im więcej myślisz, jakby ta funkcja była częścią naszego najbardziej początkowego projektu, jak pomyśleliśmy o tym projekcie w tym czasie? Czasami największym wyzwaniem związanym z pracą przyrostową jest to, że jesteśmy zbyt ograniczeni przez porządek funkcjonalności, który zbudowaliśmy jako pierwszy i często nie możemy wrócić do podstaw. Sztuczka polega na tym, aby wciąż zastanawiać się, w jaki sposób uogólnilibyśmy, zamiast uwzględniać tę nową funkcję lub scenariusz. Wymaga to, że projekt pozostaje aktualny, a dzieje się tak tylko wtedy, gdy często wracamy do deski kreślarskiej. Ponadto, gdy programiści nowej generacji dołączają, stają się częścią czołgu myślącego, a nie tylko nakładają łatki.

EDYCJA
11. Śledź obejścia i luki projektowe.
Dość często jesteśmy pod presją linii czasu, aby naprawić błąd i wydać go w produkcji. Jednak gdy błąd jest na poziomie projektu, kilka rzeczy musi się zmienić, ale często ludzie naprawią niektóre skróty, aby dotrzymać terminu. Jest OK . Jednak wraz ze wzrostem liczby takich obejść rozwiązań kod staje się kruchy. Zwracaj szczególną uwagę na to, ile luk projektowych już minęło. Zazwyczaj, negocjując harmonogram z kierownikiem projektu, najlepiej zmusić go / ją do zapewnienia, że ​​dostarczymy to w skrócie, aby zaoszczędzić produkcję, ale będziemy też mieli Oś czasu i zasoby, aby uzyskać trwałe rozwiązanie.

Pracuję również w małym zespole programistów (tylko 2 z nas) i mieliśmy podobne problemy, o których wspominałeś. Głównym problemem dla nas jest to, że oboje mamy tendencję do pracy nad oddzielnymi zadaniami i staje się zbyt powszechne, aby ukończyć zadanie / funkcję, przetestować je (przetestowane tylko przez programistę) i szybko wydać. Spowodowało to wiele małych wydań, w których użytkownicy zgłaszali małe błędy, które powinny zostać łatwo wykryte w testach.

W celu usprawnienia naszego procesu zacząłem od wprowadzenia tablicy Kanban . Na początku tablica była bardzo prosta i miała tylko kilka kolumn (konfiguracja za pomocą tablicy, kart indeksowych i kolorowych magnesów):

Zaległości | Do zrobienia | Gotowy

Jednak szybko ewoluowało, aby odzwierciedlić nasz rzeczywisty proces:

Zaległości | Rozwój | Dev. Test | UAT | Gotowe | Wydany

Wraz z tablicą mamy zasadę, że każde Zadanie / Funkcja musi zostać przetestowane przez innego programistę (a także przez programistę, który wdrożył tę funkcję). Zanim karta osiągnie kolumnę „Gotowe”, powinna była zostać przetestowana przez co najmniej 2 programistów, a także przetestowana pod kątem akceptacji użytkownika.

Istnieje wiele innych korzyści z korzystania z Kanban. Dla nas poprawiła komunikację i pomogła nam dzielić się wiedzą, ponieważ oboje jesteśmy w pewnym stopniu zaangażowani w każde zadanie. Usprawniono również proces wydawania, ponieważ możemy teraz dokładnie zobaczyć, jakie zadania / funkcje są gotowe do wydania / wykonania, a czasami mogą wstrzymać się z wydaniem, jeśli wiemy, że inne taksówki zostaną wkrótce wykonane. W przypadku osób spoza zespołu zarząd działa również jako szybki przewodnik, aby zobaczyć, jakie zadania zaplanowaliśmy, bieżące prace w toku i co ostatnio zostało wydane.

Nawiasem mówiąc, używamy kolorowych magnesów (po jednym na programistę) do oznaczenia karty, nad którą aktualnie pracujemy, ale inną opcją jest dodanie ścieżek pływania (rzędów), jednego na programistę i umieszczenie kart Kanban na odpowiednich torach pływania. Ponownie pomaga to w szybkim zapoznaniu się z tym, nad czym obecnie pracuje każdy programista.

Inne linki, które uznałem za przydatne:

Kanban dotyczy rozwoju oprogramowania: od zwinnego do szczupłego

System Kanban dla inżynierii oprogramowania - wideo

Mam nadzieję, że Kanban zajmie się punktem 1. w twoim pytaniu. W odniesieniu do recenzji kodu robimy to na etapie testowania programistów, aby wszelkie zmiany wymagane po sprawdzeniu były testowane programistycznie przed przejściem do UAT. Wycofywanie zmian zależy od środowiska, ale wdrażamy pliki aplikacji na serwerach terminali przy użyciu plików wsadowych, które zmieniają nazwy bieżących plików i kopiują nowe pliki z serwera centralnego, i możemy dość łatwo wycofać, umieszczając kopię zapasową (poprzednie pliki) w centralnej lokalizacji i ponowne uruchamianie skryptów.

Zidentyfikowałeś już, że wiesz, że istnieją problemy z procesami, które wpływają na jakość twojego oprogramowania i chociaż to pytanie wywoła szereg odpowiedzi, proponuję przyjrzeć się zagadnieniu inżynierii oprogramowania i spróbować dowiedzieć się, co to jest głównie programiści robią coraz więcej w tym obszarze. Sugeruję, abyś zaczął czytać kilka dobrych zasobów, aby się wyrzucić. Kilka, które przychodzą na myśl:

• Lean Software Development autorstwa Mary i Toma Poppendeicka stanowi świetną lekturę dla osób zainteresowanych nauczeniem się, jak identyfikować „odpady” i co zrobić, aby zmienić procesy, aby stały się szczuplejsze i wydajniejsze.
• Head First Software Development autorstwa Dana Pilone i Russa Milesa na pierwszy rzut oka przypomina trochę książkę „dla manekinów”, ale patrząc nieco poza chaotyczny styl prezentacji, zawiera większość informacji związanych z podstawami inżynierii oprogramowania i krótko napisał o rozwoju opartym na testach.
• Wprowadzenie do BDD to strona Dana Northa poświęcona rozwojowi opartemu na zachowaniach, a może wolisz Wiki BDD . Są to referencje dla początkujących dla BDD i prawdopodobnie będziesz chciał zajrzeć do narzędzi i struktur, które ci pomogą. Ważne jest, aby zrozumieć, że BDD jest skutecznie TDD przeniesiony na wyższy poziom koncepcyjny. Pozwala myśleć o testowaniu, gdy myślisz o specyfikacjach, i testować w tym samym języku, w którym piszesz specyfikacje. Frameworki ogólnie integrują się z innymi frameworkami do testowania jednostkowego, więc uzyskujesz to, co najlepsze z obu światów, jeśli zdecydujesz, że testowanie niekoniecznie skorzysta ze składni BDD.
• Artykuł Agile Software Development w Wikipedii jest dobrym podkładem na temat zwinnego tworzenia oprogramowania i zawiera wiele przydatnych odniesień i linków do artykułów niektórych bardziej szanowanych osób w społeczności programistów.

Aby poprawić JAK pracujesz, musisz pozwolić sobie być całkowicie otwartym i gotowym wyjść poza strefę komfortu, aby nauczyć się ulepszać rzeczy, które robisz bez trzymania się pewnych pojęć, które możesz znaleźć. bardziej wygodne do trzymania się. Mówiąc z własnego doświadczenia, jest to prawdopodobnie najtrudniejsza rzecz lub zachęcić innych.

Zmiana jest trudna w najlepszych momentach, nawet jeśli czujesz, że aktywnie szukasz zmiany, więc najlepszą radą, którą naprawdę mogę ci dać, jest przyjrzenie się różnym metodologiom Agile, które zostały opracowane przez lata w celu zapoznania się z praktykami które są uważane za najważniejsze (np. testy jednostkowe, ciągła integracja, refaktoryzacja itp.), a następnie wybierz metodologię, która wydaje się najbliższa temu, z czym ty i twój zespół czujecie się najlepiej. Po podjęciu decyzji, dostosuj praktyki i proces rozwoju, aby pasowały do ​​tego, w jaki sposób Twój zespół wolałby pracować, pamiętając o szczupłych zleceniodawcach i sposobie, w jaki chcesz pracować, aby Twój zespół mógł osiągnąć największą wartość dzięki najmniej odpadów. Wreszcie,

Jeśli uważasz, że Twoje procesy wymagają jedynie ulepszenia, ale obawiasz się, że Twój łańcuch narzędzi nie do końca nadąża za Twoimi potrzebami, może poszukaj tam ulepszeń. Jako minimum powinno być priorytetem produkt do ciągłej integracji (taki jak Continuum, Cruise Control lub Hudson) oraz system śledzenia problemów (taki jak Jira lub Redmine), aby pomóc Ci w automatyzacji niektórych procesów kompilacji i wydania, a także w celu kontroli błędów i próśb o funkcje.

Rzeczywistość jest taka, że ​​bez względu na to, jak RAD przebiegają twoje procesy, jeśli nie zainwestujesz czasu, aby wszystko było „odpowiednie” dla twojego zespołu, twoje problemy będą rosły z czasem, a twoje postrzeganie dostępnego czasu będzie odpowiednio się zmniejszają. Duże zmiany zwykle nie wchodzą w rachubę, gdy znajdują się pod presją czasu, ale postaraj się dać sobie trochę „spokojnego pokoju”, aby wprowadzić systemy, które pomogą ci podjąć kroki w kierunku idealnej metodologii zespołu.

Ilekroć słyszę o wadach, moje pierwsze pytania dotyczą tego, skąd pochodzą usterki oraz gdzie są one wykrywane i usuwane. Skuteczność usuwania defektów to dobry sposób pomiaru i śledzenia tego. Wiedząc, gdzie powstają wady i pracując nad usprawnieniem procesów na tych etapach, możesz skrócić czas i koszty projektu. Powszechnie wiadomo, że naprawianie defektów bliżej miejsca ich wstrzyknięcia jest tańsze, więc gdy już wiesz, skąd pochodzą defekty, możesz spojrzeć na zmiany czynności w celu poprawy tych faz.

Po uzyskaniu informacji o pochodzeniu wad możesz dokładnie przyjrzeć się, jakie techniki i technologie chcesz zastosować. Przeglądy wymagań, projektu i kodu, automatyczne testy, analiza statyczna, ciągła integracja i bardziej rozbudowane testy kierowane przez użytkownika mogą być opcjami, na które należy zwrócić uwagę, w zależności od tego, jakie fazy generują defekty.

Aby rozwinąć chęć recenzji kodu, należy również rozważyć różne poziomy recenzji kodu w zależności od priorytetu i ryzyka modułu. Moduły o niskim ryzyku i niskim priorytecie mogą w ogóle nie wymagać przeglądu kodu, a może po prostu zwykłego sprawdzania dokumentacji, w którym inny programista po prostu odczytuje kod i zapewnia komentarze. Inne techniki przeglądania kodu obejmują programowanie par, instrukcje, krytykę i inspekcje z różnymi programistami.

W celu wycofania chciałbym zautomatyzować ten proces za pomocą pewnego rodzaju skryptów, aby przyspieszyć i zmniejszyć podatność na błędy. W idealnym świecie chciałbym podnieść jakość wysyłanych produktów, tak aby nie trzeba było wycofywać, a można to osiągnąć. Posiadanie tej zdolności może być dobrym pomysłem, ale uczyń ją tak bezbolesną, jak to możliwe.

Jak zauważyli inni, dodanie testów regresji pomoże uniknąć tych samych wad pojawiających się w przyszłości. Jeśli jednak napotykasz nowe defekty, być może nadszedł czas, aby dodać aser (czyli kontrakty) do kodu określającego warunki wstępne, warunki końcowe i niezmienniki klas i metod.

Na przykład, jeśli masz klasę, w której metoda może akceptować tylko liczby od 10 do 25 (jest to nazywane warunkiem wstępnym), na początku metody dodamy instrukcję assert. Gdy to stwierdzenie się nie powiedzie, program natychmiast się zawiesi i będziesz mógł śledzić ciąg metod, które doprowadziły do ​​tego niepowodzenia.

Python, PHP i inne języki programowania są dynamicznie typowane i nie dodają wielu warunków do metod. Wszystko, czego potrzeba, aby coś zadziałało, to implementacja określonej metody. Podejrzewam, że potrzebujesz więcej warunków w swoich metodach. Musisz zdefiniować i przetestować, aby upewnić się, że metoda może faktycznie działać w swoim środowisku.

W przypadku programów C / C ++ stwierdziłem, że dodanie asercji do testowej alokacji pamięci było bardzo pomocne w zmniejszeniu liczby wycieków pamięci w programie.