Przejdź do głównej zawartości

Wymówki

Podobieństwa pomiędzy regułą podwójnego zapisu a Test-Driven Development są głębokie i jest ich dużo.
  • Obie są dyscyplinami używanymi przez ekspertów, którzy ostrożnie manipulują złożonymi dokumentami pełnymi tajemnych symboli, które muszą być pod groźbą okropnych konsekwencji, poprawne co do typu i położenia.
  • Obie obejmują reprezentację długich ciągów podstawowych ruchów w dwóch różnych formach i na dwóch różnych dokumentach.
  • Obie techniki aktualizują swoje dokumenty jednym podstawowym ruchem w jednym miejscu na raz i każda taka aktualizacja kończy się weryfikacją upewniającą się czy te dwa dokumenty pozostają w zgodności ze sobą.

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


Ubierając to w bardziej konkretne definicje:
  • Księgowi wprowadzają transakcje do dwóch różnych kont. Jedno to konto Zobowiązania. Drugie to konto Aktywa lub Udziały. Te konta są sumowane w bilansie i następująca zależność musi być spełniona: Aktywa + Udziały = Zobowiązania.
  • Księgowi są uczeni księgować jedną transakcję na raz, sprawdzając bilans po każdej takiej operacji.
  • Programiści, którzy praktykują TDD wprowadzają podstawowe jednostki zachowania w dwa różne programy. Jeden w program testowy. Drugi w pożądany program produkcyjny. Te dwa powinny być wykonywane w natychmiastowy sposób pokazując czy produkcyjny kod działa tak, jak go opisuje testowy kod.
  • Programiści są uczeni dodawać tylko jedną podstawową jednostkę na raz do każdego z programów i uruchamiać testy po każdym takim dodaniu.
Tak jak powiedziałem, równoważność pomiędzy tymi dwiema dyscyplinami jest wyraźna. One mają w zasadzie identyczne podejście.
I nic dziwnego. Obie dyscypliny służą temu samemu celowi. Obie pozwalają tym z nas, którzy ostrożnie manipulują złożonymi dokumentami pełnymi tajemnych symboli, które muszą być poprawne pod groźbą okropnych konsekwencji, być pewnym, że te konsekwencje ich nie spotkają.

Czy księgowi mają deadline'y? Czy menedżerowie naciskają na nich aby skończyli swoje księgowanie do konkretnej daty? Oczywiście! Nie ma różnicy w temacie ciśnienia. Księgowi czują presję tak samo jak czują ją programiści.
Czy programy programistów są w jakiś sposób mniej ważne od kont księgowych? Oczywiście, że nie! Te programy są instrumentami, które pozwalają zarabiać albo oszczędzać pieniądze przedsiębiorstwa. One są krytycznie ważne. Po prostu są tak ważne, jak konta księgowych.
Więc dlaczego księgowi potrafią trzymać się swojej dyscypliny tak wytrwale i tak całkowicie? Czy potrafisz wyobrazić sobie grupę księgowych rozmawiających między sobą: "Chłopaki, jesteśmy pod ścianą. Musimy skończyć te konta do Piątku. Więc róbcie wszystkie Aktywa i Udziały. Wrócimy do tego i zrobimy Zobowiązania później."
Nie. Nie możesz sobie tego wyobrazić. No i przynajmniej nie powinieneś. Księgowi mogą iść do więzienia za takie rzeczy.
No więc jak to jest, że tak dużo programistów jęczy i stęka skonfrontowana z dyscypliną TDD? Dlaczego pokazują tak wiele powodów, że TDD jest niepraktyczne, albo bezsensowne, albo...

Czy potrafisz sobie wyobrazić księgowego robiącego wymówki takie jak:(Wszystko wzięte z artykułów o TDD)
  • Nigdy nie stosuję reguły podwójnego zapisu, ponieważ śledzenie tych wszystkich kont zabiera zbyt wiele czasu.
  • Konta nie muszą być perfekcyjne, one muszą być tylko wystarczająco dobre. Reguła podwójnego zapisu to przesada.
  • Wszyscy Ci księgowi, którzy praktykują regułę podwójnego zapisu są po prostu zbyt fanatyczni. Podążają za niepotrzebnym dogmatem.
  • Balansowanie Aktywów i Udziałów z Zobowiązaniami w zasadzie nie dowodzi, że konta są poprawne. Więc reguła podwójnego zapisu jest zbyt dużą pracą za zbyt mały zysk.
  • Reguła podwójnego zapisu to brednie promowane przez konsultantów, którzy chcą po prostu zarobić pieniądze sprzedając książki, kursy i filmy.
  • Reguła podwójnego zapisu jest martwa. Kolesie z Andersen Consulting napisali o tym na blogu.
  • Jestem przeciwko regule podwójnego, ponieważ doświadczenie pokazuje, że zapobiega ona pojawianiu się wysokiej jakości designu kont.
  • Kiedy pierwszy raz usłyszałem o regule podwójnego pomyślałem, że to jakiś wymyślny żart. To jest strasznie durne.
  • Reguła podwójnego nie działa. Nie obchodzi mnie, co słyszałeś. Nie obchodzi mnie jak bardzo Twój menedżer chce ją wprowadzić. Nie obchodzi mnie jak bardzo rozpromienione oczy Twoich współpracowników lśnią w jej blasku. Ona. Nie. Działa.
  • Reguła podwójnego promuje psucie designu kont.
  • Nie wszystko da się zaksięgować.
  • Reguła podwójnego blokuje design konta.
  • Reguła podwójnego brzmi dobrze w teorii. W praktyce jednak, nie jest jasne jak jest dobra.
  • Życie jest krótkie i ma tylko skończoną liczbę godzin na dobę. Musimy więc dokonywać wyborów, w jaki sposób spędzimy nasz czas. Jeżeli spędzamy go robiąc podwójne zapisy to w tym czasie nie robimy nic innego.
  • Użycie podwójnego zapisu nie gwarantuje Ci dobrego designu kont.
  • Postawię wszystko na jedną kartę i powiem z brutalną szczerością, że to dosłownie zwyczajna strata czasu.
  • Kolejną kwestią jest dyskusyjny poziom doskonałości, do którego musi dążyć ten, który chce robić regułę podwójnego dobrze. Niektórzy upierają się, że jeżeli podwójny zapis nie jest wytrwale robiony przez wszystkich w zespole od początku to zespół ten będzie tylko cierpieć.
  • Podwójny zapis jedzie się na poczuciu winy. Bardziej zachęca do procedur niż do zrozumienia. Nosi z sobą tony doktryn i sloganów.
  • Dla mnie, fanatycy podwójnego zapisu są religijnymi wariatami pukającymi do moich drzwi aby udowodnić, że mój sposób pracy jest nieodwracalnie zepsuty i jedyną drogą do zbawienia jest podwójny zapis.
  • To, co wkurza mnie w regule podwójnego, to fakt, że zawiera w sobie mnóstwo zasad lub wytycznych.
  • W Twoim pierwszym projekcie z regułą podwójnego ponosisz dwie wielkie straty, czas i osobistą wolność.
Mógłbym tak w kółko. (I w kółko. I w kółko.) Jak możesz zauważyć nie brakuje głupiutkich, niedoinformowanych i niezadowolonych krytyków.
Dla mnie podsumowanie jest proste. TDD jest dobrą dyscypliną do upewniania się, że złożone dokumenty, pełne tajemnych symboli, są tworzone w sposób pozwalający uniknąć znaczących, negatywnych konsekwencji. Nie znam żadnej innej dyscypliny, która choć zbliża się do tego.
Reguła podwójnego zapisu była wynaleziona przez Koreańczyków ponad tysiąc lat temu. Była niezależnie wynaleziona ponownie przez Włochów ponad sześćset lat temu. Rozkwitła i rozniosła się razem z kapitalistycznym i ekonomicznym dobrobytem zapewniając mu bezpieczeństwo. Jednak jej adopcja nie obyła się bez oporów i opóźnień. Ostatnie państwa, które ustandaryzowały regułę podwójnego zapisu zrobiły to w wieku dwudziestym.
Miejmy nadzieję, że nie potrwa to 500 lat, zanim dyscyplina testowania stanie się standardem dla programistów.


Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.

Komentarze

Popularne posty z tego bloga

Kursy IT na Pluralsight. Dlaczego warto?

Bardzo sobie cenię kursy na Pluralsight. Mam wrażenie, że każdy kurs, który przeszedłem na tej platformie, w dużym stopniu podniósł moje zdolności. Wiem, dostęp do tej platformy nie jest tani, ale w mojej ocenie warty swojej ceny. To nie jest reklama, ale forma entuzjazmu jaki mam do tej formy samodoskonalenia. O to kilka punktów pokazujących ofertę tego serwisu i dlaczego warto skorzystać: Pluralsight to kursy z Javascript, C#, Java, Angular, Python, MySQL i wielu innych technologii i umiejętności. Kursy na Pluralsight w większości mają wyższą jakość niż te, które możemy znaleźć na przykład na YouTube. Są wyselekcjonowane, mają wysoką jakość dźwięku i obrazu. Często wgryzają się głęboko w dany problem daleko poza standardowe „Hello World” danej technologii. Twórcy Pluralsight to często osoby znane ze świata IT i konferencji branżowych, jak: Scott Hanselman, Microsoft John Somnez, SimpleProgrammer.com John Skeet, Google Pluralsight udostępnia funkcjonalność ścieżek – paths....

Bicie piany

Czy słyszałeś o tym gościu, który powiedział, że Object Oriented to przeżytek? No nie. Następny. Co powiedział? Opisał wszystkie obietnice OO, i jak żadna z nich tak naprawdę nigdy nie została spełniona i o tych wszystkich możliwościach OO, które kosztują więcej, niż są warte i że funkcjonalne programowanie jest lepsze i ... Phi. Tak słyszałem już to wcześniej. No, więc OO jest martwe, leży i kwiczy i możemy przejść dalej. Przejść dalej do czego? Co? No do NASTĘPNEJ WIELKIEJ RZECZY oczywiście. Aaaa, do tego. Czy wiesz już co to jest? Nie bałdzo, ale jestem podekscytowany na myśl o mikroserwisach; jaram się Elixirem; i słyszałem, że React jest fantastyczny; i ... Tak, tak. Bicie piany. Dałeś się nabrać na bicie piany. Co? Co masz na myśli. Przecież mamy takie wspaniałe czasy. Tak naprawdę postrzegam te czasy jako depresyjne. Ale dlaczego? Przecież co kilka dni wyskakują nowe wspaniałe technologie! Wspinamy się na coraz wyższe szczyty. Phi. To, co tak napraw...

Podstawy Programowania Funkcyjnego Epizod 1

O czym jest programowanie funkcyjne? Zakładam, że słyszałeś już kiedyś o programowaniu funkcyjnym. No cóż, któż nie słyszał? Wszyscy o tym gadają. Wychodzi dużo nowych języków funkcyjnych takich, jak Scala, F# i Clojure. Ludzie rozmawiają też o starszych językach jak Erlang, Haskell, ML i innych. A więc, o co w tym wszystkim chodzi? Dlaczego programowanie funkcyjne jest Następną Wielką Rzeczą™? I co jest w tym takiego pociągającego? Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina z dnia 22 grudnia 2012 ze strony: https://blog.cleancoder.com/uncle-bob/2012/12/22/FPBE1-Whats-it-all-about.html Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta. Po pierwsze, prawie na pewno programowanie funkcyjne jest następną wielką rzeczą. Są ku temu dobre, solidne powody i poznamy je w tym artykule. Ale najpierw, aby zrozumieć te powody, musimy poznać, czym programowanie funkcyjne jest....