Jak często zastanawiasz się nad sposobem myślenia o problemie, który implementujesz?
Dlaczego posługujesz się tym sposobem? Czy robisz to świadomie?
Czy to, że był to ulubiony sposób myślenia o problemach twórcy danego języka programowania (pierwszego jaki poznałeś/poznałaś) i został przez tegoż twórcę "zamrożony" w składni języka jest wystarczającym powodem?
Autorka prezentacji zadaje wiele ciekawych pytań.
Od siebie dodam, że z obserwacji setek programistów i programistek wyłaniają się pewne wzorce. Generalnie każdy z nas ma pewne standardowe "modele wewnętrzne", których używa do wyobrażania sobie problemów:
- linijki kodu
- przepływ danych
- przepływ sterowania (np podane w prezentacji "rurki")
- kształty na płaszczyźnie
- ruchome kształty w przestrzeni
- itd
- zwięzłość - jeżeli myślisz linijkami kodu, to będziesz szukać zwięzłych języków, barokowa składnia przeładowuje Twą pamięć
- harmonia - jeżeli wyobrażasz sobie kształty (język będzie nieistotny - odwrotnie niż w poprzednim przypadku)
- znalezienie ogólnych modeli (np generalne klasy - oczywiście z masą statusów:) - jeżeli lubisz uogólniać
- znalezienie szczegółowych modeli (np. wiele osobnych klas) - jeżeli lubisz różnicować
- eksploracja słownictwa domenowego
- przejście w abstrakcje (np. mapy i operacje na kolekcjach zamiast operacji domenowych)
- itd...
Po latach zrozumiałem też, że próby oceny/krytyki kodu nie mają sensu, jeżeli posługujesz się innymi kryteriami estetycznymi niż jego twórcy.
Stawia to również pod znakiem zapytania Agileową wspólnotę kodu. Bo co jeżeli każdy, kto "udziela" się w danym fragmencie kodu chce dobrze ale każdy inaczej rozumie dobrze a przez to "ciągnie" design w swoją stronę? Powstaje to co zwykle... wielka... kupa... błota;)
Osobiście nie jestem teoretykiem języków tak jak autorka prezentacji, dlatego z najbliższym poście z serii DDD h4x przedstawię klasyfikację bazowych building blocks (bardziej ogólnych BB z DDD), które może wykorzystać z powodzeniem każdy, nie koniecznie stosując DDD jako takie.
2 komentarze:
Faktycznie, bardzo ciekawa prezentacja. Jej treść może być punktem wyjścia do wielu przemyśleń.
Stawiasz pytanie o świadomość posługiwania się konkretnym sposobem myślenia podczas rozwiązywania problemów. Ciekawi mnie tutaj teza przyswajania toku myślenia promowanego w danym języku jako "swojego". Jeżeli to co promuje konkretny język nie jest mniej lub bardziej kompatybilne z moim sposobem myślenia, to jaki ma to wpływ na moją skuteczność/wydajność?
Załóżmy taką sytuację - w pracy posługuję się językiem obiektowym a mój styl myślenia bardziej odpowiadałby programowaniu funkcyjnemu. Czy lepiej, żebym "naginał" składnie języka pod swój styl myślenia, idąc tym samym w kierunku "wielkiej kupy błota" (jeżeli inne osoby w zespole też postępowałby w ten sposób)? Czy też może lepiej, żeby "przymuszać" się do stylu w danym języku promowanego?
Można się też zastanowić jak fakt istnienia wielu sposobów myślenia wpływa na pracę w zespole. Przykładowo - dwie osoby pracujące wspólnie nad jednym zadaniem. Niech obie myślą zupełnie innymi "stylami". Dodajmy do tego odmienne style komunikacji - niech jedna z osób komunikuje się w sposób typowy dla "wzrokowca" a druga dla "słuchowca" - nieszczęście gotowe :)
Ciekawi mnie też kontekst nauki programowania. Na ile trudniej będzie komuś nauczyć się (przykładowo) języka, który nie będzie kompatybilny ze sposobem myślenia tej osoby. Mam tu na myśli osoby, które pasowałyby do poziomu "Novice" w modelu Dreyfus'a.
Przykładowo - studenci pierwszego roku informatyki, którzy wcześniej nie mieli styczności z programowaniem. Takie osoby mają dostatecznie dużo "problemów" do ogarnięcia, np. jakaś tam podstawowa wiedza dotycząca zarządzania pamięcią, czy obsługi wejścia/wyjścia. Do tego można dodać bardzo "życiowe" zadania, które trzeba czasem rozwiązywać na laboratoriach (w stylu narysuj choinkę na konsoli o podanej na wejściu wysokości, jeżeli podana wysokość jest liczbą parzystą to cośtam cośtam a jeżeli dzisiaj jest poniedziałek to cośtam cośtam). Jakby tego było mało to zadanie trzeba rozwiązać w sposób, który nie bardzo pasuje do stylu myślenia jakim dana osoba się posługuje (bo dany język promuje inne podejście).
Te wszystkie tematy możnaby długo drążyć. Podczas oglądania tej prezetancji przychodziło mi do głowy też wiele innych pytań. Tak więc bardzo fajnie, że podzieliłeś się tym linkiem jak i swoimi przemyśleniami z nim związanymi.
Dobre pytanie...
Co jest pierwsze: mój ulubiony styl myślenia i dobór języka czy może język, który zmienia styl myślenia?
Ja się nie znam, ale jak to zwykle bywa: pewnie sprzężenie jest obustronne. Problem może być na początku nauki programowania, gdy zmuszają Cię do pisania w czymś, czego nie czujesz... (Sam nigdy bym nie pomyślał o pracy jako programista, gdybym na 3. roku z ciekawości nie nauczył się na własną rękę Javy i nie dotarł do książek, które mi pasowały)
Tak jak piszesz: język programowania to szczegół w porównaniu z komunikacją z innym człowiekiem - nie mam tu na myśli opowiadania np. filmu a przekazania złożonych koncepcji z domeny problemu jak jakim pracujemy...
Co do nauczania, to od czasu gdy oglądałem prezentację na temat Khan's Academy (gościnnie Bill Gates: https://www.youtube.com/watch?v=gM95HHI4gLk ) utwierdziłem się w przekonaniu, że kluczowe jest dobranie typu (pod kątem osobowości) nauczyciela do typu ucznia. I technicznie jest to wreszcie możliwe po tysiącach lat błędów i wypaczeń:)))
Prześlij komentarz