Aktywne Wpisy
Itslilianka +32
Jadę oglądać moje wymarzone auto z czasów dzieciństwa. (。◕‿‿◕。) Na co zwracać uwagę? Nie mogę się doczekać aż usiądę za kółkiem #motoryzacja
rybsonk +13
Śmiesznie, że jest tak dużo nazw które nijak się nie mają do opisywanych rzeczy.
- świnka morska nie ma nic wspólnego z morzem ani ze świniami
- para spodni to jedna sztuka, miałoby sens mówienie "para nogawek"
- ciepły azot jest tak naprawdę bardzo zimny
- Gorzów Wielkopolski nie leży tak naprawdę w Wielkopolsce
Znacie inne przykłady?
#gryparatowaniapoziomu #ciekawostki #geografia #chemia #zwierzaczki
- świnka morska nie ma nic wspólnego z morzem ani ze świniami
- para spodni to jedna sztuka, miałoby sens mówienie "para nogawek"
- ciepły azot jest tak naprawdę bardzo zimny
- Gorzów Wielkopolski nie leży tak naprawdę w Wielkopolsce
Znacie inne przykłady?
#gryparatowaniapoziomu #ciekawostki #geografia #chemia #zwierzaczki
IBMTest -> IBM Test
EloMordo -> Elo Mordo
ZZTest -> ZZ Test
#programowanie #java
Wygląda tu na:
1) Jeśli poprzedni znak jest "wielką" kolejny "wielką" i a jeszcze następny małą,
2) Poprzedni jest małą, kolejny wielką.
Komentarz usunięty przez autora
'IBMTest'.replace(/((?<=[a-z])[A-Z]|[A-Z](?=[a-z])/g, " $1").trim()
Komentarz usunięty przez autora
Świetna recepta na napisanie gównianego kodu, ewentualnie zmarnowanie czasu na pisanie gównianego kodu i potem pisanie go jeszcze raz tym razem dobrze.
@filip_k: i 20 stron dokumentacji ( ͡° ͜ʖ ͡°)
@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
Ależ oczywiście. Właśnie to miałem na myśli.
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
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
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ł
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