Zasady stosowania zasad

Klątwa wiedzy to trudność w wyobrażeniu sobie, jak to jest, gdy ktoś nie wie tego, co my wiemy.

Steven Pinker

Nikt nie rodzi się nieomylny, nikt nawet z biegiem czasu nie staje się nieomylny. Niestety czasami się tak zdarza i to jest widoczne w naszej branży dość często, że niektórzy myślą o sobie jako o doskonałych programistach, zwłaszcza jeśli są zatrudnieni jako senior-hiper-super developer. Czy można z tym walczyć? Można. Czy należy z tym walczyć? A to już zależy.

Słowa Stevena Pinkera zainspirowały mnie do napisania tego wpisu. Z perspektywy czasu mogę dostrzec rzeczy, które mnie ukształtowały jako programistę. Duży wpływ, na moje zdolności programistyczne miały pewne osoby, ale dzień za krótki, żeby opisać te osoby, jednak była jedna, powtarzalna cecha, którą wszystkie te osoby wykazywały. Co to takiego? Nawoływanie do upraszczania. Jeżeli coś jest za długie, żeby to opisać w kilku słowach to znaczy, że zbyt dużo rzeczy skupiło się naraz, a jak jest dużo rzeczy w jednym miejscu to zgodnie z zasadami matematyki, które niestety są nieubłagalne, powstaje wiele miejsc w których może pojawić się problem, który będzie trzeba rozwiązać. Pytanie jak z tym walczyć.

Oto lista rzeczy, którą mogę polecić:

  • Jeżeli nie jesteś inżynierem z NASA to nie pracuj jak inżynier z NASA.

Lubimy myśleć o sobie jako o osobach wyjątkowych, które tworzą coś co jest niezwykle wyjątkowe i na pewno zmieni otaczający nas świat. Czasami tak jest, ale to nie jest reguła. Koło ma tą właściwość, że już zostało wynalezione i raczej nie spodziewaj się, że ktoś będzie Cię oklaskiwał jak wymyślisz coś co już istnieje, po prostu szkoda na to czasu.

Wskazówka: Tam gdzie możesz korzystaj z gotowych rozwiązań.

  • Nie koduj, pisz prozę.

To już nie te czasy by ślęczyć nad kartami perforowanymi i tworzyć coś co będzie zrozumiała tylko dla nas i przy odrobinie szczęścia dla maszyny, do której to włożymy. Amerykańscy naukowcy udowodnili a codzienna praktyka potwierdza, że kod w 80% się czyta a tylko w 20% się go pisze, więc warto by kod był maksymalnie czytelny.

Polecam świetną prezentację Sławomira Sobótki na ten temat.

Jest wiele metod na pozostawienie po sobie czytelnego kodu, nie mówię o wchodzeniu ma poziom Sławka Sobótki, ale o prostych rzeczach, które można zrobić, by kod był czytelny. Absolutne minimum to odpowiednio nazwane klasy. Nie wiele kosztuje pisanie fluent api itd itp. (czyli niebawem na blogu)

  • Korzystaj z utartych zasad i dobrych praktyk odnośnie formatowania kodu.

To, że kompilator przyjmie kod napisany w jednej linijce, nie znaczy, że ma się tak pisać.

Jest zasada w .Necie nazwy metod pisze się z wielkich liter, więc nie bądź buntownikiem i pisz z wielkich. Jest coś takiego jak camelCase i PascalCase, jak nie wiesz co to poczekaj, niebawem się pojawi. Istnieje wiele zasad odnośnie formatowania kodu i można się z tym zgadzać albo nie ale to wiele ułatwia, zwłaszcza jeśli ma się poprawić nie swój błąd.

Dobra rad: Czytaj kod innych programistów i to najlepiej tych dobrych. Wszystko znajdziesz na GitHubie.

  • Poznaj i stasuj zasady SOLID

Zasady SOLID zostały już dawno spisane i naprawdę nie bolą. To że coś wymaga stworzenia większej ilości kodu nie znaczy, że jest złe. Wręcz przeciwnie, jeśli można uczynić kod czytelniejszym to czemu nie.

Zasadom SOLID poświęcę kilka najbliższych postów, więc cierpliwości.

  • Poznaj i korzystaj z wzorców projektowych

O tym, że wzorce projektowe warto znać, chyba nikogo nie muszę przekonywać. Wzorce projektowe były jednym z kamieni milowych mojego rozwoju. Pokazały mi, że nie muszę wymyślać koła na nowo bo z większością problemów, a właściwie z klasą problemów już ktoś kiedyś się zmierzył i to ze skutkiem pozytywnym.

Wzorce projektowe także opiszę niebawem.

  • Czytaj wszystko co się da.

Will Smith kiedyś powiedział, że nie ma na tym świecie problemów, z którymi już ktoś się nie zmierzył i nie napisał o tym książki. Trudno się z tym nie zgodzić, no chyba, że jesteś inżynierem z NASA, to wtedy inna para kaloszy.

Dostęp do informacji jest obecnie znacznie tańszy niż było to kilkanaście lat temu, więc czemu by z tego nie korzystać.

 

Share on Facebook0Share on Google+0Tweet about this on Twitter0Share on LinkedIn0

Kamil Jóźwiak

Nazywam się Kamil Jóźwiak i jestem programistą w firmie Sii, specjalizuję się w technologi .Net. W codziennej pracy staram się łączyć wzorce, style architektoniczne, ale przedewszystkim zdrowy rozsądek. Miłośnik czystego kodu i automatyzacji wszystkiego co się da zaatomatyzować.

Zobacz też:
Nazywam się Kamil Jóźwiak i od prawie 10 lat programowanie…