tag:blogger.com,1999:blog-5197374494377847819.post7710581723947577355..comments2024-03-22T22:13:46.650+01:00Comments on Holistycznie o inżynierii oprogramowania: Czysty kod to przetestowany kod?Sławek Sobótkahttp://www.blogger.com/profile/15082577671795313109noreply@blogger.comBlogger22125tag:blogger.com,1999:blog-5197374494377847819.post-61692668850548838852014-01-21T23:02:35.581+01:002014-01-21T23:02:35.581+01:00Dziękuję za radę.
Post ma ponad 4 lata, w tym cza...Dziękuję za radę.<br /><br />Post ma ponad 4 lata, w tym czasie niezależnie wpadłem na to aby zapoznać się z polecaną książką:P<br /><br />Nie chcę wracać do tematu, to już zeszłoroczny śnieg dla mnie jaki i na pewno dla Wujka - bo sam sprostował już kilka rzeczy, więc dla mnie to przeszłość, która rozpierzchła się w chaos wszechświata:)Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-7318824430266919122014-01-21T11:16:13.190+01:002014-01-21T11:16:13.190+01:00Jest całkiem kompetentne źródło przekazjujące info...Jest całkiem kompetentne źródło przekazjujące informację na temat tego co Robert C. Martin uważa za czysty kod i jak go uzyskać. Szybka, dobra i znacznie lepsza lektóra niż blog czy artykuł. Książka pt. "Clean Code", dostępna również w tłumaczeniu na Polski. Plecam lektórę zanim zacznie się wypowiadać w kontekście "co autor miał na myśli".<br /><br />Rafałnoreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-21555626614060281052009-11-14T22:48:56.127+01:002009-11-14T22:48:56.127+01:00Dziękuję wszystkim, którzy w ciągu tygodnia wyrazi...Dziękuję wszystkim, którzy w ciągu tygodnia wyrazili swoje opinie i podzieli się doświadczeniem.<br /><br />Cieszę się, że udało mi się sprowokować kilkanaście osób do dyskusji na na prawdę ważne tematy (zamiast wklejać hello world w kolejnym frameworku webowym).<br /><br />Cieszę się, że udało się nam zachować *racjonalne* podejście i uniknąć dziecinnej przepychanki w stylu czyj system operacyjny jest fajniejszy. Dyskutujemy przecież dla własnego dobra i we własnym interesie.<br /><br />@Rafał: Jutro sprawdzę czy aby na pewno bliżej mi do niejakiego Jima;PSławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-34939983596373931842009-11-14T18:51:35.886+01:002009-11-14T18:51:35.886+01:00link jest tutaj... http://www.infoq.com/interviews...link jest tutaj... http://www.infoq.com/interviews/coplien-martin-tddRafał Jamrózhttps://www.blogger.com/profile/04142472085473198015noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-20128349672215892582009-11-14T18:50:30.691+01:002009-11-14T18:50:30.691+01:00Mocno polecam wywiad Boba Martina z Jimem Copliene...Mocno polecam wywiad Boba Martina z Jimem Coplienem (czyli nie byle kto). Panowie przedstawiaja 2 poprawne spojrzenia na TDD. ("TDD to glupota, a wiem to z tad ze wszystkie moje testy sa integracyjne" nie uwazam za sensowna) Mysle ze Slawku masz blizej do Jima :) . <br /><br />Mimo odmiennego zdania obu Panow, dochodza do bardzo ciekawego wniosku mianowicie: "Jezeli programista chce sie uwazac za profesjonaliste musi przetestowac swoj kod (najlepiej jednostkowo)". Jest to oczywiscie warunek wymagany lecz nie wystarczajacy. Natomiast drugim wnioskiem jest: "dobrym sposobow na osiagniecie tego jest wlasnie TDD".Rafał Jamrózhttps://www.blogger.com/profile/04142472085473198015noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-49954095422597553132009-11-14T10:59:49.802+01:002009-11-14T10:59:49.802+01:00@Łukasz - dzięki za tego linka. Potwierdzam, że mn...@Łukasz - dzięki za tego linka. Potwierdzam, że mniej więcej to chciałem wyrazić. <br /><br />Mam nadzieję, że ten tekst wyda się certyfikowanym ekspertom bardziej "sensowny" niż moje skromne wynurzenia;PSławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-77080901904922472522009-11-14T10:39:49.083+01:002009-11-14T10:39:49.083+01:00Tak na podsumowanie tego wpisu, to co Sławek próbo...Tak na podsumowanie tego wpisu, to co Sławek próbował przekazać, opisał sam wujek Bob tutaj -> http://blog.objectmentor.com/articles/2009/10/08/tdd-triageŁukasz Lenarthttps://www.blogger.com/profile/16282501546640140356noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-88402276891057363652009-11-13T23:01:32.698+01:002009-11-13T23:01:32.698+01:00Ten komentarz został usunięty przez autora.Sławek Chmielhttps://www.blogger.com/profile/16793151584038902431noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-90956002409693100792009-11-13T17:16:26.716+01:002009-11-13T17:16:26.716+01:00@Krzystof - dzięki za link do artykułu. To co pisz...@Krzystof - dzięki za link do artykułu. To co piszesz odnośnie technik bez których nie da się robić TDD jest tym co chciałem wyrazić w tym poście. <br /><br />Widzę, że się zgadzamy, jednak na co ja chciałem zwrócić uwagę: nie da się osiągnąć dobrej jakości kodu bez solidnego warsztatu. I jak sam podkreślasz nie są wówczas sensownie zaaplikować TDD.<br /><br />Być może źle się wyraziłem pisząc o TDD jako o "dodatku" i stąd nieporozumienie. Chodzi mi po prostu o to, że NAJPIERW uczmy porządnego OO, później na tej bazie można mówić o kodzie podatnym na testy. Czyli może nie dodatek a etap drugi. Bo jak pisać kod o wysokim testability jeżeli jedyne techniki jakie zna team to np proceduralne podejście?<br /><br />@Paweł<br />Dziękuję za uznanie dla mego miernego poczucia humoru. Dziękują również za korektę mojego kiepskiego angielskiego - z tym mam problemy od dziecka.<br /><br />Odnośnie wpływu różnych ograniczeń (np TDD, ale nie tylko) na to czy programiści stworzą kod będący kupą... błota to jednak nie doceniasz kreatywności.<br /><br />W poście chodziło mi o to abyś zadał sobie pytanie o PIERWOTNĄ przyczynę tego, że Twój kod jest wysokiej jakości:<br />a) Twój skil projektowy i praktyczna znajomość technik dev oraz to, że je sensownie zastosowałeś<br />b) Obecność testów jednostkowych<br /><br />Piszesz o "safety net". Zgadzam się: lokalne błędne modyfikacje będą wyłapane przez testy jednostkowe, ale "rozpierducha" o szerszym zakresie to już raczej integracyjne.Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-74511459411373523832009-11-13T15:53:52.732+01:002009-11-13T15:53:52.732+01:00Hej
Z tego co piszesz, widać, że nigdy nie próbowa...Hej<br />Z tego co piszesz, widać, że nigdy nie próbowałeś TDD. Nawet samej idei dobrze nie zrozumiałeś. Co więcej, nie wiele zrozumiałeś też z przekazu Uncle Boba.<br /><br />Podstawowe twoje założenie w tym poście - przeciwstawienie pisania testów myśleniu ("Czysty kod, aby powstał musi być wypracowany poprzez pewien wysiłek umysłowy. Nie wystarczy dorwać się do klawiatury i radośnie stukać.") - jest z gruntu błędne i wszystko co dalej piszesz po prostu jest bez sensu. <br /><br />Czysty kod to kod czytelny. To jak powstanie nie ma znaczenia - ważna jest czytelność. A przypadkiem akurat TDD bardzo pomaga przy tworzeniu czytelnego kodu - myślenie przykładami jego wykorzystania; testowanie małych fragmentów "wymusza" małe metody realizujące choćby SRP. <br /><br />Ale nie wykluczam, że są osoby o wysokiej intuicji i "inteligencji programistycznej" będące w stanie pisać taki kod po chwili zastanowienia. Może tak być.<br />Jednak odrzucając TDD pozbawiasz się tego co Uncle Bob nazywa "safety net". Kod z testami to kod pewny. Nie boisz się go modyfikować, bo wiesz, że nawet jeśli coś Ci nie pójdzie, to testy natychmiast to wykryją.<br /><br />Posiadanie dobrego pokrycia kodu testami jest więc kluczowe z punktu widzenia tworzenia utrzymywalnych/modyfikowalnych aplikacji.<br /><br />Co do SOLID, projektowania i TDD to już Krzysiek napisał - nie da się po prostu zrobić "kupy" używając TDD, bo nie byłbyś w stanie pisać do niej kolejnych testów. Po tygodniu przestałbyś pisać nowe.<br /><br />Podsumowując - w mojej ocenie napisałeś względnie śmiesznym językiem parę głupot. Zanim więc skrytykujesz jakąś ideę, spróbuj ją postosować przez jakiś czas. <br />Jestem przekonany, że trzy miesiące pisania z użyciem TDD uczyni z Ciebie dużo lepszego programistę i pozwoli Ci zdobyć nowe doświadczenia.<br /><br />PS. angielski czasownik "specyfikować" ma na końcu "y" a nie "i"Paweł Lipińskihttps://www.blogger.com/profile/02772675014904905654noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-90317268217615602492009-11-13T15:36:06.147+01:002009-11-13T15:36:06.147+01:00"Konkludując: TDD ew. jako dodatek na drodze ..."Konkludując: TDD ew. jako dodatek na drodze do Clen Code wujaszku;P"<br /><br />No właśnie, wydaje się, że Uncle Bob mysli o tym zupełnie inaczej. Np. <a href="http://blog.objectmentor.com/articles/2009/11/11/archeological-dig" rel="nofollow">ostatnio napisał</a>: "That makes me think that TDD was the true catalyst of change, and the bridge that conveyed our industry from then to now."<br /><br />Dlaczego tak pisze? Udało się w mojej pracy zawodowej tworzyć kilka dużych systemów stosując TDD. Moje doświadczenie jest takie, że nie da się stosować TDD bez tego wszystkiego, co wymieniasz jako niezbędne dla tworzenia czystego kodu (SOLID, wzorce, IoC...). Tzn. że jeśli zespół zaczyna pracować w ten sposób, to albo musi szybko nadrobić zaległości w OOD, albo dość szybko przestanie pisać testy i nabierze przekonania o tym, że TDD nie działa. Stworzenie dużego systemu, który będzie miał bliskie 100% pokrycie testami, a jednocześnie będzie wielką kupą jest bliskie niemożliwości - utrzymanie testów będzie zbyt bolało.<br /><br />Zatem TDD promuje, albo niemal wymusza pisanie czystego kodu. Absolutnie nie zgadzam się ze spojrzeniem na TDD jako na dodatek.<br /><br />Zachęcam do tego, abyś spróbował zastosować TDD w dużym projekcie. Przekonasz się, jak bardzo wpływa to na sposób pracy, myślenia o architekturze, designie i o kodzie. Jeśli znasz i stosujesz to wszystko, o czym piszesz w kontekście czystego kodu, powinno Ci to przyjść dość łatwo. Choć i tak jestem przekonany, że TDD sprawi, że pójdziesz jeszcze dalej i nauczysz się pisać jeszcze lepszy i przejrzystszy kod.Krzysztof Jelskihttps://www.blogger.com/profile/13328086479988072905noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-13681424049670361072009-11-13T12:15:34.229+01:002009-11-13T12:15:34.229+01:00"Unit Testy można pisać, gdy wiadmomo, jaka m..."Unit Testy można pisać, gdy wiadmomo, jaka ma być wyjście funkcji na dany zestaw wejść."<br /><br />Zycze powodzenia programistom ktorzy proboja cokolwiek implementowac nie wiedzac jak ich funkcja ma sie zachowac NAWET dla przykladowego zestawu danych...Rafał Jamrózhttps://www.blogger.com/profile/04142472085473198015noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-3646502576917629792009-11-12T13:54:38.087+01:002009-11-12T13:54:38.087+01:00Co do dyskusji na temat stosować/nie stosować to w...Co do dyskusji na temat stosować/nie stosować to wszystko zależy od cech osobniczych - w szczególności od metaprogramów kognitywnych.<br /><br />http://www.racjonalista.pl/kk.php/s,4588/q,Preferowane.style.myslenia..metaprogramy<br /><br />Zwróćcie uwagę na programy unikanie/możliwości oraz ew. ogólny/szczegółowy. Problem w tym, że team jest różnorodny...<br /><br />Z uwagi na zależność od osobowości lepiej unikać tego typu dyskusji ponieważ nikogo nigdzie nie doprowadzi. Dlatego też podjąłem problem Craftsmanship jako takiego - czyli z czego powinna składać się nasza profesja oraz dlaczego nikt nie podejmuje trudnych problemów?Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-2312585378818300782009-11-12T11:58:59.092+01:002009-11-12T11:58:59.092+01:00@Janusz - w przekazie Wuja chodzi o TDD, a nie o s...@Janusz - w przekazie Wuja chodzi o TDD, a nie o same, wąsko rozumiane unit testy. Choć te ostatnie mogą być i owszem pożyteczne. Napisałem ostatnio unit test do właśnie tworzonej klasy, który trudno mi było doprowadzić do działania, dopóki nie stało się dla mnie jasne, że z tworzonej klasy powinienem wyodrębnić dodatkową klasę pomocniczą. Mój test przestał nagle być unit testem, bo przecież zaczął testować też tę drugą klasę. Zaczął być specyfikacją mini-komponentu. Klucz w tym, że bez posiadania testu nie wpadłem na pomysł wyodrębnienia dodatkowej klasy i gdybym testu nie miał, przypuszczalnie odnalazłbym błąd znacznie później.<br />Kwestia znanego wejścia i wyjścia jest bardzo istotna - ona formułuję specyfikację. Jeśli Twój system zależy od ściśle uporządkowanej sekwencji wywołań metod, to znaczy, że programujesz w stylu imperatywnym. Wszyscy, którzy docenili zalety stylu funkcyjnego będą Ci współczuć. Testy w naturalny sposób skłaniają do używania stylu funkcyjnego.<br /><br />@Sławek - na wspomnianym przykładzie widać korzyści płynące ze stylu projektowego "continuous care" w porównianiu z "big design up-front". Pytanie, czy siadając i zastanawiając się nad projektem mojej klasy na początku uzyskałbym optymalny projekt szybciej? Na pewno musiałbym wtedy (starając się skupić) walczyć z licznymi rozproszeniami bardziej, niż w sytuacji, gdy zawalający test podpowiada mi wciąż, czego jeszcze brakuje w moim designie.Anonymoushttps://www.blogger.com/profile/08968963615797084668noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-47238674634116005812009-11-12T08:51:54.321+01:002009-11-12T08:51:54.321+01:00A mi podoba się idea, którą wyczytałem w pewnej ks...A mi podoba się idea, którą wyczytałem w pewnej książce, że testy jednostkowe pozwalają nam uczyć się .... <- wstawić cokolwiek: domeny biznesowej, działania algorytmu, zachowania klasy, etc.<br /><br />Dzięki testom łatwo można poznać aplikację, jeśli nawet jej jeszcze nie ma ;-)Łukasz Lenarthttps://www.blogger.com/profile/16282501546640140356noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-68120067792121779782009-11-11T23:57:48.135+01:002009-11-11T23:57:48.135+01:00Unit Testy można pisać, gdy wiadmomo, jaka ma być ...Unit Testy można pisać, gdy wiadmomo, jaka ma być wyjście funkcji na dany zestaw wejść. Tego po pierwsze często nie wiadomo w przypadkach gdzy funkcja robi co kolwiek bardziej skomplikowanego, np. oblicza nastawy parametrów silnika w danych warunkach, a my często nie wiemy, jakie powinny byc dla danych wejść i właśnie chcemy, bo to funkcja obliczyła. Poza tym wiele błędów bierze się z tego, że program wykonał sekwencję operacji nieprzewidzianą przez programistę i tego też nie jesteśmy testami jednostkowymi w stanie opanować. Ogólnie testy jednostkowe nadają się do testowania jedynie najprostszych przypadków, które ze względu na swoją prostotę na ogół w ogóle (logicznie rzecz biorąc) nie wymagaja testowania.<br /><br />pozdr.<br />JanuszAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-26605051980662251572009-11-10T13:39:44.054+01:002009-11-10T13:39:44.054+01:00@Sławek - niestety wątpię, aby istniało pojedyncze...@Sławek - niestety wątpię, aby istniało pojedyncze opracowanie zawierającego syntezę profesji głoszonej przez Wuja na wzór książki o DDD Mr Evansa. Moje informacje czerpię z jego bloga, publikacji na stronie objectmentor.com, oraz blogów i twórczości jego współpracowników z OM i przyjaciół - współtwórców Agile Manifesto (m.in. Martin Fowler, Kent Beck)Anonymoushttps://www.blogger.com/profile/08968963615797084668noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-35127688573746352682009-11-10T12:22:46.463+01:002009-11-10T12:22:46.463+01:00@oodventurer - możesz polecić jakieś opracowanie r...@oodventurer - możesz polecić jakieś opracowanie rzetelnie prezentujące całość profesji? Nie musi być koniecznie produkcji Wujka. <br /><br />Chętnie się zapoznam i streszczę na np blogu.Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-51357875302690227702009-11-10T11:49:27.834+01:002009-11-10T11:49:27.834+01:00@Sławek
W jednej prezentacji trudno by raczej był...@Sławek<br /><br />W jednej prezentacji trudno by raczej było przedstawić całą profesję, na dodatek w atrakcyjny sposób. Wujek skupił się na TDD moim zdaniem słusznie, bo niewiele osób poza nim dostrzega podstawowe znaczenie tej techniki dla zachowania wielu pożądanych cech projektu.Anonymoushttps://www.blogger.com/profile/08968963615797084668noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-29860790175133918752009-11-10T11:30:53.626+01:002009-11-10T11:30:53.626+01:00@oodventurer - masz rację, pod warunkiem, że jest ...@oodventurer - masz rację, pod warunkiem, że jest to prezentowane całościowo - jako spójna "profesja".<br /><br />Odnoszę się do Wujka w kontekście jego słynnej prezentacji gdzie mamy lansowanie samych testów - tak zresztą wygląda zdecydowana większość marketingu.<br /><br />@Anonim - dziękuję za uznanie, ale nie miałem intencji krytykowania TDD. Chodziło mi o krytykę naiwnej interpretacji skupionej wokół SAMYCH TYLKO testów. Lansuje się to co proste/prostackie bo zawsze łatwiej sprzedać taki produkt:/Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-84771676052041449672009-11-10T11:23:30.511+01:002009-11-10T11:23:30.511+01:00Cześć Sławku. Polecałbym Ci wziąć przekaz Wujka w ...Cześć Sławku. Polecałbym Ci wziąć przekaz Wujka w szerszym kontekście (on współtworzył stan obecnej wiedzy nt OOP - zobacz listę publikacji na ObjectMentor), bo jego przekonanie do TDD wcale nie bierze się z niedocenienia zasad SOLID i GRASP (znajdziesz je zresztą szeroko omówione na stronach jego firmy). Przeciwnie, praktyka TDD w wersji polecanej przez Wujka bardzo sprzyja zachowaniu tych zasad. Niezbędny wysiłek umysłowy, o którym mówisz, przy TDD zachodzi niejako przy okazji - TDD stwarza dla niego bardzo wygodną ramę. Dodatkowo otrzymujesz cenny efekt uboczny, o który trudno nieraz w zaawansowanych metodach analityczno-projektowych: prostotę.Anonymoushttps://www.blogger.com/profile/08968963615797084668noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-14866413740882069682009-11-10T11:21:55.045+01:002009-11-10T11:21:55.045+01:00Brawo za artykuł! Nareszcie ktoś się odważył skryt...Brawo za artykuł! Nareszcie ktoś się odważył skrytykować tę durną koncepcję, która niczego nie wnosi, a wręcz przeszkadza w efektywnym tworzeniu oprogramowania.Anonymousnoreply@blogger.com