Standardy kodowania jako choroba dziedziczna

2010-05-25 18:38

Ponieważ programowaniem zajmuję się już od dość długiego czasu, mam w tym nieco doświadczenia praktycznego. Przez ten czas zdążyłem też zmienić część swoich poglądów na niektóre rzeczy z tym związane. Mówiąc trochę górnolotnie: stałem się bogatszy o wiedzę z życia wziętą :)
Jedną z takich nauczek życiowych jest to, by nie ufać zbytnio standardom, zaleceniom i innym tzw. dobrym praktykom podpowiadających (a czasem wręcz nakazujących), jak powinien wyglądać pisany przez nas kod. Dotyczy to na przykład instrukcji rzekomo złych “z natury” i innych tego rodzaju przesądów. Tak, uważam określenie ‘przesądy’ za uprawnione w wielu przypadkach.

Nie jestem ponadto odosobniony w tych poglądach – ba, wśród swoich kolegów po fachu mógłbym wskazać wielu kilku, którzy są pod tym względem nawet bardziej… radykalni :) Jak już jednak wspomniałem na początku, nie zawsze tak było. Kiedyś miałem bardziej rygorystyczne i pryncypialne podejście do kwestii tego, jak kodować należy lub nie należy. Skąd brałem dla niego uzasadnienie, jeśli nie z praktyki, której wtedy zbyt wiele jeszcze nie miałem?…
Ano właśnie – tu dochodzimy do sedna. Przekonanie to brało się głównie – jeśli nie wyłącznie – ze wszelkiego typu materiałów pomocniczych do nauki programowania: książek, kursów, artykułów, czasem dokumentacji. Choćby nie wiem jak techniczne i merytoryczne były te teksty, w każdym – co do jednego, z moim skromnym dziełem włącznie – znajdą się rady, zalecenia, wskazówki i inne “metainformacje” odnośnie tego, jak programować należy – a nie tylko o tym, jak można. Czy ktoś widział w kursie programowania opis instrukcji goto (że pozwolę sobie użyć najbardziej typowego przykładu), który nie zawierał chociaż śladowej wzmianki o tym, iż.. no, w zasadzie to nie należy jej używać?… …Tak myślałem ;-)

Nasuwającą się od razu repliką w obronie autorów jest sugestia, że w sumie to przecież całkiem dobrze, iż uczą oni nowicjuszy tego, co sami musieli wcześniej wypracować przez lata. Nie wątpię wręcz, że taka intencja – oszczędzenia początkującym trudności – rzeczywiście autorom przyświeca. Dodają oni do pisanych przez siebie tekstów, kursów, tutoriali, itp. liczne wskazówki, te wszystkie dos and don’ts właśnie dlatego, iż wierzą w to, że w ten sposób pomogą swoim czytelnikom od razu, już na starcie kodować w sposób przejrzysty, efektywny, elastyczny, elegancki, “łatwo konserwowalny”, i tak dalej.


“Pamiętaj synku, by się zabezpieczać:
dawaj const, gdzie tylko możesz.”
(Źródło obrazka)

Chwalebne intencje – nie da się ukryć. Ale nietrudno jest wskazać przynajmniej dwa błędy takiego rozumowania. Pierwszym jest założenie, że każdą wiedzę i każdą umiejętność da się przekazać innym – czyli że w ogóle istnieje “droga na skróty”, niejako omijająca zdobywanie doświadczenia praktycznego w danej dziedzinie (w tym przypadku w programowaniu). Żeby stwierdzić, że to jednak nieprawda, wystarczy zastanowić się, czy ukończenie podstawowego kursu szachów u arcymistrza da nam od razu ELO 2500. Niestety w rzeczywistości dojście do takiego poziomu wymaga dziesiątków tysięcy rozegranych partii – i nic się na to nie poradzi.
Drugim błędem jest przyjmowanie, że przekazywane mądrości są faktycznie odpowiednie dla odbiorców. Nie, nie chcę wcale sugerować, że ktoś może mieć traumę z powodu wczesnych doświadczeń z hermetyzacją czy wzorcem fabryki ;) Raczej sugeruję, że przywiązując zbyt wielką wagę do przekazywanych zaleceń, początkujący mogą stracić wiele czasu na dopasowywanie swoich pierwszych programów do ich wysoko zawieszonej poprzeczki – najczęściej zupełnie niepotrzebnie. Gra w zgadywanie liczby, kółko i krzyżyk czy tetris nie potrzebują zwykle skomplikowanej, wewnętrznej architektury z dokładnie zaprojektowanymi relacjami między klasami i starannym oddzieleniem interfejsu od implementacji. Prosi się to bowiem o przytoczenie znanego powiedzenia na temat artylerii i pewnego gatunku insekta :)

Tak oto okazuje się więc, że zalecenia i rady tudzież – szumnie nazywane – standardy kodowania są “dziedziczone” przez początkujących programistów od autorów książek, kursów i tutoriali, którzy je tam umieszczają pomiędzy objaśnieniami kolejnych konstrukcji językowych czy elementów API. A że ponadto, jak opisałem wyżej, standardy te zbyt wcześnie poznane mogą być nie tyle nawet zbędne, co wręcz szkodliwe, pozwalam sobie nazwać je ‘chorobami dziedzicznymi’. Nic tak bowiem nie trafia do wyobraźni jak obrazowe porównanie ;>
Zakończyć chcę jednak optymistycznym akcentem. Otóż choroby te są jak najbardziej uleczalne. Terapia jest też nieskomplikowana i – jak sądzę – skuteczna. Trzeba po prostu kodować, kodować i jeszcze raz kodować :)

Tags: , ,
Author: Xion, posted under Books, Programming, Thoughts »


4 comments for post “Standardy kodowania jako choroba dziedziczna”.
  1. Kauach:
    May 26th, 2010 o 13:55

    myślę, że książki z programowania czyta się iteracyjnie – najpierw próbuje się zrozumieć podstawowe kontrukcje, potem działanie kodu, a na końcu standardy. Pisząc taką książkę nie da się ominąć standardów, bo odruchowo wg. nich się koduje. Po co pisać coś “średnio poprawnego” skoro lepiej żeby czytelnik wrócił potem do książki i zrozumiał o co tam chodziło. Sam do końca nie rozumiem części konstrukcji z Symfonii, a mimo to nauczyła mnie programować w C++ i jak mam jakieś wątpliwości co do standardów czy użycia pewnych konstrukcji zaglądam tam i patrzę jak ich używają “profesjonaliści” =)

  2. moriturius:
    May 26th, 2010 o 22:47

    @Xion: rozumem Cie! Sam kiedys tez popelnilem podobny post jednak bardziej skupialem sie na goto i obiektowosci ;)

    Prawde mowiac nie mam nic przeciwko temu ze ktos kladzie mi do glowy swoje doswiadczenia i przemyslenia. Predzej czy pozniej – jak sam zauwazyles – czlowiek dochodzi do odpowiednich wnioskow sam (potem pisze artykul i sprzedaje swoje pomysly na kod ;) ).

    Jedno co mnie prawdziwie meczy (zwlaszcza odnosnie goto) to fakt, ze wszyscy mowia/pisza, zeby nie uzywac, a nikt nie informuje dlaczego… Sam uzylem tej instrukcji chyba z dwa razy (z czego raz podczas nauki), ale mozliwe ze sie balem bo myslalem ze mi komputer wybuchnie ;)

    Wydaje mi sie ze lepiej by bylo napisac aby uwazac na goto bo potrafi zrobic niezly ‘dom publiczny’ w kodzie.

  3. Reg:
    May 30th, 2010 o 20:09

    Bardzo trafne refleksje – popieram! Chociaż myślę, że może choć trochę można pomóc początkującym dając im wskazówki na podstawie swoich doświadczeń, żeby uczyli się na cudzych błędach a nie musieli dochodzić do wszystkiego sami. Ważne, żeby te wskazówki i nauczanie uprawiali ci którzy takie doświadczenie faktycznie mają, a nie tylko teoretycy oderwani od rzeczywistości. A z tym niestety bywa różnie, bo jak wiadomo “kto coś umie, to robi, a kto nie umie, uczy innych” :) Natomiast przesadzanie z wpajaniem programistom “od małego” indoktrynacji obiektowej to jest wg mnie osobny problem.

  4. Xion:
    June 7th, 2010 o 13:28

    Przypadkiem trafiłem na coś, co częściowo zgadza się z moimi obserwacjami:

    http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition

    Nadal jednak nie wyjaśnia, czemu osoby poziomu 4. i 5. (bo głównie takie piszą książki/kursy (a przynajmniej mam nadzieję)) tak chętnie przekazują innym reguły, do których sami już przestali się stosować :)

Comments are disabled.
 


© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.