Dlaczego powinniśmy pisać dobry kod, a nie tylko działający

Nie jest to regułą,

ale często z punktu widzenia pracodawcy (zwłaszcza gdy pracodawca nie sprzedaje naszych programów tylko sam z nich korzysta) praca programisty polega tylko na dostarczaniu działającego oprogramowania. Trudno się z tym nie zgodzić, bo faktycznie taki jest stawiany przed nami cel.  Niedziałające oprogramowanie nie byłoby nikomu potrzebne, chyba że samym programistom by mogli zarobić na chleb. Pracy jednak przynajmniej na razie nie brakuje. Wracając do tematu:  Jak programista osiąga ów cel? Świadomość ogólnie rozumianego biznesu jest na ten temat raczej niska i być może ktoś wyobraża sobie że gość we flanelowej koszuli (btw. uwielbiam flanelowe koszule) z okularami jak lornetka i smarkający w 100 złotowe banknoty uderza w przyciski klawiatury w rytm „Stairway To Heaven” granego od tyłu.

Nie ma w tym nic złego (no chyba że ktoś ma fobię na punkcie stereotypów – nawet tak ogranych i żałośnie mijających cel 😉 ) bo dla tego kogoś istotne jest to że w końcu będzie mógł uruchomić program który mu dostarczymy.

Tak więc w pełni zgadzam się ze stwierdzeniem że hajs który wpływa z tytułu pracy co miesiąc na moje konto jest zapłatą za produkt który tworzę i że głównym czynnikiem implikującym to że piniendze sie zgadzajo jest fakt poprawnego działania produktu. Niemniej uważam że nie jest to czynnik jedyny (nawet gdy gość który płaci mi pieniądze tak uważa).

Każdy zawód posiada pewien, z braku lepszego słowa użyję tego, ekosystem. Ten w którym „żyją” programiści być może faktycznie nie wydaje się wymagający, ceni on za to dobre maniery. O czym mowa? O tym, że w skład (a co tam) biocenozy tego ekosystemu wchodzimy nie tylko my i pracodawca, a także inni programiści. Ci którzy będą, teraz lub w przyszłości, pracowali na tym samym kodzie (to będzie chyba biotop :))

Do rzeczy 🙂

Co prawda w liceum byłem w klasie biol-chem, ale z tego co pamiętam ledwo zdawałem z biologii więc zostawię te metafory. Mam nadzieję, że w części można już odpowiedzieć sobie na pytanie stojące w tytule posta ale chce mi się jeszcze pisać więc…

Zakładam, że definicja mówiąca czym jest dobry kod jest szeroko znana. Mimo wszystko wspomnę o tym i tutaj, starając się pokazać że nie jest to  tylko sztuka dla sztuki.

  • Dobry kod to taki, który jest czytelny. Jeżeli jest czytelny to łatwiej jest go komuś zrozumieć, lub wyłapać błędy. Lepiej też przyjmuje zmiany robione pod presją.
  • Czytelny kod to taki, który jasno wyraża intencje programisty, dzięki czemu minimalizowane jest ryzyko że ktoś spróbuje wprowadzać zmiany do których nie został przeznaczony
  • Kod, który jasno wyraża intencję programisty jest zwykle prosty – zbytnia złożoność, albo próby wydumanej elegancji (z czym niestety wciąż mam problem) utrudniają innym utrzymanie i zaciemniają intencje i sprzyjają powstawaniu błędów.
  • Kod prosty jest kodem przemyślanym. Jest to coś co McConnell nazywa kodem pisanym do języka a nie w języku. Dzięki temu ktoś kto zna tylko podstawy też jest w stanie nas zrozumieć.
  • Kod przemyślany stawia na minimalizm zarówno na poziomie odpowiedzialności klas, jak i ilości ich zależności. Nie wykorzystuje zbędnych konstrukcji języka, jeżeli można coś rozwiązać prościej. Takie podejście pozwala innym na łatwiejsze dostrzeżenie konwencji jakie stosujemy i wzorców jakimi się posługujemy.

Oczywiście tego typu stwierdzenia można by jeszcze mnożyć ale wydaje mi się, że powyższe wystarczą do zastanowienia się nad jeszcze raz nad kwestią: za co tak naprawdę płaci pracodawca (i dlaczego nie jest to sam działający program)?  Wtedy łatwiejsza jest odpowiedź na pytanie zadane w tytule 🙂

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *