Metodologia zwinna: szybka i brudna czy najpierw planowana?

Zwinne pytanie: czy zwinny wierzy w uruchamianie rzeczy w „szybki i brudny sposób” - czy zwinny woli budować solidnie od podstaw? A może nie jest to pytanie metodologiczne, a raczej pytanie, które oceniasz indywidualnie?

Technicznie „przerabiam” fundament systemu, po tym jak zbudowałem już większość samej konstrukcji ... to nie jest ogromna ilość pracy… zwinny chciałby, żebym najpierw sprecyzował cały przepływ, przeanalizował go, popraw to, a następnie buduj? Wydaje mi się, że w ten sposób jest lepiej ... kiedy już wprowadzę nieporządny system, lepiej widzę, jak należy to zrobić ... z drugiej strony nie jest tak zorganizowany ... po prostu ciekawy, jaki najlepszy rozwój praktyka jest pod tym względem.

Uważam, że to pytanie jest nieco inne niż zwinne i prototypowe, ponieważ nie pytam o prototypowanie i niepotrzebny kod; Interesuje mnie zwinność kodu klasy produkcyjnej.

Metodologia zwinna jest najpierw planowana. Po prostu nie wszystko najpierw. W rzeczywistości gromadzisz wymagania, projektujesz, kodujesz, testujesz, wdrażasz i prezentujesz. Robisz to wszystko w mniej niż dwa tygodnie (daj lub weź) przy najmniejszej funkcji, jaką możesz wdrożyć i uzyskać informacje zwrotne. Następnie ponownie to wszystko robisz, dodając kolejną funkcję lub zmieniając starą.

Kluczem jest napisanie kodu, który akceptuje zmiany, aby kiedy w końcu zobaczysz „jak powinien wyglądać cały przepływ”, możesz zmienić kod, aby to zrobić. W ten sposób, gdy „sposób, w jaki powinien płynąć przepływ” (lub cokolwiek innego) zmienia się ponownie, nie jest to traumatyczne.

Nie możesz pisać szybko i brudnie. Szybki i brudny kod daje ci niesamowity kod. Bądź szybki, pracując na małą skalę. Zachowaj elastyczność, nie rozpowszechniając wiedzy . Idealnie każda pojedyncza zmiana funkcji powinna mieć wpływ tylko na jedno miejsce w kodzie.

Nie można też spędzić mnóstwo czasu, robiąc tylko planowanie. Możesz planować, ale musisz mieć możliwość zmiany planu. Musisz szybko odkryć powody zmiany planu. Gdy planowanie przebiega bezproblemowo, bez żadnych niespodzianek, można się na nim zbyt długo zastanawiać. Planowanie i kodowanie muszą odbywać się blisko siebie. Jeśli uczysz się, tym starszy plan, tym głupszy jest.

W dłuższej perspektywie powinieneś planować stać się mądrzejszym. Napisz elastyczny kod. Zatem bycie mądrzejszym nie prowadzi do żalu.

Nie podoba mi się to, że dla większości ludzi jest to „szybki i brudny” lub „duży projekt z przodu”. Nie uważają nawet, że istnieją inne opcje.

Agile polega na budowaniu systemu, w którym zmiany, nawet na późnym etapie rozwoju, są banalne. Odbywa się to poprzez budowanie oprogramowania w małych, przyrostowych porcjach i blokowanie zachowania tych porcji za pomocą solidnych automatycznych testów. I przy użyciu częstego, automatycznego wdrażania w produkcji, aby zweryfikować wartość tych zmian.

Dzięki solidnym zautomatyzowanym testom zmiana nawet najtrudniejszych części architektury staje się banalna, poprzez stopniowe refaktoryzowanie w dłuższych okresach czasu. Więc nawet jeśli zdajesz sobie sprawę, że twoja architektura mogłaby być lepiej wykonana w połowie projektu, realistycznie możliwe jest dokonanie zmiany stosunkowo szybko.

Niektórzy twierdzą, że „niektóre projekty z przodu” są dobre w przypadku zwinności. Ale jeśli zamierzasz później powtórzyć ten projekt, nadal musisz upewnić się, że twoja kultura programistyczna tworzy system, który można łatwo zmienić. Tak więc „SDUF” nie unieważnia potrzeby dokładnych testów, agresywnego refaktoryzacji i ciągłego wdrażania.

Budując „łatwość zmian” w systemie, nie musisz się zastanawiać nad początkowym projektem swojego projektu, ponieważ można go później zmienić. Podejście „szybkie i brudne”, które większość ludzi nazywa to „skokiem”, jest użyteczne tylko wtedy, gdy ustabilizujesz funkcje, które uważasz za cenne. Nie należy jednak zbyt długo pozostawiać fragmentów zhakowanego kodu w bazie kodu, ponieważ spowalniają one zmiany.

Ani.

Jest to „Zacznij od prostoty i ulepszaj się podczas ruchu”.

Szybkie i brudne są kruche, ale szybkie (jeśli projekt jest wystarczająco mały i krótkotrwały).

Najpierw plan jest sztywny, ale stabilny (jeśli projekt zostanie zakończony, zanim napotkają ograniczenia finansowe lub czasowe).

Zwinne jest alternatywą dla 2 powyżej. Opiera się na iteracyjnym podejściu, w którym funkcje są uzupełniane pojedynczo, funkcja po funkcji, a wiedza zdobyta podczas wypełniania tych w pełni funkcjonalnych elementów programu jest wykorzystywana do opracowania i dostosowania planu w miarę rozwoju. Aby to zrobić, konieczne jest wcześniejsze planowanie - potrzebujesz co najmniej wystarczającego planowania, aby móc oszacować, ile pracy wymagają poszczególne funkcje - ale ponieważ zwinny oczekuje zmian, nadmierne planowanie prowadzi do marnotrawstwa.

Jedną z głównych cech Agile jest wykonywanie krótkich iteracji, a następnie ponowna ocena. Biegniesz naprzód, eksplorując nowe terytorium, ucząc się na nim, a następnie opracowując plan. W ten sposób Twój plan będzie lepszy. A jeśli się nie uda (okaże się, że pomysł na kurs nie działa), „szybko się nie uda”, co jest dobre.

Więc twoje podejście jest w porządku. Niebezpieczeństwo polega jednak na powiedzeniu „Fajnie, działa, skończyłem. Co dalej?”. Jeszcze nie skończyłeś, jest wiele ciętych narożników do wyprostowania i powinieneś / powinnaś poświęcić trochę czasu, aby zrobić to poprawnie, gdy jest jasne, że twoje podejście daje działający i sprawny system. Może to być pisanie testów, dokumentowanie, StyleCop, optymalizowanie, edukowanie kolegów o tym, co zrobiłeś i jak to zrobiłeś, poddanie go przeglądowi itp.

Aby dodać do powyższych odpowiedzi, kluczową zasadą jest YAGNI . Jeśli Twój wstępny projekt i planowanie umożliwia następny krok, to dobrze. Ale jeśli umożliwi hipotetyczny przyszły krok, którego nie można udowodnić, że jest potrzebny, załóżmy, że YAGNI.

Wiele projektów, zarówno od góry do dołu, jak i od dołu do góry, zakłada, że ​​będzie znaczące ponowne użycie kodu. Doświadczenie mówi jednak, że ponowne użycie kodu po prostu nie jest tak częste, ponieważ rzadko rozwiązujesz dokładnie ten sam problem. Jeśli chcesz rozwiązać wariant tego problemu w przyszłości, zmodyfikuj swój projekt w przyszłości, aby dodać ten wariant, ale nie bierz go teraz pod uwagę.

Innymi słowy, zaplanuj natychmiastowe zadanie, ale nie planuj niczego dalej.