Wpis z mikrobloga

@sucharixx: proponuję zacząć od napisania testów, a potem "poprawiać" kod aż zacznie działać, na a koniec posprzątać i upewnić się że testy dalej działają, 30 minut ze zrobieniem kawy i siku
@PaaD: > proponuję zacząć od napisania testów, a potem "poprawiać" kod aż zacznie działać, na a koniec posprzątać i upewnić się że testy dalej działają,

Świetna recepta na napisanie gównianego kodu, ewentualnie zmarnowanie czasu na pisanie gównianego kodu i potem pisanie go jeszcze raz tym razem dobrze.
recepta na napisanie gównianego kodu


@Krolik: xd, przecież to był opis TDD (red - green - refactor), tyle że w pigułce na poziomie wymagań tego zadania ¯\_(ツ)_/¯

dobra kultura w konstruktywnej dyskusji wymagałaby, abyś po tym wstępie napisał co proponujesz co mogłoby się sprawdzić lepiej w tej sytuacji
@PaaD:

xd, przecież to był opis TDD (red - green - refactor), tyle że w pigułce na poziomie wymagań tego zadania


Ależ oczywiście. Właśnie to miałem na myśli.

abyś po tym wstępie napisał co proponujesz co mogłoby się sprawdzić lepiej w tej sytuacji


0. znaleźć czy biblioteki używane w projekcie już takiej funkcji nie mają, ale jeśli nie to...
1. zaprojektować algorytm
2. zaimplementować

Napisanie testów czy przed czy po implementacji
@PaaD:

Tu masz ładnie opisane czym się kończy stosowanie TDD w praktyce.
Nawet nie możesz napisać, że gościu stosował TDD źle, bo to pisał sam autor TDD:

http://xprogramming.com/articles/sudokumusings/
http://xprogramming.com/articles/oksudoku/
http://xprogramming.com/articles/sudoku2
http://xprogramming.com/articles/sudoku4
http://xprogramming.com/articles/sudoku5

A tu masz jak to się powinno robić czyli tzw. "pure old engineering":
http://norvig.com/sudoku.html

Jak się komuś nie chce czytać - Jeffreys przez kilka artykułów bezskutecznie próbuje napisać solver sudoku stosując TDD. Ostatecznie produkuje kupę kodu (literalnie kupę, tzn
@Krolik:

Z wnioskami z tego eksperymentu oczywiście się zgodzę: TDD nie jest czarodziejską sztuczką i nie zastępuję myślenia. A projektowanie algorytmów (jak każde inne projektowanie) oczywiście wymaga myślenia i całościowego postrzegania problemów. (Nawiasem mówiąc całościowe spojrzenie nie wykluczałoby to wytworzenia jakiś narzędziowych fragmentów kodu inkrementacyjnie).

Do kolekcji:
- podobna krótsza historyjka Wujka Boba:
https://web.archive.org/web/20071114000849/http://programming.reddit.com/info/1kth0/comments/c1lkvh
- i wkład Vlada L w dyskusję odnośnie TDD w algorytmach:
https://web.archive.org/web/20201109033939/http://vladimirlevin.blogspot.com/2009/09/spy-vs-spy.html (szkoda, że oryginalny blog spadł
@PaaD: Ja się nie czepiam testów, bo testy powinny być, zwłaszcza do czegoś nietrywialnego lub do czegoś co bardzo łatwo przetestować. I testy są bardzo ważne i mają olbrzymią wartość.

Czepiam się za to podejścia kodowania na zasadzie TDD - czyli permutuję kod aż przejdzie wszystkie testy. Takie podejście często prowadzi do patologicznej ifologii w kodzie - czyli na każdy przypadek testowy masz potem w kodzie jakiegoś ifa.

Mam takiego kumpla