Witam, z tej strony Mirosław Zelent. Post niniejszy zawiera wyjaśnienie czym są i po co istnieją wątki typu Code Reviews na tym forum. Wątki te, jak zapewne zauważyliście dotyczą głównie kodów źródłowych z realizowanych przeze mnie odcinków na YouTube. Zanim zapostujesz/skomentujesz coś w Code Review, warto abyś zapoznał się z tym, co zapisałem poniżej (wszystkie linki otworzą się w nowych kartach):
1. Dlaczego Code Review jest w ogóle potrzebny? Czy kod z odcinka nie powinien być idealny?
Oczywiście, że kod nie powinien być idealny składniowo (semantycznie), bo wówczas odcinek straciłby wiele na jakości dydaktycznej! Celem kodu z odcinka jest przekazanie ustalonego, konkretnego zakresu wiedzy, a nie stworzenie tzw. czystego kodu. Jeżeli wiesz cokolwiek na temat dydaktyki, to nie trzeba nic dalej wyjaśniać, ale pozwól że zobrazuję o co chodzi na przykładach (tak jest najłatwiej to zrozumieć).
Przykład #1
Fakt: Odcinek pierwszy kursu C++ zawiera kod źródłowy ze wszystkimi zmiennymi globalnymi. Ergo: kod nie jest czysty.
Powód dydaktyczny: W odcinku pierwszym kursu C++ uczeń ma zrozumieć m.in. pojęcie zmiennej, kompilacji, oswoić się z IDE, oswoić się z Hello Worldem, dokonać pierwszych operacji na danych, nauczyć się operacji wejścia/wyjścia, podstawowych typów danych. Celem odcinka nie jest mówienie o zasięgu zmiennej! Mówienie o zasięgach ma sens dopiero po wprowadzeniu i zrozumieniu pojęcia własnej funkcji (co nastąpi dużo później, dopiero w odcinku 9 kursu). Nasz uczeń jeszcze nawet dobrze nie poukładał sobie w głowie czym jest zmienna, a jest to pojęcie abstrakcyjne i wymaga ułożenia się w głowie. I dlatego wysoce szkodliwym (z dydaktycznego punktu widzenia) byłoby tłumaczyć mu na tym etapie kursu czym jest zasięg zmiennej, czyli tłumaczyć mu różnicę między zmienną lokalną a globalną. Zresztą jak to miałoby wyglądać? - "gdyby była tu druga funkcja i gdyby w tej funkcji była zmienna i gdybyśmy chcieli jej użyć w main(), a main to też funkcja (ale główna, ona wywołuje inne funkcje, które mogą na różny odbierać wartość), to ona przesłoniłaby wartość w tej zmiennej" - reakcja kursanta to najczęściej: "Sorry, ale nie kumam!"
Za dużo wiedzy naraz staje się niestrawne i sprawia, że uczeń odnosi wrażenie, że: "tego jest za dużo, nie rozumiem" - zniechęcasz go tym samym do nauki, zamiast zapalać pasją i powoli wprowadzać w arkana. Nie kładź na kimś takich ciężarów, których sam nie potrafiłeś unieść na jego etapie nauki! A inna rzecz, że zasięgu i tak uczeń nie zrozumie na tym etapie swojego doświadczenia - co najwyżej zapamięta definicję pamięciowo (i to tylko jeśli jest uparty i się nie zniechęcił), ale i tak nie zrozumie implikacji płynących z tej wiedzy na tym etapie - więc po co zaprzątać tym teraz jego głowę? Dydaktyczne uproszczenie ma sens - jest realizowane świadomie i w trosce o harmonijny rozwój kursanta. Podobnie zarzut, że stosowanie zmiennych globalnych wyrobi złe nawyki nie ma racji bytu, bo nie nastąpił tu w ogóle wybór kursanta - używał wszystkich zmiennych globalnych nie będąc świadomym zasięgu, ale kiedy w dalszych odcinkach udzielono mu już wyjaśnienia (bo w dlaszych odcinkach jest już sens i baza u kursanta aby o tym mówić), to zaczyna używać zasięgu świadomie - tak w funkcjach, jak w przekazywaniu przez wartość, referencję i potem w klasach. Podobnie twierdzenie, że ktoś zapisze zmienną z przyzwyczajenia jako globalną jest naiwne - bo jak to miałoby niby wyglądać? "Tworzę klasę, ale doh! po co mam specyfikować zasięg, oleję wszystko czego się nauczyłem, bo nie myślę". Więcej wiary w ludzi!
Przykład #2
Fakt: Odcinek drugi kursu HTML nie posiada żadnych tagów HTML5. Ergo: kod nie jest czysty.
Powód dydaktyczny: Za wcześnie na tagi HTML5. Uczeń w tym odcinku stara się zrozumieć dychotomię tabele vs divy (coś, czego wiele osób do dziś w sieci nie rozumie), a ty chcesz mu jeszcze w tym samym odcinku kłaść na barki zrozumienie tagów HTML5? To za duży ciężar, za dużo naraz - stracisz kursanta, bo zniechęcisz człowieka przytłaczającą ilością materiału. Uczeń musi zbudować co najmniej kilka struktur opartych tylko na divach, żeby dobrze stosować float:left, clear:both, position:absolute, position:fixed i tak dalej. Natomiast oczywiście nic nie stoi na przeszkodzie, aby zrobić Code Review dla osób, które już dawno znają dychotomię div vs table i chcą pójść dalej - a nawet dla czystej przyjemności nauki/rozwoju przepisać kod do HTML5. Chcą to też zrobić z innego powodu: z powodu dbałości o przestrzeganie standardów w sieci! I ta chęć jest czysta i szlachetna. Uczniowie już na tym etapie kursu mogą chcieć już przecież co nieco opublikować w internecie. Tym bardziej, że odcinki HTML nie wychodzą co tydzień, a raczej co kilka tygodni. I stąd właśnie Code reviews - dla osób, które mają ochotę zastanowić się nad optymalnym kodem dla przykładu z odcinka - ale optymalnym semantycznie i składniowo, a nie optymalnym dydaktycznie.
2. W moich materiałach dydaktycznych reprezentuję taksonomiczne podejście dydaktyczne oparte na rozwinięciu myślenia technicznego u kursantów, w tym także najtrudniejszej sztuki oceny własnych stworzonych już rozwiązań. I dlatego z premedytacją używam wielu starszych technik w pierwszych epizodach serii po to, aby po wprowadzeniu w kolejnych odcinkach nowej techniki uczeń mógł samodzielnie porównać jak spisywało się poprzednie podejście w porównaniu do nowego - nic nie zastąpi samodzielnego doświadczenia (empiryzm) i nauki przez refaktoryzację kodu. Więcej o tym podejściu mówiłem w tym podcaście: LINK. Proces uczenia to ciągła optymalizacja, w której na początku największy nacisk kładziemy na dydaktykę i prostotę, a dopiero w późniejszym etapie nauki ciężar przesuwamy na poprawność składniową / najnowsze techniki / czysty kod. Jeśli ten środek ciężkości za wcześnie przesuniemy ku semantycznej poprawności to stworzymy kurs niestrawny dla adeptów, zbyt hermetycznie napisany.
3. Code Reviews nie mają na celu obrażania mojej osoby / statusu / dorobku zawodowego / umiejętności koderskich. Młody adepcie programowania, "świeży" forumowiczu - proszę, nie zarzucaj przypadkiem obecnym na forum użytkownikom takiej postawy (no chyba, że rzeczywiście tak by się działo). Jako programiści reprezentujemy podejście merytokratyczne - interesuje nas CO powiedziano, a nie KTO to powiedział. Po prostu kochamy kodować i interesuje nas znalezienie optymalnego rozwiązania problemu lub najpiękniejszego zaimplementowania jakieś funkcjonalności - tylko tyle. Od czasów pierwszych maniaków, pierwszych hackerów pokroju Steve'a Wozniaka czy Richarda Stallmana - interesujemy się po prostu odpowiedzią na pytanie: "jak można to zrobić najlepiej?". Mamy taką część umysłu, która domaga się odpowiedzi na to pytanie. Samo słowo hacking - (ang. to hack) oznacza dla nas co innego niż większość ludzi myśli. Manifest hackera mówi: moją zbrodnią jest ciekawość. I to jest prawda. Wierzymy w jakość informacji, nie w jakość autorytetu. Wierzymy, że informacja powinna być wolna, dostępna dla każdego kto chce się uczyć. Dzielimy się wiedzą za darmo i wiemy, że to dzielenie się nie jest grą o sumie zerowej. Robimy to co robimy z pasji! I dlatego to właśnie takie techniczne, merytokratyczne społeczności przyczyniły się do powstania idei Wolnego Oprogramowania czy Open Source.
4. Kursy mogą zawierać błędy merytoryczne, a nawet także na płaszczyźnie dydaktycznej. Nigdy nie twierdzę i nie będę twierdzić, że jestem nieomylny. Jako jednostka jestem w pełni świadomy własnych ograniczeń - czasem niewiedzy, czasem ignorancji, czasem lenistwa, ślepoty poglądowej czy pychy. Ale jestem tylko człowiekiem i nie wstydzę się tego. Wręcz przeciwnie - Code Reviews uważam za dobry materiał do autorefleksji - autor kursu nigdy nie posiada świeżego spojrzenia na swoje dzieło i tak jak programista musi się cały czas rozwijać, tak samo nauczyciel musi szukać nowych podejść / punktów widzenia / perspektyw. I jeżeli nawet popełniam błędy, bywam opacznie rozumiany, czasem nawet obrażany to wierzę, że to co robię ma sens i że owoce tej pracy są dobre. Andrew Carnegie pięknie powiedział: As I grow older, I pay less attention to what men say. I watch what they do. Code Reviews dają mi nowe wnioski do dalszej pracy i dziękuję za wszystkie merytoryczne wpisy!
5. Tak kursy na YouTube, jak i wypowiedzi ludzi w Code Reviews dostarczone są na zasadzie delivered as is. Jesteśmy tylko jednostkami i każdy z nas myli się stosunkowo często i gęsto, mimo że tego nie chce i jego intencje są czyste. Ale pamiętaj: jako programista to Ty sam odpowiadasz za jakość swojego kodu, nikt nie weźmie tej odpowiedzialności za Ciebie! I tak dostarczamy wiele dobrego contentu w sieci, a nasze uzyskiwane zasięgi pokazują tylko jak wielu ludzi znajduje w tym pomoc, jak również własny w tym udział. Sami jako jednostki tworzymy tylko rzeczy dobre. Jako Społeczność tworzymy rzeczy świetne, ale nikomu nie dajemy gotowców! Włącz myślenie, przestrzegaj zasad, nie trać niepotrzebnie naszego czasu! Jesteśmy tu po rozwój i z pasji. Nie pozwól, aby nasze osobiste ograniczenia i naturalna jałowość dyskusji zakłóciła proces trenowania otwartego systemu, jakim jako człowiek jesteś. Nie zakopuj talentu w ziemi z powodu ograniczeń interpersonalnych - nad nimi też można pracować i je także możesz trenować i rozwijać na forum.
6. Życzę Wam moi drodzy owocnej nauki / weryfkacji koderskiego playbooka / dystansu w dyskusjach / rozwoju, rozwoju, rozwoju (po trzykroć, a co tam). Niezmiernie się cieszę, że te wątki powstały i że możemy wspólnie pochylić się nad przykładami dydaktycznymi, które kiedyś przygotowałem.
Przejdź do: pełnej listy dostępnych Code Reviews
