Rozpoczynając jak zwykle skromnie, powyżej pierwszy oficjalny lans video w moim wykonaniu. Prezentacja odbyła się w ramach jednego ze spotkań grupy miłośników Java w regionie Łódzkim.
Prezentacja jakaś wybitna nie jest : ja cały czas uczę się wysławiać i prezentować, koledzy uczą się nagrywać tak aby cokolwiek było widać i cokolwiek było słychać. Mowę ciała mam jeszcze zjebaną ale powinno dać się to oglądać. OTO przed wami:
Główna ideą prezentacji było uzmysłowienie wszystkim zebranym, że nie potrafią programować ;). Tak, jest to dosyć kontrowersyjne stwierdzenie ale bazując na obserwacjach, które cały czas przeprowadzam wydaje się być prawdziwe. Oczywiście ja również łapię się do zbioru "wszyscy zebrani" i jest to wbrew pozorom fantastyczna rzecz. W październikowym wydaniu "Focusa" była wzmianka o badaniach twierdzących jakoby najbardziej myliły się osoby nie mające kompletnie żadnego pojęcia o danym temacie, jak również osoby uznające, że w danej dziedzinie są spejcalistami. Jak to wszystko o czym tutaj wspominam składa się w logiczną całość prezentacji?
o co chodzi w programowaniu?
Dlaczego większość osób zajmujących się extremalnym użyciem klawiatury woli robić nowe projekty zamiast utrzymywać cudze? Niby jedno i drugie to przecież "programowanie". Utrzymanie jednak polega zazwyczaj na spędzeniu około dwóch tygodni na próbie zrozumienia jak działa dany kod a następnie na dodaniu kliku linijek. Ani programiści nie są z tego zadowoleni ani zapewne szare eminencje zajmujące górne warstwy korporacyjne. Przecież czas to pieniądz. Gdyby tak programista znał doskonale kod, z którym pracuje, to namierzenie miejsc wymagających wprowadzenia zmiany zajmowało by relatywnie odpowiednio zajebiście mniej czasu.
To o czym tutaj piszę na obrazku można zauważyć w czerwonym prostokąciku. Jest to meritum zrozumienia czytelności kodu, droga do zdobycia świętego grala wszystkich zespołów programistycznych i zapowiedź wolności emocjonalnej załóg działów utrzymania. Aby znaleźć wszystkie odpowiedzi na pytania odnośnie czytelnego kodu trzeba podróżować na granicy techniki i psychologii. Nie wiem czy kawałek prezentacji omawiający to zagadnienie będzie zrozumiały gdyż z tego co widziałem próbki kodu prezentowanego na tablicy są nieczytelne. Ale nawet jeśli to tylko zaproszenie do osobistego zgłębiania tematu. Interesujace hasła to : psychologia, percepcja, nlp, teoria pamięci i tym podobne.
No a jak już wiadomo co trzeba zrobić nadchodzi etap drugi, czyli faktyczna zmiana. Tutaj w grę wchodzą wszelakie wzorce pozwalające programiście wywrzeć duży wpływ na system stosunkowo małym kosztem
Dlaczego sama teoria nie wystarczy?
Efekt aureoli,Efekt halo ,błędy percepcyjne - ma to wiele określeń ale zawsze chodzi o to samo - "jest ładny to jest i mądry", "samochód jest czysty to się nie psuje", "towar ma ładne opakowanie i jest drogi to na pewno jest dobry", " w pracy mówią na mnie architekt to znaczy , ze dobrze programuję", "w pracy tworzę słynny portal X, który zarabia miliony to zanczy ,że dobrze programuję". nie, wcale tak nie znaczy .
- programowanie wielowątkowe
- programowanie obiektowe
- programowanie bazodanowe
- czytelne programowanie
Co mają wspólnego poszczególne pozycje na tej liście: ano obrazują one niezależne umiejętności.
Aby nabyć dana umiejętność trzeba podejść do tego wyzwania świadomie:
Weźmy takie programowanie wielowątkowe. Znam masę osób, które owego zagadnienia nie znają a kilka latek już kodują. Dlaczego nie znają? Bo byli skoncentrowani na czymś innym. Sam fakt, że tworzysz działające programy przez dłuższy czas, i że one działają wcale nie znaczy, że twoje programy są czytelne.
Dla osób zainteresowanych zdobywaniem nowych umiejętności : wpiszcie sobie w google "model TOTE"
Ostatnia część prezentacji to omówienie statycznej analizy kodu ale to temat na inny post.
