czwartek, 2 stycznia 2014

Pragmatyzm według mnie .... część 1.

Chapter 1 (Należy dbać o swoje rzemiosło)
NoSql_joke1

Przedstawie parę fajnych recept jak zostać pragmatycznym programistą.
Wiedza ta pochodzi głównie z książek i praktyki :
 - From Journeyman to Master  
 - Thinking and Learning
 - 97 Thinks Every Programmer Should Know

(Self improvement , Technical Excellence, Code Smells)

Poniższe opisane przeze mnie wskazówki powinny stanowić podstawę warsztatu każdego programisty w każdym stadium jego rozwoju. Ale to tylko moja opinia;)

 Pragmatycznego programistę cechują:
 - odwaga (do przyznania się do popełnionych błędów)
 - branie odpowiedzialności na siebie
 - proponowanie rozwiązań,  zamiast kiepskich wymówek
 - nie akceptowanie wybitej szyby
 - śmiałe propozycje ulepszeń
 - inwestowanie w wiedzę
 - krytyczne myślenie
 - dociekliwość
 - gotowość do nowych wyzwań

Tak więc zaczynamy: (w nawiasach podaje jakieś skróty myślowe mające związek z daną poradą.)

Software is created in your head. - spędzaj czas na nauce technologii, poznawaniu narzędzi oraz procesów wytwarzania. To dobrze spędzony czas.

Only dead fish go with the flow :) - nic w życiu nie jest statyczne. Żeby się rozwijać i dostosowywać do nowych wyzwań i technologii trzeba czasem zmienić swoje podejście lub przyzwyczajenia. Bycie elastycznym - zawsze to Ci ułatwi. Np znasz jave i piszesz w niej parę już lat. Uważasz, że możesz zrobić dzięki niej niemal wszystko. Ignorujesz nowe języki oparte na JVM jak Scala czy Groovy, bo po co je używać skoro możesz to wszystko zrobić w javie ?
Ale czy to naprawdę słuszne podejście. Warto zrobić rozeznanie, zobaczyć co daje mi jedno a co oferuje drugie. Może niektóre rzeczy można wykonać lepiej, lub szybciej ? Bądź zawsze otwartym na zmiany.

Where We’re Going - czyli moja droga rozwoju od nowicjusza aż do eksperta. Opis znajdziesz tutaj. Można to uzupełnić jedynie o następujące zasady :
Istnieje zależność między poziomami od nowicjusza po eksperta oparta na następujących regułach: (Use rules for novices, intuition for experts)
intuicja rozwija się z czasem, rozumienie szerszego kontekstu również.

Autorzy Pragmatic Thinking and learning sugerują, że niestety większość ludzi zostaje na poziomie advanced beginner i to jest smutna prawda w naszej drodze do profesjonalizmu.
Ważna jest tutaj własna świadomość i uczciwa ocena poziomów zdefiniowanych przez braci. Na niższych stopniach umiejętności ludzi mają tendencje do zawyżania swoich umiejętności. Odwrotna sytuacja dotyczy wyższych stopni umiejętności. Trzeba tutaj również zaznaczyć, iż ekspert nie musi być dobrym nauczycielem czy mentorem (craftsmanship).

Code is write-one , read-many. Pamiętaj zawsze o tej zasadzie. Jest ona bardzo blisko spokrewniona z ideą Clean Code. Twój kod będzie czytać wiele osób, a nawet Ty sam czasem musisz do niego wrócić po długim czasie. Ułatw sobie i innym czytanie i zrozumienie go.
Stosuj się do praw opisanych przez Uncle Boba i utartych standardów danego języka. Stosuj narzędzia do statycznej analizy kodu one Ci pomogą i wskażą potencjalne problemy. Stosuj wzorce projektowe i wzorce integracji. To są ustandaryzowane struktury,  które pomogą innym w zrozumieniu dziedziny problemu, lub w poznaniu działania algorytmu programu.

Talk to the duck - ile razy zdarzyło Ci się siedzieć godzinami nad rozwiązaniem jakiegoś buga. W końcu decydujesz się prosić kolegę o pomoc w znalezieniu problemu. Kolega podchodzi do Twojego monitora, a Ty opowiadasz mu w czym leży problem i jak zaimplementowałeś jakąś funkcjonalność. Okrywasz nagle, że podczas swojego tłumaczenia to Ty znasz już rozwiązanie albo wpadacie na niego niemal równocześnie. Często uznajesz, że kolega jest jakimś magikiem bo problem szybko znika. To syndrom  "gumowej kaczki", swoistego rodzaju  metafory. Wyobraź sobie, że taka kaczka siedzi Ci na ramieniu i opisz jej problem jak to robiłem poprzednio z kolegą, którego wołałeś do pomocy. To działa - sprawdź to sam :)
Można też obrać inną taktykę, spróbuj wyjaśniać problem i stosowane rozwiązanie komuś kto nie zna dziedziny problemu lub nawet technologii w której pracujesz. Takie procesy myślowe ułatwiają czasem znalezienie błędu i są skuteczniejsze bardziej niż Ci się wydaje.

Use a Wiki . WIKI powinno działać jako tekstowy zamiennik mapy myślowej. Gromadź i opisuj tutaj ważne informację o danym projekcie jak np: konfiguracje, opis interfejsów systemowych, API, potencjalne problemy i opisy kluczowych procesów biznesowych. Przygotuj to w taki sposób, żeby potencjalnie nowy członek zespołu, który wchodzi do projektu po przeczytaniu tych dokumentów mógł w miarę bezproblemowo skonfigurować i odpalić aplikacje na dedykowanym serwerze oraz poznał podstawowe procesy i akcje oraz zadania,  które nasza aplikacja ma wykonywać. (Use a wiki to manage information and knowledge.)

Care about your craft. - jeśli programujesz czy projektujesz staraj się to robić dobrze. Ucz się, rozwijaj się, poznawaj swoje rzemiosło. (craftsmanship)

Grab the wheel. You can’t steer on autopilot.
Bądź świadom tego co robisz. Bacznie obserwuj zmiany i szybko na nie reaguj.(CI)

Provide options, don’t make lame excuses.
Nigdy nie szukaj wymówek.
Przyznanie się do winy jest symbol odwagi. Jeśli inni tego nie docenią to ......słabo świadczy o nich samych.
Staraj się nie mówić nigdy, że czegoś nie można zrobić.
Szukaj rozwiązań, proponuj, organizuj burzę mózgów. Zawsze masz stackoverflow :) jak pomysły Ci się już skończą.

Remember the big picture.
Zawsze pamiętaj o ogóle. Skupienie się na szczegółach czasem potrafi zamazać obraz.

Be a catalyst for change.
Zostań katalizatorem zmian w Twojej firmie czy teamie. Takie podejście pozwala na rozwój zespołu i wspomaga poszerzanie wiedzy.

The Dog Ate my Source Code
Jeśli coś stanie się z Twoim kodem, który pisałeś przez cały dzień będzie słabo.
Stosuj zawsze systemy SCM. Dzięki częstym commit'om nie musisz martwić się, że wydarzy się coś co sprawi, że Twoja praca pójdzie na marne.
Naucz się  jak działa Twój SCM, jakie ma cechy, funkcje, możliwości
Zobacz jak tworzyć gałęzie, tagować czy merge'ować zmiany. Sprawdź np jaki będzie zysk dla projektu oraz dla mnie jeśli przejdę z SVN'a na GIT'a. Poczytaj o dobrych praktykach wersjonowania oraz stosuj się do nich.
Ale tak naprawdę nie chodzi tu o kod a branie odpowiedzialności na siebie. Trzeba mieć odwagę przyznać się do swojej niewiedzy lub popełnionych błędów.

Build continuously
Stosuj zawsze CI - to potężne narzędzie i Twój największy sprzymierzeniec. Więcej na ten temat przeczytasz tutaj.

Use the best tool for the job
Przygotuj sobie skrypty i skonfiguruj narzędzia pracy - to ma być twoja oręż.
Dobrze jest używać też np dwóch monitorów jeśli to ma pomoc w przełączaniu się między różnymi kontekstami.

Don’t live with broken windows
Ktoś zauważył, że jeśli np w jakimś budynku w mieście jest wybita szyba, to zaraz pojawią się dodatkowe mazgaje pomalowane sprayem. Zostanie wybita następna szyba czy inna dowolna czynność, która będzie sprawi że budynek popadnie w ruinę.
To samo dzieje się z naszym kodem. Jeśli zobaczysz jakiś nieudolny kawałek lub coś co wymaga szybkiej refaktoryzacji zrób to. Inaczej projekt popadnie w ruinę. Kiedy kod jest ładny każdy stara się o niego jak tylko umie. Nie chce by jego praca spowodowała, że stanie się bublem lub śmietnikiem. Kod jest własnością wspólną. (code review) Nie akceptuj wybitych szyb.
A co daje nam wspomniany wyżej Code Review ? - zwiększa jakość kodu oraz redukuje wystąpienie błędów. Ponadto podnosi współczynnik dzielenia się wiedzą oraz zwiększa krzywą nauki. Dlatego właśnie często niesłusznie znienawidzony przez programistów code review powinien być tak naprawdę przez nich pożądany. Komentarze wydane przez lidera czy architekta powinny być konstruktywne i nie drażnić autora kodu, w przeciwnym wypadku często taki proces kończy się na wzajemnej niechęci.

Invest regularly in your knowledge portfolio.
To jest bardzo ważna cecha bycia czy stawania się pragmatycznym i ulepszania swojego warsztatu. Programowanie to nie garncarstwo , wiedza szybko się dezaktualizuje. Jeśli nie chcesz martwić się o pracę teraz czy w przyszłości już wiesz co robić.

Dobrą praktyką jest :
-  regularne inwestowanie, np. co 1 rok ucz się nowego języka programowania
- różnorodność : im większa tym lepiej (technologia, narzędzia etc)
- zarządzanie ryzykiem (chyba nie chcesz być bezrobotny ?)
- czytanie jak największe ilości książek technicznych (min 1 książka na kwartał).
- udzielanie się sieci, bycie aktywnym (obecnie coraz więcej pracodawców szuka  Twoich śladów w sieci)
- warsztaty, konferencje etc
- poznawanie nowych narzędzi, metodyk , czy środowisk (przegląd i korekta)

DRY – Don’t repeat yourself. (One fact in one place - duplication leads to error)
Bez komentarza :) Shotgun surgery.

Make it easy to reuse.
Buduj tak klasy aby można było je łatwo użyć ponownie. Niestosowanie się do tego może spowodować  antipattern copy-paste. (solid , grasp (SRP oraz OCP))

Eliminate effects between unrelated things.
Buduj tylko systemy oparte na ortogonalności.
System nieortogonalny jest jak sterowanie helikopterem, aby skorygować tor lotu pilot musi wykonać wiele czynności. Ma do dyspozycji pedały i dźwignie. Zmiana jednego może spowodować konieczność korekty drugiego ustawienia.
Należy eliminować wzajemny wpływ niepowiązanych elementów :
  - zwiększamy produktywność
  - możliwość wielokrotnego użycia
  - testowalność
  - prostotę
(MVC , AOP,  TIER, Separation of concerns)

Prototype to learn
Budowanie prototypu jest tanie. Samochody też najpierw buduje się używając balsy, żeby pokazać spodziewany rezultat i przetestować np w tunelu aerodynamicznym. Budowanie modelu z docelowych części jest drogie. Poza tym cała koncepcja może okazać się klapą.

Use tracer bullets to find the target.
Użyj pocisku smugowego do zlokalizowania celu. Jest to prostsze i łatwiejsze niż stosowanie żmudnych i skompilowanych obliczeń. Pocisk smugowy jest tani.
(AOP)

Keep knowledge in plain text
WIKI. Czysty test ma swoją moc. Łatwo się czytać, porównywać, obrabiać.
(Learn a text manipulation language., sed , awk)

Use the power of command shells.
Skrypty mają swoją moc. Poznaj możliwości swojego shell'a.
Naucz się go lepiej, korzystać ze skryptów kiedy tylko możesz. Minimalizują możliwość pojawienia się błędów i przyspieszają Twoją pracę. Są na wagę złota.
(bash, fishshell, gitshell

Use a single editor well
Zostań mistrzem swojego IDE. Poznaj skróty, stwórz template'y. Skonfiguruj go na własne potrzeby. To ma być Twój przyjaciel nie wróg. (IDE)
Przygotuj rodzaj formatowania w obrębie całego projektu. Kod musi zawsze wyglądać jakby pochodził od jednej osoby.

Fix the problem, not the blame.
Kod jest własnością wszystkich. Debuguj, napraw błąd nawet jeśli wprowadził go Twój kolega. Po prostu to napraw. Zrzucanie winny czy pretensje tylko pogorszą sprawę.

'Select' isn’t broken.
Nie doszukuj się błędu w poleceniu select. Autorzy SQL zrobili to dobrze raczej poszukaj błędów u siebie. To samo jest z javą. Czasem zwalasz na środowisko czy technologie ale w 99,8% wina leży po Twojej stronie czyli programisty.

Crash early
Wykrywaj błędy jak najwcześniej.
Stosuj throw w początkowych liniach metody.
Stosuj assert w stosunku do metod prywatnych.
Stosuj logi. Wszechobecne logi, zróżnicowane poziomami np debug , info , fatal.
Używaj nowoczesnych, sprawdzonych bibliotek jak logback, slf4j etc.
Jeśli jakiegoś procesu już nie da się uratować , przerwij go to zmniejszy potencjalną liczbę szkód.
(defensive programming)

Separate views from models.
Bez komentarza (MVC)

Sign your work
Podpisujesz się pod kodem stajesz się jego autorem. To jest dobry nawyk bo zmusza Cie do pisania lepszego kodu.
Kod anonimowy jest do niczego, każdy ucieka od odpowiedzialności. Co prawda informacje o autorze kodu wyciągniesz z repo (blame, scm) ale fajnie jak jest podpisany.

Refactor early, refactor often.
Refaktoryzacja to następna rzecz która jest nie do przecenienia.
Zwiększa higienę kodu, poprawia czytelność, sprawia , że praca z kodem nie stanowi przykrego obowiązku oraz przeciwdziała długowi projektowemu.
Postępuj według zasady: zostaw kod lepszy niż go zastałeś.
Posiadanie testów jednostkowych oraz zasada małych kroków to podstawowa zasady refaktoryzacji. Kolor zielony podczas testów, to to czego zawsze oczekujesz :) (design pattern, refactoring, code smells)

Design to test
Pisz kod aby można było go łatwo testować (DI)

Test your software, or your users will
Twoim obowiązkiem jest testować swój kod. Jeśli zrobią to za Ciebie użytkownicy zawsze bardziej Cie zaboli.
Stracisz więcej czasu na ich ponowne znalezienie. Testy mają być częścią wytwarzania (CI, xUnit)


Ciąg dalszy nastąpi :)




Brak komentarzy:

Prześlij komentarz