Dobrzy programiści potrafią ruszyć swoją dupę

Oryginalny post: Good Programmers Get Off Their Butts

Autor: Jeff Atwood

Szukałem tego cytatu i tak jak Wes pamiętam, że go czytałem, ale nie pamiętam, gdzie dokładnie to było:

To nasuwa kolejny komentarz do ostatnio przeczytanego wpisu na blogu, którego autora nie potrafię sobie przypomnieć. Dobrzy programiści potrafią ruszyć swoją dupę. Zazwyczaj jest tak, że programiści nie piszą żadnego kodu, dopóki nie rozwiążą pewnych problemów projektowych, a wtedy czas ucieka bez większych postępów w projekcie. Produktywni programiści napiszą jakiś kod nawet, jeśli projekt jest niejasny, ponieważ tworzenie oprogramowania jest procesem iteracyjnym.

Już nie pamiętam ile razy zasiadałem do projektowania po czym, podczas programowania porzucałem bądź radykalnie modyfikowałem projekt, ponieważ..

  • Zapomniałem o czymś bardzo ważnym
  • Znalazłem inne, łatwiejsze rozwiązanie
  • To co robiłem, nie miało sensu
  • Na nowo wynajdywałem koło, a powinienem był znaleźć gotowca w sieci
  • Hej, przecież nie muszę tego robić od razu!

W prawdziwym świecie istnieje ciasna pętla przyczynowo-skutkowa pomiędzy fazą implementacji a projektowania. Jeśli używasz Photoshopa jako narzędzia do projektowania, wszystko jest możliwe. Niestety, Visual Studio nie jest takie wyrozumiałe.

Nie proponuje tutaj metodologii programowania, które zamienia się w piekło. Podczas mojego doświadczenia zaobserwowałem, iż kodowanie bez planowania jest tak samo bezskuteczne jak kodowanie ze zbyt dużą ilością planowania. Tworzenie oprogramowania jest paskudnym problemem; nigdy nie powinieneś podejmować decyzji w sprawie planowania bez jakiegokolwiek prototypu w postaci kodu dla pewności, iż podejmujesz świadome decyzje. Jeśli zbyt dużo planujesz w oderwaniu od kodowania gwarantuję Ci, iż robisz coś, co będzie wyrzucone bądź zmienione nie do poznania.

Najbardziej destruktywnym symptomem nadmiernego planowania jest błędne pojęcie, iż bycie Architektem Oprogramowania(tm) oznacza rysowanie dużej ilości diagramów UML i przekazywanie ich grupie programistów w Bangalore. UML jest świetny, jeśli nie chcesz wykonać żadnej pracy; rysujesz jedynie obrazki przedstawiające to, jak by to wyglądało, jeśli praca byłaby faktycznie wykonana. To nie tylko granica lenistwa, to również przepis na katastrofę. Nie można na białej tablicy stworzyć architektury modelującej świat rzeczywisty. Musisz stworzyć prototyp w kodzie, aby zebrać informacje o wydajności oraz implikacje wynikające z projektu na podstawie Twoich decyzji. W innym razie tak naprawdę nie masz pojęcia, czy tworzysz coś, co ma sens -- bądź czy w ogóle jest wykonalne! Tak jak zaznaczył to Robert Glass w książce Facts and Fallacies of Software Engineering, że podczas projektowania oprogramowania praktyka jest obowiązkowa:

Projektowanie, będące daleko od bycia przewidywalnym, dającym się ustrukturyzować, proceduralnym procesem -- według ustaleń Curtisa i Solowaya (1987) -- jest czynnością pełną zamieszania, operającą się na metodzie prób i błędów. A pamiętaj, że te ustalenia są wynikiem obserwacji najlepszych projektantów podczas pracy. Można sobie wyobrazić mniej doświadczonych ludzi używających jeszcze bardziej zagmatwanego procesu. Najprawdopodobniej najgorsze podejście projektowe, a jednocześnie takie, które kusi wielu nowicjuszy, to "najpierw-rzeczy-łatwe". Pomimo iż łatwo jest rozpocząć projektowanie z tym podejściem, to często wiedzie ono do wczesnych rozwiązań, które nie integrują się z rozwiązaniem końcowym. W wyniku czego, wczesne rozwiązania często muszą być porzucone.

Na podstawie tego dobrze widać, iż faza projektowania jest złożona i iteracyjna. (Ta myśl jest wyraźna w książce Wiegersa [1996].) W zasadzie, jest to prawdopodobnie najbardziej zajmująca intelektualnie czynność w procesie tworzenia oprogramowania. Jak również łatwo zauważyć, początkowe rozwiązania projektowe całkiem często okazują się być złe. A co z rozwiązaniem optymalnym? Cóż, z pewnością początkowe rozwiązania rzadko kiedy bywają optymalne. Natomiast to słowo rodzi kolejne interesujące pytanie -- czy istnieje takie coś jak optymalne rozwiązanie projektowe?

Jako programiści -- a w szczególności jeśli rościmy sobie prawa do określania nas mianem "architektów" -- zawsze powinniśmy podejmować decyzje oparte na doświadczeniu i danych. Możesz to lubić bądź nie, ale to oznacza ruszenie swojego dupska i napisania jakiegoś kodu.

Data publikacji oryginału: 21 listopada, 2004

5 komentarze:

Tomasz Kowalczyk pisze...

Problem w tym, że akurat ja lubię pisać kod i czasem wiedziony początkowym sukcesem [to działa! buahahahaha!] nie wracam do projektowania, a staram się skończyć kod, co powoduje, że niestety trzeba zrobić svn revert. ;] Mam nadzieję, że ten artykuł uświadomi mojemu programistycznemu ja, że czasem trzeba wrócić, ale do projektowania a nie do kodu.

M4ks pisze...

Doświadczenie i dane. To podstawa - wybitnie pokazał to mój projekt uczelniany - część na hura rzucili się do edytorów a część zaczęło projektować kazdą jedną zmienna - nie mając przy tym pojęcia o danych ani praktycznego doświadczenia. W efekcie niestety praca poszła do kosza i trzeba było zaczynać jeszcze raz. Przy czym 80% to mój "niepotrzebny i zbędny" wg. początkowych opini proof of concept paru aspektów.

Tomasz 'Kos' Wesołowski pisze...

Drobny burak w tłumaczeniu: "Hey, I don't even need to do this in the first place! " - to ostatnie nie znaczy "jako pierwsze", a bardziej coś na kształt "przede wszystkim".

rafek pisze...

@Kos: dzięki, poprawiłem na "od razu", ponieważ lepiej pasuje. Przy okazji znalazłem jeszcze inny błąd. ;)

Anonimowy pisze...

@rafek
Tomkowi chodziło chyba o to, że w tym zdaniu znaczenie to raczej:
"Hej, przecież ja tak właściwie nie muszę tego WCALE robić".

Prześlij komentarz

Related Posts with Thumbnails