W jaki sposób ludzie wykonujący TDD radzą sobie z utratą pracy podczas poważnej refaktoryzacji

37

Od jakiegoś czasu próbuję nauczyć się pisać testy jednostkowe dla mojego kodu.

Początkowo zacząłem robić prawdziwy TDD, w którym nie pisałbym żadnego kodu, dopóki nie napisałem najpierw testu zakończonego niepowodzeniem.

Jednak ostatnio miałem drażliwy problem do rozwiązania, który wymagał dużej ilości kodu. Po kilku tygodniach pisania testów, a potem pisania kodu, doszedłem do niefortunnego wniosku, że całe moje podejście się nie uda i będę musiał odrzucić dwa tygodnie pracy i zacząć od nowa.

Jest to wystarczająco zła decyzja, aby podjąć się, gdy właśnie napisałeś kod, ale kiedy napisałeś również kilkaset testów jednostkowych, jeszcze trudniej jest go wyrzucić.

Nie mogę przestać myśleć, że zmarnowałem 3 lub 4 dni na pisanie tych testów, kiedy mogłem po prostu skompletować kod dla potwierdzenia koncepcji, a następnie napisać testy, kiedy byłem zadowolony z mojego podejścia.

Jak osoby ćwiczące TDD właściwie radzą sobie z takimi sytuacjami? Czy w niektórych przypadkach można zginać reguły, czy zawsze najpierw niewolniczo piszesz testy, nawet jeśli kod ten może okazać się bezużyteczny?

tdd refactoring

— GazTheDestroyer
źródło

6

Perfekcję osiąga się nie wtedy, gdy nie ma już nic do dodania, ale kiedy nie ma już nic do zabrania. - Antoine de Saint-Exupery

— mouviciel

12

Jak to możliwe, że wszystkie twoje testy są nieprawidłowe? Wyjaśnij, w jaki sposób zmiana implementacji unieważnia każdy napisany test.

— S.Lott,

6

@ S.Lott: Testy nie były złe, po prostu nie były już istotne. Załóżmy, że rozwiązujesz część problemu za pomocą liczb pierwszych, więc piszesz klasę, aby wygenerować liczby pierwsze i piszesz testy dla tej klasy, aby upewnić się, że działa. Teraz znajdujesz zupełnie inne rozwiązanie swojego problemu, które w żaden sposób nie obejmuje liczb pierwszych. Ta klasa i jej testy są teraz zbędne. Taka była moja sytuacja tylko z dziesięcioma klasami, a nie tylko jedną.

— GazTheDestroyer

5

@GazTheDestroyer wydaje mi się, że rozróżnienie między kodem testowym a kodem funkcjonalnym jest błędem - wszystko to jest częścią tego samego procesu programowania. Należy zauważyć, że TDD ma narzut, który zwykle odzyskuje się w dalszej części procesu programowania i wydaje się, że w tym przypadku nic nie zyskało. Ale w równym stopniu, w jakim stopniu testy potwierdziły twoje zrozumienie wad architektury? Ważne jest również, aby pamiętać, że możesz (nie, zachęcamy ) przycinać swoje testy w czasie ... chociaż jest to prawdopodobnie nieco ekstremalne (-:

— Murph

10

Będę semantycznie pedantyczny i zgadzam się z @ S.Lott tutaj; nie dokonałeś refaktoryzacji, jeśli spowoduje to wyrzucenie wielu klas i testów dla nich. To jest przebudowa architektury . Refaktoryzacja, szczególnie w sensie TDD, oznacza, że testy były zielone, zmieniłeś jakiś wewnętrzny kod, ponownie uruchomiłeś testy i pozostały zielone.

— Eric King,

33

Wydaje mi się, że są tutaj dwie kwestie. Po pierwsze, nie zdawałeś sobie sprawy, że oryginalny projekt może nie być najlepszym podejściem. Jeśli wiesz o tym z góry, być może zdecydowałeś się opracować prototyp szybkiego wyrzucania lub dwa, aby zbadać możliwe opcje projektowania i ocenić, który jest najbardziej obiecujący. W prototypowaniu nie musisz pisać kodu jakości produkcji i nie musisz testować jednostkowo każdego zakamarki (lub w ogóle), ponieważ jedynym celem jest nauka, a nie dopracowywanie kodu.

Teraz uświadomienie sobie, że potrzebujesz prototypowania i eksperymentów, a nie rozpoczęcie tworzenia kodu produkcyjnego od razu, nie zawsze jest łatwe i nie zawsze jest możliwe. Uzbrojeni w właśnie zdobytą wiedzę, możesz następnym razem rozpoznać potrzebę prototypowania. A może nie. Ale przynajmniej wiesz teraz, że należy rozważyć tę opcję. I to samo w sobie jest ważną wiedzą.

Drugi problem to IMHO z twoim postrzeganiem. Wszyscy popełniamy błędy i z perspektywy czasu łatwo jest zobaczyć, co powinniśmy zrobić inaczej. Tak właśnie się uczymy. Zapisz swoją inwestycję w testy jednostkowe, ponieważ cena nauki o prototypowaniu może być ważna, i przełam ją. Staraj się nie popełniać tego samego błędu dwa razy :-)

— Péter Török
źródło

2

Wiedziałem, że będzie to trudny problem do rozwiązania i że mój kod będzie nieco eksploracyjny, ale byłem entuzjastycznie nastawiony do moich ostatnich sukcesów TDD, więc kontynuowałem pisanie testów tak, jak to zrobiłem, ponieważ to wszystko literatura TDD tak bardzo podkreśla. Więc tak, teraz wiem, że zasady można złamać (o to naprawdę chodziło w moim pytaniu). Prawdopodobnie napiszę to na dowód doświadczenia.

— GazTheDestroyer

3

„Kontynuowałem testy pisania, jak to zrobiłem, ponieważ tak bardzo podkreśla cała literatura TDD”. Prawdopodobnie powinieneś zaktualizować pytanie ze źródłem twojego pomysłu, że wszystkie testy muszą być napisane przed jakimkolwiek kodem.

— S.Lott,

1

Nie mam takiego pomysłu i nie jestem pewien, skąd masz to w komentarzu.

— GazTheDestroyer

1

Zamierzałem napisać odpowiedź, ale zamiast tego głosowałem za pana. Tak, milion razy tak: jeśli nie wiesz jeszcze, jak wygląda twoja architektura, najpierw napisz prototyp i nie zawracaj sobie głowy pisaniem testów jednostkowych podczas prototypowania.

— Robert Harvey

1

@WarrenP, na pewno są ludzie, którzy myślą, że TDD jest Jedną Prawdziwą Drogą (wszystko może zostać przekształcone w religię, jeśli spróbujesz wystarczająco mocno ;-). Wolę jednak być pragmatyczny. Dla mnie TDD jest jednym z narzędzi w moim zestawie narzędzi i używam go tylko wtedy, gdy pomaga, a nie przeszkadza, w rozwiązywaniu problemów.

— Péter Török,

8

Chodzi o to, że TDD zmusza cię do pisania małych przyrostów kodu w małych funkcjach , właśnie w celu uniknięcia tego problemu. Jeśli spędziłeś tygodnie na pisaniu kodu w jednej domenie, a każda metoda, którą napisałeś, staje się bezużyteczna po ponownym przemyśleniu architektury, wówczas twoje metody są prawie na pewno zbyt duże. (Tak, wiem, że nie jest to teraz pocieszające ...)

— Kilian Foth
źródło

3

Moje metody wcale nie były duże, po prostu stały się nieistotne, biorąc pod uwagę nową architekturę, która nie przypominała starej architektury. Częściowo dlatego, że nowa architektura była znacznie prostsza.

— GazTheDestroyer

W porządku, jeśli naprawdę nie ma nic wielokrotnego użytku, możesz jedynie ograniczyć straty i przejść dalej. Ale obietnicą TDD jest to, że pozwala szybciej osiągnąć te same cele, nawet jeśli piszesz kod testowy oprócz kodu aplikacji. Jeśli to prawda i tak mi się wydaje, to przynajmniej osiągnąłeś punkt, w którym zdałeś sobie sprawę z tego, jak zrobić architekturę w „kilka tygodni”, a nie dwa razy w tym czasie.

— Kilian Foth

1

@Kilian, re „obietnica TDD polega na tym, że dzięki niej szybciej osiągasz te same cele” - o jakich celach tu mówisz? Jest całkiem oczywiste, że pisanie testów jednostkowych wraz z samym kodem produkcyjnym początkowo spowalnia działanie , w porównaniu do samego rezygnacji z kodu. Powiedziałbym, że TDD zwróci się tylko w dłuższej perspektywie, ze względu na lepszą jakość i obniżone koszty utrzymania.

— Péter Török,

@ PéterTörök - Są ludzie, którzy twierdzą, że TDD nigdy nie ponosi żadnych kosztów, ponieważ zwraca się w momencie pisania kodu. Z pewnością nie jest tak dla mnie, ale Killian wydaje się wierzyć w siebie.

— psr

Cóż ... jeśli w to nie wierzysz, a jeśli nie wierzysz, że TDD ma znaczną korzyść, a nie koszty, to nie ma sensu tego robić, prawda? Nie tylko w bardzo konkretnej sytuacji opisanej przez Gaz, ale w ogóle . Obawiam się, że całkowicie usunąłem ten wątek :(

— Kilian Foth,

6

Brooks powiedział „plan wyrzucenia jednego; w każdym razie będziesz”. Wydaje mi się, że właśnie to robisz. To powiedziawszy, powinieneś napisać testy jednostkowe w celu przetestowania jednostki kodu, a nie dużego pokosu kodu. Są to bardziej testy funkcjonalne i dlatego powinny być przeprowadzane w ramach każdej wewnętrznej implementacji.

Na przykład, jeśli chcę napisać solver PDE (częściowe równania różniczkowe), napisałbym kilka testów próbujących rozwiązać rzeczy, które mogę rozwiązać matematycznie. To moje pierwsze testy „jednostkowe” - czytaj: testy funkcjonalne uruchamiane w ramach frameworka xUnit. Nie zmienią się one w zależności od tego, jakiego algorytmu używam do rozwiązania PDE. Wszystko, na czym mi zależy, to wynik. Drugie testy jednostkowe skupią się na funkcjach używanych do kodowania algorytmu, a zatem będą specyficzne dla algorytmu - powiedzmy Runge-Kutta. Gdybym miał dowiedzieć się, że Runge-Kutta nie był odpowiedni, nadal miałbym te testy na najwyższym poziomie (w tym te, które wykazały, że Runge-Kutta nie był odpowiedni). Zatem druga iteracja nadal miałaby wiele takich samych testów jak pierwsza.

Twój problem może dotyczyć projektu, a niekoniecznie kodu. Ale bez dalszych szczegółów trudno powiedzieć.

— Sardathrion - Przywróć Monikę
źródło

To tylko peryferyjne, ale co to jest PDE?

— CVn

1

@ MichaelKjörling Myślę, że to równanie różniczkowe cząstkowe

— zapomniane

2

Czy Brooks nie wycofał tego stwierdzenia w swoim drugim wydaniu?

— Simon

Co masz na myśli mówiąc, że nadal będziesz mieć testy, które wykażą, że Runge-Kutta nie był odpowiedni? Jak wyglądają te testy? Czy masz na myśli, że zapisałeś napisany przez siebie algorytm Runge-Kutta, zanim odkryłeś, że nie jest on odpowiedni, a uruchomienie kompleksowych testów z RK w miksie nie powiedzie się?

— moteutsch

5

Należy pamiętać, że TDD jest procesem iteracyjnym. Napisz mały test (w większości przypadków powinno wystarczyć kilka wierszy) i uruchom go. Test powinien zakończyć się niepowodzeniem, teraz należy bezpośrednio pracować na głównym źródle i spróbować wdrożyć testowaną funkcjonalność, aby test przeszedł pomyślnie. Teraz zacznij od nowa.

Nie powinieneś próbować pisać wszystkich testów za jednym razem, ponieważ, jak zauważyłeś, to się nie uda. Zmniejsza to ryzyko marnowania czasu na pisanie testów, które nie będą używane.

— BenR
źródło

1

Nie sądzę, żebym mógł sobie dobrze wytłumaczyć. Testy piszę iteracyjnie. Tak skończyło się na kilkuset testach kodu, który nagle stał się zbędny.

— GazTheDestroyer,

1

Jak wyżej - myślę, że należy to traktować raczej jako „testy i kod” niż „testy kodu”

— Murph,

1

+1: „Nie powinieneś próbować pisać wszystkich testów za jednym razem”

— S.Lott,

4

Myślę, że sam to powiedziałeś: nie byłeś pewien swojego podejścia, zanim zacząłeś pisać wszystkie testy jednostkowe.

Czego się nauczyłem, porównując rzeczywiste projekty TDD, z którymi pracowałem (w rzeczywistości nie tak wiele, tylko 3 obejmujące 2 lata pracy) z tym, czego nauczyłem się teoretycznie, to automatyczne testowanie! = Testowanie jednostkowe (oczywiście bez wzajemnego testowania Ekskluzywny).

Innymi słowy, T w TDD nie musi mieć ze sobą U ... Jest zautomatyzowany, ale jest mniej testem jednostkowym (jak w klasach i metodach testowych) niż automatyczny test funkcjonalny: jest na tym samym poziomie funkcjonalnej szczegółowości jako architektury, nad którą obecnie pracujesz. Zaczynasz na wysokim poziomie, z kilkoma testami i tylko funkcjonalnym dużym obrazem, i dopiero w końcu dostajesz tysiące UT, a wszystkie twoje klasy są dobrze zdefiniowane w pięknej architekturze ...

Testy jednostkowe zapewniają dużą pomoc podczas pracy w zespole, aby uniknąć zmian w kodzie, powodując niekończące się cykle błędów. Ale nigdy nie napisałem niczego tak precyzyjnego, kiedy zaczynałem pracę nad projektem, zanim nie miałem przynajmniej globalnego działającego POC dla każdej historii użytkownika.

Może to tylko mój osobisty sposób na zrobienie tego. Nie mam wystarczającego doświadczenia, aby od początku zdecydować, jakie wzory lub strukturę będzie miał mój projekt, więc rzeczywiście nie będę marnować czasu na pisanie setek UT od samego początku ...

Mówiąc bardziej ogólnie, pomysł zniszczenia wszystkiego i wyrzucenia wszystkiego zawsze będzie obecny. Choć „ciągłe”, jak możemy próbować być przy użyciu naszych narzędzi i metod, czasami jedynym sposobem na walkę z entropią jest rozpoczęcie od nowa. Ale celem jest to, że kiedy to nastąpi, zautomatyzowane i jednostkowe testy, które wdrożysz, sprawią, że Twój projekt będzie już mniej kosztowny, niż gdyby go nie było - i tak będzie, jeśli znajdziesz równowagę.

— GFK
źródło

3

dobrze powiedziane - to TDD, a nie UTDD

— Steven A. Lowe

Doskonała odpowiedź. Z mojego doświadczenia z TDD ważne jest, aby testy pisemne koncentrowały się na funkcjonalnych zachowaniach oprogramowania i poza testowaniem jednostkowym. Trudniej jest myśleć o zachowaniach, których potrzebujesz od klasy, ale prowadzi to do czystych interfejsów i potencjalnie upraszcza wynikową implementację (nie dodajesz funkcji, których tak naprawdę nie potrzebujesz).

— JohnTESlade,

4

Jak osoby ćwiczące TDD właściwie radzą sobie z takimi sytuacjami?

rozważając, kiedy prototypować, a kiedy kodować
przez uświadomienie sobie, że testowanie jednostkowe to nie to samo co TDD
pismami Testy TDD w celu weryfikacji cechy / historii, a nie jednostki funkcjonalnej

Połączenie testów jednostkowych z rozwojem opartym na testach jest źródłem wielu udręk i biada. Przejrzyjmy to jeszcze raz:

testowanie jednostkowe dotyczy weryfikacji każdego modułu i funkcji we wdrażaniu ; w UT nacisk kładziony jest na takie rzeczy, jak wskaźniki pokrycia kodu i testy, które wykonują się bardzo szybko
rozwój oparty na testach dotyczy weryfikacji każdej funkcji / historii w wymaganiach ; w TDD nacisk zostanie położony na takie rzeczy, jak najpierw napisanie testu, upewnienie się, że napisany kod nie przekracza zamierzonego zakresu oraz refaktoryzacja pod kątem jakości

Podsumowując: testowanie jednostkowe koncentruje się na implementacji, TDD koncentruje się na wymaganiach. To nie to samo.

— Steven A. Lowe
źródło

„TDD koncentruje się na wymaganiach” Całkowicie się z tym nie zgadzam. Testy, które zapisujesz w TDD, są testami jednostkowymi. Oni zrobić zweryfikować każdą funkcję / metodę. TDD nie mają nacisk na pokrycia kodu i nie dbają o testach, które wykonywane są szybko (a oni lepiej zrobić, skoro uruchomić testy co 30 sekund lub tak). Może myślałeś o ATDD lub BDD?

— guillaume31

1

@ ian31: idealny przykład połączenia UT i TDD. Musisz się nie zgodzić i skierować Cię do jakiegoś źródła: en.wikipedia.org/wiki/Test-driven_development - celem testów jest zdefiniowanie wymagań kodowych . BDD jest świetne. Nigdy nie słyszałem o ATDD, ale na pierwszy rzut oka wygląda to tak, jak stosuję skalowanie TDD .

— Steven A. Lowe,

Możesz doskonale wykorzystać TDD do zaprojektowania kodu technicznego, który nie jest bezpośrednio związany z wymaganiami lub historią użytkownika. Niezliczone przykłady tego można znaleźć w Internecie, w książkach, na konferencjach, w tym od osób, które zainicjowały TDD i ją spopularyzowały. TDD to dyscyplina, technika pisania kodu, nie przestanie być TDD w zależności od kontekstu, w którym go używasz.

— guillaume31

Również z artykułu w Wikipedii, o którym wspomniałeś: „Zaawansowane praktyki programowania opartego na testach mogą prowadzić do ATDD, w którym kryteria określone przez klienta są automatycznie przekształcane w testy akceptacyjne, które następnie napędzają tradycyjny proces programowania opartego na testach jednostkowych (UTDD). [ ...] Dzięki ATDD zespół programistów ma teraz konkretny cel do spełnienia, testy akceptacyjne, dzięki którym stale koncentruje się na tym, czego naprawdę chce klient od tej historii użytkownika. ” Co wydaje się sugerować, że ATDD koncentruje się przede wszystkim na wymaganiach, a nie TDD (lub UTDD, jak to określają).

— guillaume31,

@ ian31: Pytanie OP dotyczące „wyrzucenia kilkuset testów jednostkowych” wskazuje na zamieszanie skali. Możesz użyć TDD do zbudowania szopy, jeśli chcesz. : D

— Steven A. Lowe

3

Rozwój oparty na testach ma na celu napędzanie rozwoju. Testy, które piszesz, pomagają potwierdzić poprawność pisanego kodu i zwiększają szybkość programowania od pierwszego wiersza.

Wydaje się, że wierzysz, że testy są obciążeniem i są przeznaczone tylko do późniejszego rozwoju. Ten sposób myślenia nie jest zgodny z TDD.

Może możesz to porównać do pisania statycznego: chociaż można pisać kod bez informacji o typie statycznym, dodanie typu statycznego do kodu pomaga w zapewnieniu pewnych właściwości kodu, uwalniając umysł i pozwalając skupić się na ważnej strukturze, zwiększając w ten sposób prędkość i skuteczność.

— Dibbeke
źródło

2

Problem z robieniem poważnego refaktoryzacji polega na tym, że możesz i czasami podążasz ścieżką, która prowadzi cię do zrozumienia, że odgryzłeś więcej niż możesz przeżuć. Wielkie refaktoryzacje są błędem. Jeśli projekt systemu jest wadliwy, to refaktoryzacja może zająć Ci tylko tyle czasu, zanim będziesz musiał podjąć trudną decyzję. Albo zostaw system bez zmian i obejdź go, albo zaplanuj przeprojektowanie i dokonaj poważnych zmian.

Jest jednak inny sposób. Prawdziwą zaletą refaktoryzacji kodu jest uproszczenie, łatwiejszy do odczytania, a nawet łatwiejszy w utrzymaniu. Gdy podejdziesz do problemu, którego nie masz pewności, zmieniasz zmianę, idziesz tak daleko, aby dowiedzieć się, gdzie może to prowadzić, aby dowiedzieć się więcej o problemie, a następnie wyrzucasz skok i zastosujesz nowe refaktoryzowanie w zależności od tego, co to skok nauczył cię. Chodzi o to, że naprawdę możesz poprawić swój kod z pewnością tylko wtedy, gdy kroki są małe, a wysiłki związane z refaktoryzacją nie przerastają twojej zdolności do pisania testów. Pokusa polega na napisaniu testu, następnie napisaniu kodu, a następnie napisaniu kodu, ponieważ rozwiązanie może wydawać się oczywiste, ale wkrótce zdajesz sobie sprawę, że twoja zmiana zmieni wiele innych testów, więc musisz uważać, aby zmieniać tylko jedną rzecz na raz.

Dlatego odpowiedzią jest, aby nigdy nie uczynić swojego refaktoryzacji ważnym. Dziecięce kroki. Zacznij od wyodrębnienia metod, a następnie spójrz na usunięcie duplikacji. Następnie przejdź do wyodrębniania klas. Każdy krok po kroku, drobna zmiana. JEŚLI wyodrębniasz kod, najpierw napisz test. Jeśli usuwasz kod, usuń go, uruchom testy i zdecyduj, czy którykolwiek z uszkodzonych testów będzie potrzebny. Jeden mały krok po kroku. Wydaje się, że zajmie to więcej czasu, ale w rzeczywistości znacznie skróci czas refaktoryzacji.

Rzeczywistość jest jednak taka, że każdy skok wydaje się potencjalnie stratą wysiłku. Czasami zmiany kodu nigdzie nie idą, a ty przywracasz kod z vcs. To tylko rzeczywistość tego, co robimy z dnia na dzień. Każdy kolec, który zawodzi, nie jest jednak marnowany, jeśli czegoś cię nauczy. Każdy wysiłek refaktoryzacji, który się nie powiedzie, nauczy cię, że albo próbujesz zbyt szybko zrobić zbyt wiele, albo że twoje podejście może być błędne. To też nie jest strata czasu, jeśli się czegoś nauczysz. Im częściej to robisz, tym więcej się uczysz i tym bardziej będziesz efektywny. Moja rada to po prostu na razie go nosić, nauczyć się robić więcej, robiąc mniej, i zaakceptować, że tak właśnie powinno być, dopóki nie będziesz w stanie lepiej określić, jak daleko zaostrzyć skok, zanim nigdzie cię to nie zaprowadzi.

— S.Robins
źródło

1

Nie jestem pewien, dlaczego Twoje podejście okazało się wadliwe po 3 dniach. W zależności od niepewności w architekturze możesz rozważyć zmianę strategii testowania:

Jeśli nie masz pewności co do wydajności, możesz zacząć od kilku testów integracyjnych, które potwierdzają wydajność?
Gdy badasz złożoność interfejsu API, napisz kilka prawdziwych, małych testów jednostkowych, aby dowiedzieć się, jaki byłby najlepszy sposób, aby to zrobić. Nie zawracaj sobie głowy wdrażaniem czegokolwiek, po prostu spraw, aby Twoje klasy zwracały wartości zakodowane na stałe lub zmusza je do zgłaszania NotImplementedExceptions.

— Boris Callens
źródło

0

Dla mnie testy jednostkowe są również okazją do wprowadzenia interfejsu w „rzeczywiste” zastosowanie (cóż, tak prawdziwe, jak to tylko możliwe!).

Jeśli jestem zmuszony do przeprowadzenia testu, muszę wykonać swój projekt. Pomaga to zachować rozsądek (jeśli coś jest tak skomplikowane, że napisanie testu jest ciężarem, jak to będzie z niego korzystać?).

Nie pozwala to uniknąć zmian w projekcie, a raczej uwidacznia ich potrzebę. Tak, całkowite przepisanie jest uciążliwe. Aby (próbować) tego uniknąć, zwykle konfiguruję (jeden lub więcej) prototyp, prawdopodobnie w Pythonie (z ostatecznym opracowaniem w c ++).

To prawda, że nie zawsze masz czas na te wszystkie gadżety. To są dokładnie przypadki, w których potrzebujesz DUŻO czasu, aby osiągnąć swoje cele ... i / lub utrzymać wszystko pod kontrolą.

— Francesco
źródło

0

Witamy w cyrku kreatywnych programistów .

Zamiast szanować wszystkie „legalne / rozsądne” sposoby kodowania na początku,
spróbuj intuicji , przede wszystkim, jeśli jest to ważne i nowe dla Ciebie, a jeśli żadna próbka nie wygląda tak, jak chcesz:

- Pisz instynktownie z rzeczy, które już znasz , nie twoją mentalnością i wyobraźnią.
- I stój.
- Weź szkło powiększające i sprawdź wszystkie słowa, które piszesz: piszesz „tekst”, ponieważ „tekst” jest zbliżony do ciągu, ale potrzebny jest „czasownik”, „przymiotnik” lub coś dokładniejszego, przeczytaj ponownie i dostosuj metodę z nowym wyczuciem
. .. czy napisałeś fragment kodu, który myśli o przyszłości? usuń
- Popraw, zrób inne zadanie (sport, kultura lub inne rzeczy poza biznesem), wróć i przeczytaj ponownie.
- Wszystko dobrze pasuje,
- Poprawnie, zrób inne zadanie, wróć i przeczytaj ponownie.
- Wszystko pasuje dobrze, przekaż do TDD
- Teraz wszystko jest w porządku, dobrze
- Wypróbuj benchmark, aby wskazać rzeczy do optymalizacji, zrób to.

Co się pojawia:
- napisałeś kod zgodny z wszystkimi regułami
- dostajesz doświadczenie, nowy sposób pracy,
- coś zmienia się w twoim umyśle, nigdy nie będziesz się bał nowej konfiguracji.

A teraz, jeśli zobaczysz UML wyglądający jak wyżej, będziesz mógł powiedzieć
„Szefie, zaczynam od TDD w tym celu…”
to kolejna nowa rzecz?
„Szefie, spróbowałbym czegoś, zanim zdecyduję, w jaki sposób będę kodować ..”

Pozdrawiam PARIS
Claude

— cl-r
źródło