środa, 18 grudnia 2013

Oceń się sam...i sprawdz co wiesz część 1

Wiele programistów uważa - " kurwa ale jestem dobry ".
Piszę zajebisty kod. Wszystko prawie działa a najwięcej działa u mnie :)
Kod jest tak dobry, fajny i w ogóle , że .....
Jest jeden problem, niestety muszę go utrzymywać i tylko ja uważam, że kod jest piękny.
Czasem uda się coś napisać nawet szybko wystarczy miesiąc, dwa miesiące na całkiem spory i złożony system.


Wykorzystałem nawet nową wersję Javy, .neta czy innego chłamu, mam nawet dobry serwer, zajebistą bazę oracle 11 i cokolwiek jeszcze .
Ale czy to wystarczy? 
Teraz zadaj sobie pytanie: czy przejąłbyś chętnie system pisany przez innych - potencjalnie kolegów ?
Dla mnie odpowiednim miernikiem jest to, czy ktoś inny chętnie wykorzystuje moje API, funkcjonalność, moduł .

Jeśli stosujesz się do zasad SOLID i GRASP masz duże szanse, że Twój kod będzie dobry, a kolega chętnie przejmie Twój kod i będzie z nim sprawnie pracował .

Jeśli jeszcze dodasz testy będzie super :), dlaczego ? - bo test nie dość, że sprawdzą funkcjonalność to jeszcze będą najlepszą dokumentacją . Napisane w BDD pomagają także zrozumieć przypadki użycia.
Poza jest jeszcze jedno o czym powinieneś już teraz wiedzieć .
Dług projektowy (technical dept) - bierze się stąd, że nie wprowadzany odpowiednich zmian, pielęgnacji kodu , oraz usprawnień w następnych iteracjach procesu wytwarzania. Teraz wprowadzamy pojęcie refaktoryzacji (refactoring) -  w skrócie zmieniamy strukturę kodu bez zmiany jej funkcjonalności. Tylko następny problem - refaktoryzacja nie działa bez testów:)
Tzn można chwalić się , zrobiłem refaktoring jakieś funkcji czy klasy ale to jest podeście nie pełne.
Pierwsza zasada refaktoringu - refaktoryzuj tylko kod pokryty testami i spodziewaj się zielonego na ekranie :)

Następne pytanie czemu chętnie używasz np Springa czy podobnych frameworków ?
Odpowiedź jest następująca : bo mają dobre API , wysoki poziom abstrakcji i bazują na interfejsach.

Zapytany kiedyś na konferencji  James Gosling (twórca java) co zmieniłby  jakby miał jave napisać od nowa opowiedział - wyjeb.... klasy :)

Jakiś czas temu sam zauważyłem , że mój najlepszy kod z którego mogę być w jakiś sposób dumny - to czysta abstrakcja.
Dzięki temu dany moduł mogę wykorzystać wielu projektach i doskonale się do nich integruje - oczywiście dzięki DI . (czytaj : DI + GRASP + SOLID = 80% sukcesu)

Recepta :



Teraz pytanie co zrobić aby to poprawić ?
Edukacja..

Teraz czasy się zmieniły. Dostęp do internetu jest tani i powszechny.
Książki też nie kosztują majątku. Konferencje są często darmowe.
Wewnątrz firm teamy mogą tworzyć warsztaty.




Craftsmanship - wiesz co to jest ?  - to zainteresuj się .
A o to jego manifest :


1. Nie tylko działające oprogramowanie, ale również dobrze napisane oprogramowanie
2. Nie tylko reagowanie na zmiany, ale również ciągłe zwiększanie wartości
3. Nie tylko osoby i interakcje, ale również społeczność profesjonalistów
4. Nie tylko współpraca z klientem, ale również produktywne partnerstwo
Poznajesz te hasła ?
A może skojarzysz te : 
   - Cały czas doskonal swój warsztat
   - Lepiej zapobiegać niż leczyć.
   - Zły szelong zawsze wraca
   - Niezależnie jak piękny jest dom bałagan na biurku psuje wrażenie


Bardziej radykalne podsumowanie : 

Lepsze jest niedziałające programowanie ale dobrze napisane niż działające ale oderwane od wszelkich norm i zasad projektowych , ponieważ z tym pierwszym da się coś jeszcze zrobić natomiast drugie nadaje się co najwyżej do kosza
(trudno się  z powyższym nie zgodzić ale jak to wytłumaczyć dla biznesu ? )

To jest sprytna modyfikacja manifestu Agile :)

Następne pytanie czy Ty lub Twój Team wytwarzanie w duchu Agile ? - zastanów się dwa razy za czym powiesz tak :)

Craftsmanship zdobywał szybko popularność na zachodzie, tam już nie liczy się działające oprogramowanie, ale też produkt wysokiej jakości. Coś co jest określane terminem Clean Code (Uncle Bob mówi Ci to coś ?)

Czy w Twojej firmie spełnione są jakiekolwiek standardy , dobre praktyki itd ?
Teraz mógłbym wymienić z tuzin książek, które warto być przeczytał abyś ogarnął w jakimś stopniu temat by przejść do dalszej lektury.

Zadaj sobie następne pytanie : 

wychodzą nowe wersje  javy  : 1.4, 1.5 ... teraz 1.8
Czy potrafisz wymienić  features z każdej z wersji ?
np :
-  java concurrent ? - po co to jest, na co pozwala i co ułatwia, czemu to taki przełom w wielowątkowości ?
Przecież java została wymyślona jako programowanie sieciowe.

- Generics (np kiedy extends a kiedy super )?
- Try-with-resource ?
- NIO 2 ?
- Fork&Join ?
- Invokedynamic ?
- G1 ?
- czy teraz lamba w 1.8 ?

Dochodzą do tego biblioteki , które każdy dobry programista javy ma obowiązek znać (w kolejności od najważniejszej w moim przekonaniu ):
- GUAVA ?
- AOP (AspectJ) ?
- JODA TIME , MONEY ?
- LOMBOK ?
- LOGBACK ?
- SLF4J ?
- GSON ?

Testujemy :
- MOCKITO ?
- HARMCREST ?
- FEST ASSERT ?
- SELENIUM ?
- ConcurrentUnit ?
- Spock ?
- GRINDER ?
- JMETER ?
- Cucumber?
- PIT ?
- JBehave ?
- DB Unit ?
- SQL Unit ?

Dorzucam pojęcia : 
- EIP ?
- DI ?
- SOA ?
- TDD ?
- BDD ?
- DDD ?
- REST ?
- WS ?
- CI ?
- CD ?
- Clean code ?
- Refactoring ?
- JBPM ?
- Design Pattern (tych nie wymieniam bo zabrakło by dnia) ?
- Nosql ?
- MapReduce ?
- ORM ?
- Immutable ?


W książce pt : Pragmatic thinking and learning dowiadujemy się o modelu braci Dreyfus.

Możemy odbyć  podróż od adepta , początkującego w sztuce programowania na samą górę tej drabiny czyli do eksperta w danej dziedzinie.
Bracia opisali pięć poziomów doświadczenia. Poniżej moja interpretacja.
(Dreyfus model)

1. Novices (Począkujacy)
Jak sam tytuł mówi nie masz doświadczenia lub masz je niewielkie.
Fajny przykład podali autorzy : developer, który rzekomo twierdzi , że na 10 letnie doświadczenie , ale w rzeczywistości było to roczne doświadczenie ale powtórzone 9 razy. Więc nie liczy się to jako doświadczenie.

Inaczej:)
Hipotetycznie przychodzi facet do stolarza i mówi :
'Mistrzu mam 8 lat doświadczenia w bijaniu gwoździ w deskę '
Co odpowie na to stolarz ?.
Odpowie tak : 'chu...mnie obchodzi, że wbijałeś  8 czy 10 lat te pieprzone  gwoździe w jakąś dechę..
Jak dla mnie masz 2 tyg doświadczenia. W tej materii jak dla mnie nic więcej  już się nie nauczysz.'
Trudno się z tym nie zgodzić. Podobne zjawisko występuje w programowaniu. 
Przykład ze stolarzem jest może nieco przesadzony ale czasem lepiej walną z grubej rury, żeby do niektórych dodarło co robią.

Żeby coś zrobić dobrze muszą mieć podaną recepturę. (Novices need recipes)
Może wykonać pewne zadanie ale ktoś go musi prowadzić . Początkujący nie ma szerszej świadomości kontekstu ani problemu jakie może napotkać w swoim zadaniu.

2. Advanced begginer (Zaawansowany początkujący)
  Jest już lepszy w tym co robi. Potrafi znaleźć sobie potrzebne informacje o danym API. Nadal nie rozumie szerszego kontekstu. Ktoś musi podpowiadać mu rozwiązania. Często kopiuje rozwiązania już istniejące w kodzie, nie jest potrafi powiedzieć dlatego to właśnie tak ma być.

Przykład z życia.
Na początku swojej przygody zawodowej pracowałem z jednym zespole z obcokrajowcami. Nie istotne jakiej narodowości. Np nie hindusi, bo tych to w ogóle nie wiem do jakiej kategorii zakwalifikować;)

W każdym razie tamci mieli robić jakąś warstwę pomiędzy frontendem a backendem, która tak naprawdę nie była nikomu potrzebna. Nazwijmy ją adapterem. Goście mieli bogate CV, kilkunastoletnie doświadczenie jeszcze wywodzące się z cobola, bo wtedy nawet java nie istniała.

Podsumowując, śmieliśmy się z nich, że u nich jest taka charakterystyka:
im większe doświadczenie tym gorzej bo zdążyli przez ten czas więcej zapomnieć;)
(Advanced begginers don't want the big picture) 

3. Competent (kompetentny)
Ma nastawienie na konkretny cel i wie jak go osiągnąć. Jego praca opiera się bardziej na celowym planowaniu i doświadczeniu z przeszłości. Wypracowuje swój sposób działania który potrafi skutecznie wdrożyć. Stosuje się do porad ekspertów , posiada zdolność incjatywy i jest zaradny.
To co wcześniej sprawiało problemy teraz idzie to znacznie lepiej.
Może już być mentorem dla początkujących i nie drażnić ekspertów.
Jego rozwiązania pomimo , że nie są do końca idealne -  działają.
Dobrze posiadać takich ludzi w swojej drużynie. 
Generalnie nie chce wysilać się za bardzo (samodoskonalenie, edukacja) dlatego ciężko mu będzie wejść na następny poziom.
(Competents can troubleshoot)


4. Proficient (doświadczony) (need the big picture)
Jest już na zupełnie dobrym poziomie. Posiadł biegłość w danej dziedzinie.
Ma duże chęci do nauki . Potrafi znajdywać analogie do innych procesów.
Potrzebuje znać też cały kontekst.
Według autorów jest po poziom na którym osoba powinna skutecznie używać wzorców projektowych co niekoniecznie udaje się osobom na niższych poziomach.
W poprzednich poziomach osoba ma "błogi spokój" . Tutaj nawet po pracy intrygują go pytania i problemy z którymi na cały czas styczność.
Ciągle zadaje pytania : np czy warto persystować dane w bazie nosql, a jak tak to dlaczego ?
Ma poczucie że nic nie wie - to jest idealny przykład tego poziomu.
Proficient to ogromny przeskok jakościowy z poprzednim poziomem.
(Proficient practitioners can self-correct)


5. Expert (ekspert)
Główne źródło wiedzy i informacji na każdym polu. Zgromadził prawie kompletną wiedzę z danej dziedziny.
Wystarczy , że spojrzy i już poda receptę na lepszą metodę lub drogę zrobienia czegoś.
Taki ktoś często pisze książki , artykuły itd. Jest określany jako współczesny czarodziej - alchemik.
Widzi szeroki kontekst i działa intuicyjnie, bardzo szybko znajduje analogie do innych dziedzin. Myśli zawsze abstrakcjami. Konkretne klasy dla niego mało się liczą. Stosuje metafory. Często zdarza się tak , że nie potrafi argumentować swoich decyzji, a rozwiązania rodzą się same w głowie.
(Experts work from intuition)

 Ja dodałem jeszcze od siebie jeden poziom Guru. 
Na tym poziomie się nigdy nie znajdziesz. Guru jest odpowiednikiem Boga w programowaniu , wyznacza nowe trendy i tworzy kierunki rozwoju.


Czytaj dalej a dowiesz się więcej. Na wstępie będzie trochę  jak być  pragmatycznym i jakie korzyści z tego wynikną dla Ciebie i Twojej firmy.

dalej ->

Brak komentarzy:

Prześlij komentarz