Wady Test Driven Development? [zamknięte]

Jeśli chcesz zrobić "prawdziwe" TDD (Czytaj: najpierw testuj z czerwonymi, zielonymi krokami refactor), musisz również zacząć używać mocks/stubs, gdy chcesz przetestować punkty integracji.

Kiedy zaczniesz używać mocks, po pewnym czasie będziesz chciał zacząć używać Dependency Injection (DI) i Inversion of Control (IoC) container. Aby to zrobić, musisz użyć interfejsów do wszystkiego (które same w sobie mają wiele pułapek).

Na koniec dnia, musisz napisać o wiele więcej kodu, niż Jeśli zrobisz to po prostu "po staremu". Zamiast tylko klasy klienta, musisz również napisać interfejs, klasę makiety, konfigurację IoC I kilka testów.

I pamiętaj, że kod testowy również powinien być utrzymywany i pielęgnowany. Testy powinny być tak samo czytelne jak Wszystko inne i potrzeba czasu, aby napisać dobry kod.

Wielu programistów nie do końca rozumie, jak zrobić to wszystko "we właściwy sposób". Ale ponieważ wszyscy mówią im, że TDD jest jedynym prawdziwym sposobem na rozwój oprogramowanie, po prostu starają się jak mogą.

Jest to o wiele trudniejsze niż mogłoby się wydawać. Często projekty wykonane z TDD kończą się dużą ilością kodu, którego nikt tak naprawdę nie rozumie. Testy jednostkowe często sprawdzają niewłaściwą rzecz, niewłaściwy sposób. I nikt nie zgadza się, jak powinien wyglądać dobry test, nawet tak zwani Guru.

Te wszystkie testy znacznie utrudniają "zmianę" (w przeciwieństwie do refaktoryzacji) zachowania systemu, a proste zmiany stają się po prostu zbyt trudne i czas / align = "left" /

Jeśli czytasz literaturę TDD, zawsze jest kilka bardzo dobrych przykładów, ale często w rzeczywistych aplikacjach musisz mieć interfejs użytkownika i bazę danych. To tutaj TDD staje się naprawdę trudne, a większość źródeł nie oferuje dobrych odpowiedzi. A jeśli tak, to zawsze wiąże się z większą ilością abstrakcji: mock obiektów, programowania do interfejsu, wzorców MVC / MVP itp., które ponownie wymagają dużej wiedzy i... musisz napisać jeszcze więcej kodu.

Więc bądź ostrożny... jeśli nie masz entuzjastycznego zespołu i co najmniej jednego doświadczonego programisty, który wie, jak pisać dobre testy, a także wie kilka rzeczy o dobrej architekturze, naprawdę musisz pomyśleć dwa razy, zanim pójdziesz w dół drogi TDD.

Kiedy dojdziesz do punktu, w którym masz dużą liczbę testów, zmiana systemu może wymagać ponownego napisania niektórych lub wszystkich testów, w zależności od tego, które z nich zostały unieważnione przez zmiany. Może to zmienić stosunkowo szybką modyfikację w bardzo czasochłonną.

Możesz też zacząć podejmować decyzje projektowe w oparciu bardziej o TDD niż o faktycznie dobre zasady projektowania. Natomiast być może masz bardzo proste, łatwe rozwiązanie, które jest niemożliwe do przetestowania sposób TDD wymagania, masz teraz znacznie bardziej złożony system, który jest bardziej podatny na błędy.

Myślę, że największym problemem dla mnie jest ogromna strata czasu, który zajmuje "dostanie się do niego". Jestem jeszcze bardzo na początku mojej podróży z TDD (Zobacz mój blog , aby aktualizować moje przygody testowe, jeśli jesteś zainteresowany) i dosłownie spędziłem godziny na rozpoczynaniu.

Potrzeba dużo czasu, aby wprowadzić swój mózg w" tryb testowy", a pisanie "testowalnego kodu" jest umiejętnością samą w sobie.

TBH, z całym szacunkiem nie zgadzam się zkomentarzami Jasona Cohena na upublicznianie prywatnych metod, nie o to chodzi. w moim nowym sposobie pracy nie stworzyłem więcej publicznych metod niż wcześniej . Wiąże się to jednak ze zmianami architektonicznymi i pozwala na "podłączenie" modułów kodu, aby Wszystko inne było łatwiejsze do przetestowania. Powinieneś NIE sprawić, by wewnętrzne elementy Twojego kodu były bardziej dostępne w tym celu. W przeciwnym razie wracamy do punktu wyjścia z tym, że wszystko jest publiczne, gdzie jest w tym enkapsulacja?

Tak, (IMO) w "nutshell": {]}

• czas potrzebny na zastanowienie się (tj. faktycznie grok ' ING testowanie ).
• nowa wiedza wymagana do pisania testowalnego kodu.
• zrozumienie zmian architektonicznych wymaganych do testowania kodu.
[19]} zwiększając swoje umiejętności "TDD-Coder", starając się poprawić wszystkie inne umiejętności wymagane do naszego wspaniałego rzemiosła programistycznego:) [22]}
• uporządkowanie bazy kodu tak, aby zawierał kod testowy bez wkręcania twojego kod produkcji.

  ---

PS: Jeśli chcesz linki do pozytywów, zadałem i odpowiedziałem na kilka pytań na ten temat, sprawdź mój Profil.

W ciągu kilku lat, w których ćwiczyłem Test Driven Development, muszę powiedzieć, że największe minusy to:

Sprzedam go zarządowi

TDD najlepiej wykonać w parach. Po pierwsze, trudno oprzeć się pokusie napisania implementacji, kiedy wiesz Jak napisać if/else . Ale para będzie trzymać cię na zadanie, ponieważ trzymasz go na zadanie. Niestety, wiele firm / menedżerów nie uważa, że jest to dobre wykorzystanie zasobów. Po co płacić za dwie osoby do napisania jednej funkcji, Kiedy mam dwie funkcje, które muszą być wykonane w tym samym czasie?

Sprzedam go innym programistom

Niektórzy ludzie po prostu nie mają cierpliwości do pisania testów jednostkowych. Niektórzy są bardzo dumni ze swojej pracy. Lub niektóre po prostu lubią widzieć zawiłe metody / funkcje wykrwawiające się na końcu ekranu. TDD nie jest dla wszystkich, ale naprawdę chciałbym, żeby tak było. Ułatwiłoby to utrzymanie tych biednych dusz, które dziedziczą kod.

Utrzymanie kodu testowego wraz z kodem produkcyjnym

Idealnie, twoje testy ulegną awarii tylko wtedy, gdy podejmiesz złą decyzję o kodzie. Czyli myślałeś, że system działa w jeden sposób, a okazuje się, że nie. przełamując test lub (mały) zestaw testów, jest to właściwie dobra wiadomość. Wiesz dokładnie, jak Twój nowy kod wpłynie na system. Jeśli jednak twoje testy są źle napisane, ściśle powiązane lub, co gorsza, wygenerowane ( VS Test), a następnie utrzymanie testów może szybko stać się chórem. I, po wystarczająco dużo testów zaczynają powodować więcej pracy, że postrzegana wartość, którą tworzą, następnie testy będą pierwszą rzeczą do usunięcia, gdy harmonogramy zostaną skompresowane (np. it gets to crunch time)

Pisanie testów tak, aby pokryć wszystko (100% pokrycia kodu)

Najlepiej, jeśli zastosujesz się do metodologii, Twój kod będzie domyślnie w 100% testowany. Zazwyczaj, myśląc, kończę z pokrycie kodu w górę o 90%. Zwykle dzieje się tak, gdy mam architekturę stylu szablonu, a baza jest testowana i staram się wyciąć rogi, a nie testować dostosowania szablonu. Odkryłem również, że gdy napotkam nową barierę, z którą wcześniej nie spotkałem, mam krzywą uczenia się w testowaniu jej. Przyznam się do pisania kilku linijek kodu w stary sposób skool, ale naprawdę lubię mieć to w 100%. (Chyba byłem over achiever w szkole, er skool).

Jednak, z tym powiedziałbym, że korzyści z TDD znacznie przewyższają negatywy dla prostego pomysłu, że jeśli możesz osiągnąć dobry zestaw testów, które obejmują swoją aplikację, ale nie są tak kruche, że jedna zmiana łamie je wszystkie, będziesz mógł dodawać nowe funkcje w dniu 300 twojego projektu, tak jak w dniu 1. Tak się nie dzieje z tymi wszystkimi, którzy próbują TDD, myśląc, że to magiczna kula do całego ich kodu z błędami, a więc myślą, że to nie może zadziałać, kropka.

Osobiście odkryłem, że z TDD piszę prostszy kod, spędzam mniej czasu na debatach, czy konkretne rozwiązanie kodu zadziała, czy nie, i że nie boję się zmieniać dowolnej linii kodu, która nie spełnia kryteriów określonych przez zespół.

TDD to trudna dyscyplina do opanowania i zajmuję się nią od kilku lat, a ciągle uczę się nowych technik testowania. Z góry jest to ogromna inwestycja czasowa, ale w dłuższej perspektywie zrównoważony rozwój będzie znacznie większy niż w przypadku braku zautomatyzowanych testów jednostkowych. Gdyby tylko moi szefowie mogli to rozgryźć.

Na Twoim pierwszym projekcie TDD są dwie duże straty, czas i wolność osobista

Tracisz czas Bo:

• stworzenie kompleksowego, refakturowanego, łatwego do utrzymania zestawu testów jednostkowych i akceptacyjnych dodaje sporo czasu do pierwszej iteracji projektu. Może to być czas zaoszczędzony na dłuższą metę, ale może to być czas, którego nie musisz oszczędzać.
Musisz wybrać i stać się ekspertem w zestawie podstawowych narzędzi. Narzędzie do testowania jednostkowego musi być uzupełnione o jakiś szyderczych RAM i oba muszą stać się częścią zautomatyzowanego systemu budowania. Chcesz również wybrać i wygenerować odpowiednie metryki.

Tracisz wolność osobistą, ponieważ:

• TDD jest bardzo zdyscyplinowanym sposobem pisania kodu, który ma tendencję do ocierać się o te na górze i na dole skali umiejętności. Zawsze pisanie kodu produkcyjnego w określony sposób i poddawanie swojej pracy ciągłej recenzji może przerażać najgorszych i najlepszych programistów, a nawet prowadzić do utraty pracowników.
• większość zwinnych metod, które osadzają TDD wymaga ciągłego rozmawiania z klientem o tym ,co proponujesz osiągnąć (w tej historii/dniu/cokolwiek) i jakie są kompromisy. Po raz kolejny to nie jest herbata dla wszystkich, zarówno po stronie deweloperów, jak i klientów.

Hope this helps

TDD wymaga od Ciebie zaplanowania, jak będą działać Twoje klasy, zanim napiszesz kod, aby zdać te testy. To zarówno plus, jak i minus.

Trudno mi pisać testy w" próżni " - zanim jakiś kod został napisany. Z mojego doświadczenia mam tendencję do potknięcia się o moich testach, gdy nieuchronnie myślę o czymś podczas pisania moich zajęć, o czym zapomniałem podczas pisania moich testów wstępnych. Wtedy nadszedł czas, aby nie tylko refaktorować moje zajęcia, ale także testy. Powtórz to trzy lub cztery razy i to może być frustrujące.

Wolę najpierw napisać szkic moich klas, a następnie napisać (i utrzymać) baterię testów jednostkowych. Po tym, jak mam projekt, TDD działa dobrze dla mnie. Na przykład, jeśli zostanie zgłoszony błąd, napiszę test, który wykorzysta ten błąd, a następnie poprawię kod, aby test przeszedł pomyślnie.

Prototypowanie może być bardzo trudne z TDD - kiedy nie jesteś pewien, jaką drogą zmierzasz do rozwiązania, pisanie testów z góry może być trudne (inne niż bardzo szerokie). To może być bolesne.

Szczerze mówiąc nie sądzę, aby w przypadku" core development " dla zdecydowanej większości projektów był jakiś prawdziwy minus; jest on omawiany o wiele bardziej niż powinien być, zwykle przez ludzi, którzy uważają, że ich kod jest na tyle dobry, że nie potrzebują testów (nigdy nie jest) i ludzie, którzy po prostu nie chcą ich pisać.

No i to rozciąganie, trzeba debugować testy. Ponadto istnieje pewien koszt w czasie pisania testów, choć większość ludzi zgadza się, że jest to inwestycja z góry, która opłaca się przez cały okres użytkowania aplikacji, zarówno w czasie zaoszczędzonym debugowaniu, jak i stabilności.

Największym problemem, jaki miałem z tym osobiście, jest podniesienie dyscypliny do pisania testów. W zespole, szczególnie w zespole o ugruntowanej pozycji, trudno jest przekonać ich, że czas wydane są warte zachodu.

Tracisz zdolność do powiedzenia, że jesteś "skończony" przed przetestowaniem całego kodu.

Tracisz możliwość napisania setek lub tysięcy linii kodu przed jego uruchomieniem.

Tracisz możliwość uczenia się przez debugowanie.

Tracisz elastyczność wysyłania kodu, którego nie jesteś pewien.

Tracisz swobodę ścisłego łączenia modułów.

Tracisz możliwość pominięcia pisania dokumentacji projektowej niskiego poziomu.

Tracisz stabilność, która pochodzi z kodem, który każdy boi się zmienić.

Tracisz tytuł "hakera".

Jeśli twoje testy nie są bardzo dokładne, możesz wpaść w fałszywe poczucie "wszystko działa"tylko dlatego, że testy przechodzą. Teoretycznie, jeśli twoje testy przebiegną pomyślnie, kod działa; ale gdybyśmy mogli napisać kod idealnie za pierwszym razem, nie potrzebowalibyśmy testów. Morał polega na tym, aby upewnić się, że sprawdzisz zdrowie psychiczne na własną rękę, zanim nazwiesz coś kompletnym, nie polegaj tylko na testach.

Jeśli twój test zdrowia psychicznego znajdzie coś, co nie jest testowane, upewnij się, że wrócisz i napisz do niego test.

Minusem TDD jest to, że zwykle jest ono ściśle związane z metodologią "Agile" , która przywiązuje nie wagę do dokumentacji systemu, a raczej zrozumienie, dlaczego test "powinien" zwrócić jedną konkretną wartość, a nie jakąkolwiek inną, leży tylko w głowie dewelopera.

Jak tylko programista odejdzie lub zapomni powód, dla którego test zwraca jedną konkretną wartość, a nie inną, masz przerąbane. TDD jest w porządku, jeśli jest odpowiednio udokumentowane i otoczony czytelnym dla człowieka (tj. pointy-haired manager) dokumentacja, do której można odnieść się w ciągu 5 lat, gdy świat się zmienia i Twoja aplikacja również tego potrzebuje.

Kiedy mówię o dokumentacji, to nie jest blurb w kodzie, to jest oficjalne pismo, które istnieje poza aplikacją, takie jak przypadki użycia i podstawowe informacje, do których mogą odwoływać się menedżerowie, prawnicy i biedny sap, który musi zaktualizować kod w 2011.

Spotkałem się z kilkoma sytuacjami, w których TDD doprowadza mnie do szału. Aby wymienić niektóre:

• Test case maintainability:

  Jeśli jesteś w dużym przedsiębiorstwie, wiele szans jest, że nie musisz pisać spraw testowych samodzielnie lub przynajmniej większość z nich jest pisana przez kogoś innego, gdy wejdziesz do firmy. Funkcje aplikacji zmieniają się od czasu do czasu, a jeśli nie masz systemu, takiego jak HP Quality Center, aby je śledzić, zmienisz się w nie czas.

  Oznacza to również, że nowi członkowie zespołu zajmą sporo czasu, aby zdobyć to, co dzieje się z przypadkami testowymi. Z kolei można to przełożyć na więcej potrzebnych pieniędzy.

• Złożoność automatyzacji testów:

  Jeśli zautomatyzujesz niektóre lub wszystkie przypadki testowe do skryptów testowych uruchamianych maszynowo, będziesz musiał upewnić się, że te skrypty testowe są zsynchronizowane z odpowiadającymi im przypadkami testowymi i zgodne ze zmianami aplikacji.

  Także, poświęcisz czas na debugowanie kodów, które pomogą Ci złapać błędy. Moim zdaniem większość z tych błędów pochodzi z braku odzwierciedlenia zmian aplikacji w skrypcie testów automatyzacji przez zespół testujący. Zmiany w logice biznesowej, GUI i innych wewnętrznych rzeczach mogą sprawić, że skrypty przestaną działać lub będą działać nieprawidłowo. Czasami zmiany są bardzo subtelne i trudne do wykrycia. Kiedyś wszystkie moje Skrypty zgłaszają awarię, ponieważ opierały swoje obliczenia na informacjach z tabeli 1, podczas gdy tabela 1 Była teraz tabela 2 (bo ktoś podmienił nazwę obiektów tabeli w kodzie aplikacji).

Największym problemem są ludzie, którzy nie wiedzą jak napisać odpowiednie testy jednostkowe. Piszą testy, które zależą od siebie (i świetnie działają z Ant, ale potem nagle zawodzą, gdy uruchamiam je z Eclipse, tylko dlatego, że działają w innej kolejności). Piszą testy, które nie testują niczego konkretnego - po prostu debugują kod, sprawdzają wynik i zmieniają go na test, nazywając go "test1". Poszerzają zakres zajęć i metod, tylko dlatego, że łatwiej będzie napisz dla nich testy jednostkowe. Kod testów jednostkowych jest okropny, ze wszystkimi klasycznymi problemami programistycznymi (ciężkie sprzężenie, metody o długości 500 linii, ciężko zakodowane wartości, duplikacja kodu) i jest piekłem do utrzymania. Z jakiegoś dziwnego powodu ludzie traktują testy jednostkowe jako coś gorszego od" prawdziwego " kodu i w ogóle nie dbają o ich jakość. :-(

Tracisz dużo czasu na pisanie testów. Oczywiście może to zostać zapisane do końca projektu przez szybsze łapanie błędów.

Największym minusem jest to, że jeśli naprawdę chcesz zrobić TDD prawidłowo, będziesz musiał dużo zawieść, zanim odniesiesz sukces. Biorąc pod uwagę, ile firm programistycznych pracuje (Dolar za KLOC), w końcu zostaniesz zwolniony. Nawet jeśli twój kod jest szybszy, czystszy, łatwiejszy w utrzymaniu i ma mniej błędów.

Jeśli pracujesz w firmie, która płaci Ci przez KLOCs (lub wymagania wdrożone -- nawet jeśli nie testowane) trzymaj się z dala od TDD (lub recenzji kodu, programowania par, ciągłej integracji itp. itd. itd.).

Popieram odpowiedź na temat początkowego czasu rozwoju. Tracisz również możliwość komfortowej pracy bez bezpieczeństwa testów. Opisywano mnie też jako nutbara TDD, więc można stracić kilku znajomych;)

Ponowne skoncentrowanie się na trudnych, nieprzewidzianych wymaganiach jest stałą zmorą programisty. Rozwój oparty na testach zmusza cię do skupienia się na już znanych, przyziemnych wymaganiach i ogranicza twój rozwój do tego, co już sobie wyobrażałeś.

Pomyśl o tym, prawdopodobnie skończysz projektując do konkretnych przypadków testowych, więc nie będziesz kreatywny i zaczniesz myśleć "byłoby fajnie, gdyby użytkownik mógł zrobić X, Y i z". Dlatego, kiedy ten użytkownik zaczyna się ekscytować potencjalne fajne wymagania X, Y i Z, twój projekt może być zbyt sztywno skoncentrowany na już określonych przypadkach testowych i będzie trudny do dostosowania.

To oczywiście miecz obosieczny. Jeśli spędzasz cały swój czas na projektowaniu każdego możliwego, możliwego do wyobrażenia, X, Y i Z, którego użytkownik może kiedykolwiek chcieć, nieuchronnie nigdy niczego nie ukończysz. Jeśli coś zrobisz, nikt (w tym ty sam) nie będzie mógł mieć pojęcia, co robisz w swoim kod/projekt.

Jest percived jako wolniejszy. Na dłuższą metę nie jest to prawdą, jeśli chodzi o smutek, który pozwoli Ci zaoszczędzić na drodze, ale skończysz pisząc więcej kodu, więc prawdopodobnie spędzasz czas na "testowaniu, a nie kodowaniu". To błędny argument, ale pytałeś!

Pisanie testów dla "losowych" danych, takich jak kanały XML i bazy danych może być trudne i czasochłonne (nie takie trudne). Spędziłem ostatnio trochę czasu pracując z danymi pogodowymi. To dość mylące pisanie testów do tego, przynajmniej nie mam zbyt dużego doświadczenia z TDD.

Stracisz duże klasy z wieloma obowiązkami. Prawdopodobnie stracisz również duże metody z wieloma obowiązkami. Możesz stracić pewną zdolność do refaktoryzacji, ale stracisz również część konieczności refaktoryzacji.

Jason Cohen powiedział coś w stylu: TDD wymaga określonej organizacji dla Twojego kodu. Może to być architektonicznie błędne; na przykład, ponieważ metody prywatne nie mogą być wywoływane poza klasą, musisz uczynić metody nie-prywatnymi, aby je utworzyć testowalny.

Mówię, że to wskazuje na brak abstrakcji -- jeśli prywatny kod naprawdę musi być przetestowany, powinien być prawdopodobnie w osobnej klasie.

Dave Mann

Musisz pisać aplikacje w inny sposób: taki, który czyni je testowalnymi. Zdziwiłbyś się, jak trudne to jest na początku.

Niektórzy uważają, że myślenie o tym, co napiszą, zanim to napiszą, jest zbyt trudne. Pojęcia takie jak wyśmiewanie mogą być trudne dla niektórych zbyt. TDD w starszych aplikacjach może być bardzo trudne, jeśli nie zostały zaprojektowane do testowania. TDD wokół frameworków, które nie są przyjazne TDD, może być również walką.

TDD to umiejętność więc młodsi deweloperzy mogą początkowo walczyć (głównie dlatego, że nie zostali nauczeni, aby pracować w ten sposób).

Ogólnie rzecz biorąc, wady zostają rozwiązane, gdy ludzie stają się wykwalifikowani, a ty w końcu abstrakujesz "śmierdzący" kod i masz bardziej stabilny system.

Potrzeba trochę czasu, aby się w to zaangażować, a trochę czasu, aby zacząć to robić w projekcie, ale... Zawsze żałuję, że nie robię podejścia testowego, gdy znajduję głupie błędy, które zautomatyzowany test mógł znaleźć bardzo szybko. Ponadto TDD poprawia jakość kodu.

• testy jednostkowe to więcej kodu do napisania, a tym samym wyższy koszt opracowania
• jest to bardziej kod do utrzymania
• wymagana dodatkowa Nauka

Dobre odpowiedzi wszystkie. Dodałbym kilka sposobów na uniknięcie ciemnej strony TDD:

• Pisałem aplikacje do samodzielnego randomizowanego testu. Problem z pisaniem konkretnych testów polega na tym, że nawet jeśli piszesz wiele z nich, obejmują one tylko przypadki, o których myślisz. Generatory testów losowych znajdują problemy, o których nie pomyślałeś.

• Cała koncepcja wielu testów jednostkowych zakłada, że masz komponenty, które mogą dostać się do nieprawidłowych stanów, takich jak złożone struktury danych. If you stay z dala od złożonych struktur danych jest o wiele mniej do przetestowania.

• W zakresie, w jakim pozwala na to Twoja aplikacja, wstydź się projektowania, który opiera się na właściwej kolejności powiadomień, zdarzeń i efektów ubocznych. Te mogą łatwo zostać upuszczone lub jajeczkowane, więc wymagają wielu testów.

TDD wymaga pewnej organizacji dla Twojego kodu. Może to być nieefektywne lub trudne do odczytania. Na przykład, ponieważ metody private nie mogą być wywoływane poza klasą, musisz uczynić metody nieprywatnymi, aby mogły być testowane, co jest po prostu złe.

Gdy Kod się zmienia, musisz również zmienić testy. Przy refaktoryzacji może to być dużo dodatkowej pracy.

Dodam, że jeśli zastosujesz Zasady BDD do projektu TDD, możesz złagodzić kilka głównych wad wymienionych tutaj (zamieszanie, nieporozumienia itp.). Jeśli nie jesteś zaznajomiony z BDD, powinieneś przeczytać wprowadzenie dana Northa. Wymyślił tę koncepcję w odpowiedzi na niektóre problemy wynikające z zastosowania TDD w miejscu pracy. Intro Dana do BDD można znaleźć tutaj.

Sugeruję to tylko dlatego, że BDD odnosi się do niektórych z tych negatywów i działa jako gap-stop. Warto wziąć to pod uwagę podczas zbierania opinii.

Musisz upewnić się, że twoje testy są zawsze aktualne, moment, w którym zaczniesz ignorować czerwone światła, jest momentem, w którym testy stają się bezsensowne.

Musisz również upewnić się, że testy są wyczerpujące, lub w momencie pojawienia się dużego błędu, duszny typ zarządzania, który w końcu przekonałeś, aby pozwolić ci poświęcić czas na pisanie więcej kodu, będzie narzekał.

Osoba, która nauczyła mojego zespołu agile development nie wierzyła w planowanie, napisałeś tylko tyle dla najmniejszych wymagań.

Jego motto brzmiało refactor, refactor, refactor. Zrozumiałem, że refactor oznacza "nie planować z wyprzedzeniem".

Czas rozwoju wzrasta: każda metoda wymaga testowania, a jeśli masz dużą aplikację z zależnościami, musisz przygotować i wyczyścić dane do testów.