Jak powinniśmy nauczać informatyki?

Oryginalny post: How Should We Teach Computer Science?

Autor: Jeff Atwood

Greg Wilson przesłał mi ostatnio e-mailem następujące pytanie:

Od stycznia wykładam inżynierię oprogramowania dla studentów 3-ciego roku na Uniwersytecie Toronto i chciałbym choć jedną godzinę poświęcić na wdrożenia -- [wdrożenia] nigdy nie pojawiły się na moich wykładach i są dość często pomijane w podręcznikach do inżynierii oprogramowania, a z doświadczenia wiem, że bywają one wyzwaniem niemniej trudnym jak samo napisanie aplikacji.

Wdrożenie jest wielkim problemem. Jest wyzwaniem nawet dla najlepszych zespołów programistycznych i jest niesamowicie ważne: jeśli użytkownicy nie mogą przejść przez fazę instalacji, to cały kod, który napisałeś, nie ma znaczenia! A wciąż, tak jak zaznaczył Greg, istniejące podręczniki do inżynierii oprogramowania pobieżnie traktują ten ważny temat. Podobnie, parę tygodni temu młodszy współpracownik powiedział mi, że nigdy nie uczył się o kontroli wersji na żadnych z zajęć na informatyce. Jak to możliwe? Kontrola wersji jest podstawą inżynierii oprogramowania.

Jeśli na uniwersytetach nie nauczamy fundamentalnych zagadnień z inżynierii oprogramowania, takich jak wdrożenia czy kontrola wersji, to nauczamy informatyki w zły sposób. Czym jest nauczanie pisania kodu w oderwaniu od rzeczywistości, jeśli nie możesz pracować nad tym kodem zespołowo w kontrolowanym środowisku oraz nie możesz wdrożyć wynikowego oprogramowania? Wielu absolwentów informatyki dowiaduje się tego z opóźnieniem, gdy znajdą się już w prawdziwej pracy jako programiści -- nie ma w tym nic dobrego.

Dzisiejsi studenci informatyki powinni rozwijać oprogramowanie w warunkach jak najbardziej zbliżonych do tych z prawdziwego świata albo przypominających takie. Każda linijka kodu powinna być pisana pod kontrolą wersji przez cały czas. To nie podlega dyskusji. Kiedy przychodzi czas wdrożenia, spróbuj to zrobić na współdzielony serwer komercyjny i dowiedz się wszystkiego, co ta czynność za sobą pociąga. Jeśli jest to aplikacja wykonywalna, stwórz samodzielną paczke instalacyjną, którą użytkownicy mogą ściągnąć, zainstalować, a następnie mieć dostęp do mechanizmu, za pomocą którego mogą raportować błędy, na które napotkają. Studenci powinni badać każdy nadesłany błąd w aplikacji, którą napisali.

Czy to będzie bolesne? O stary, zawsze takie będzie. Będzie potworne. Studenci znienawidzą to. Zaczną kwestionować to, dlaczego ktoś o zdrowych zmysłach chciałby pisać oprogramowanie.

Witamy w prawdziwym świecie.

Po tym jak odpowiedziałem Gregowi, Joel Spolsky zamieścił wpis o nauczaniu informatyki, który na moje oko wygląda zadziwiająco podobnie do rady, której udzieliłem:

Myślę, iż rozwiązaniem byłoby stworzenie BFA z tworzenia oprogramowania ze wzmożonym programowaniem -- Julliard dla programistów. Program studiów zawierałby zespołowe tworzenie nadających się do zastosowania w praktyce kawałków oprogramowania wraz z bardzo doświadczonymi nauczycielami oraz odrobinę zajęć ze sztuk wyzwolonych dla równowagi.

Kiedy mówię BFA, Bakałarz Sztuk Pięknych, mam na myśli to: tworzenie oprogramowania jest sztuką, a istniejący model nauczania informatyki, gdzie masz się nauczyć paru rzeczy o NP-zupełności oraz Quicksorcie, jest wybitnie nieadekwatny, jeśli chodzi o nauczanie studentów jak rozwijać oprogramowanie.

Wyobraź sobie natomiast program nauczania, który zawiera 1/3 sztuk wyzwolonych oraz 2/3 pracy związanej z tworzeniem oprogramowania. Nauczyciele to doświadczeni twórcy oprogramowania związani z branżą. Studia byłyby czymś w rodzaju firmy wytwarzającej oprogramowanie. Mógłbyś specjalizować się w wytwarzaniu gier i na przykład pracować nad konkretnym tytułem gry, i tak byś spędzał większość czasu, tak jak studenci filmówki spędzają dużo czasu na właściwym robieniu filmów, a studenci tańca spędzają większość czasu tańcząc.

Nie chodzi o to, aby wyrzucić teorię z programów nauczania informatyki. Fundamentalne pojęcia takie jak algorytmy i struktury danych są nadal ważne. Moje zajęcia z algorytmów były moimi ulubionymi i, co więcej, najbardziej użytecznymi zajęciami, na jakie uczęszczałem podczas studiów. Ale nauczanie tych rzeczy kosztem bardziej prozaicznych umiejętności z inżynierii oprogramowania -- umiejętności, których niesamowicie potrzebujesz jako praktykujący programista -- jest olbrzymią pomyłką. To jest to, do czego Steve Yegge czynił aluzję w jego fantastycznym wypracowaniu o Szkole Czarodziejów.. jak sądzę.

I tu jest problem -- wszystkie te napuszone stopnie naukowe z informatyki możnaby zdegenerować do czegoś w stylu szkół zawodowych, o czym wspominał Joel w swoim znakomitym przemówieniu na Yale:

W instytucjach z Ligii Bluszczowej wszystko jest o Unixie, programowaniu funkcjonalnym i o teoretycznych rzeczach na temat automatów skończonych. Idąc dalej, do mniej wymagających uczelni, zaczyna pojawiać się Java. Posuwając się dalej zaczynasz dosłownie dostrzegać zajęcia o tematyce typu Microsoft Visual Studio 101, 3 punkty zaliczeniowe. Do czasu aż dotrzesz do 2-letnich instytucji, zobaczysz kursy "certyfikacyjne" SQL-Server-w-21-dni, które są reklamowane w weekendy na kablówce. Czy to nie czas by rozpocząć karierę w (zmiana głosu) Java Enterprise Beans!

Można osiągnąć obie rzeczy jednocześnie. Dlatego jestem tak entuzjastycznie nastawiony do praktyk. Informatyka na uniwersytecie jest tak sucha i jałowa, że musisz poświęcić swoje wakacje na pracę w branży, inaczej nie posiądziesz niezbędnych umiejętności z zakresu inżynierii oprogramowania, których będziesz potrzebował, aby przetrwać po ukończeniu studiów. Nieistotne małe rzeczy jak, powiedzmy, kontrola wersji, wdrożenia czy zmaganie się z użytkownikami. Ciągle ględzę o praktykach, jak tylko spotkam studenta w pogoni za stopniem naukowym z informatyki. To dla Waszego własnego dobra.

Uderzająco niesprawiedliwe jest to, że studenci są zmuszeni polegać na praktykach, by dokończyć swoją edukację informatyki. Albo nawet coś o wiele gorszego. "Chcesz nauczyć się informatyki? Nie potrzeba uniwersytetu! Ściągnij tylko parę obrazów ISO i załóż swój własny startup w postaci portalu społecznościowego!" Wyzwolenie nagiej chciwości tłumu TechCrunch na wrażliwe programistyczne umysły zdaje się być całkowicie okrutne.

Tak więc, jak powinniśmy nauczać informatyki? Cynicy powiedzą, że tego się nie da zrobić. Myślę że to jest zrzucenie odpowiedzialności. Jeśli studenci chcą się przygotować na karierę w branży tworzenia oprogramowania, muszą pozbyć się teorii i spędzić znaczną część swojego czasu na tworzeniu oprogramowania ze wszystkimi jego brodawkowatowymi, kłującymi, niebędącymi żadnym wyzwaniem elementami. Połowa inżynierii oprogramowania to łagodzenie bólu. Jeśli nie przeklinasz co tydzień swojego dostawcy hostingowego, nie walczysz z systemem kontroli wersji każdego dnia, nie odszyfrowywujesz raportów błędów od swoich użytkowników co godzinę -- nie byłeś uczony informatyki.

Data publikacji oryginału: 12 stycznia, 2008

12 komentarze:

Tomasz Kowalczyk pisze...

I o to chodzi, nic dodać, nic ująć.

Anonimowy pisze...

Cóż, trudno się nie zgodzić...

Konradzik pisze...

Ja na studiach byłem zmuszony do tworzenia projektu używając systemu kontroli wersji. Co więcej, tym projektem było oprogramowanie w stylu tortoise. Jak sie można domyślić, napisanie czegoś takiego wymagało większego czytania niż poznanie 'svn up/commit/checkout'. I co? I w pracy jak pojawiły się branche, margowanie i problemy z properties i tak czułem się jak ostatni idiota. Musieli by nam chyba cały semestr z svna zrobić żebym się w tym czuł płynnie.

Co do algorytmów i struktur danych - jedno jest pewne, zmuszały do myślenia. A to jest zawsze dobre.

Praktyki a studia to dwie różne rzeczy. Na studiach, chcąc nie chcąc, kręcisz się w otoczeniu osób które Cię rozumieją, mają odpowiednią wiedzę i możesz prowadzić rozmowy na pewnym poziomie programistycznej/umlowej abstrakcji. Takie środowisko nigdy nie będzie symulować rzeczywistości. Jakkolwiek wspaniały byłby program studiów to i tak uważam, że bez praktyk się nie obejdzie.

Tomasz Kowalczyk pisze...

wydaje mi się to średnio trudne, ja po prostu pewnego dnia zostałem "zmuszony" [wcale nie siłą, po prostu projekt wymagał] wykorzystania svna w formie "od zera do milionera". zaraz po tym, jak nauczyłem się korzystać konsolowo [nic specjalnego, tak jak napisałeś, zwykłe "svn up/commit/checkout" w pakiecie sliksvn] zainstalowałem sobie tortoisesvn i zacząłem się zastanawiać jak to możliwe, żebym wcześniej nie korzystał z tak genialnego systemu. zacząłem testować wszystkie możliwości, czytać o różnych sztuczkach. dla mnie trudnością nie było nauczenie się obsługi, ale samo korzystanie z niego tak, jak wszyscy, czyli nauczenie się po prostu "standardu" tworzenia repozytoriów, wraz z drzewami "tags", "trunk", "branches" i zrozumieniem czy one są i do czego służą. po jednym z moich wpisów na blogu mogę powiedzieć, że chyba już opanowałem obsługę svna w stopniu "niezłym", ale zawsze jest przecież coś, czego [jeszcze] nie wiem.

BTW. OT: mam nadzieję, że zostanie wprowadzona niedługo funkcja svn obliterate, bo teraz to trochę kuleje. ;]

koziołek pisze...

Artykuł o tyle mądry, że dobrze oddaje braki w systemie edukacji też w Polsce. Gdy przychodzi do mnie osoba z tytułem inżyniera informatyki to nie wymagam od niej bycia bogiem. Wiem, że odpowiednich umiejętności i obycia nabierze "w boju". Przerażające jest jednak gdy człowiek taki robi wielkie oczy gdy zaczynamy rozmawiać o systemach kontroli wersji, serwerach CI czy narzędziach wspomagających.
Autor kładzie duży nacisk na kontrolę wersji. Ja powiem inaczej system taki jest tylko niewielkim, acz ważnym, elementem czegoś co można porównać z taśmą produkcyjną z której zjeżdżają aplikacje.
Z drugiej strony kierunki takie jak informatyka czy fizyka(moje rodzime podwórko) staja przed wyzwaniem wtłoczenia coraz to większej ilości wiedzy do głów studentów, a jednocześnie mają na to coraz mniej czasu. Gdy porównywałem kiedyś ilość godzin zajęć w trakcie całych studiów na wydziale fizyki z koleżanką z medycyny to wychodziło, jak byśmy nie liczyli, że jako fizyk robię w 4,5 roku tylko 100 godzin mniej niż ona przez 6 lat medycyny (u medyków nie ma w praktyce semestru wolnego na pisanie pracy). Trudno więc wkładać w plan jeszcze dodatki.

W tym miejscu należy wspomnieć o działalności "User Groups", czyli organizacji skupiających programistów w okół jednej technologii (Warszawa - Java User Group) czy zagadnienia (Warszawa Design Patterns User Group), których celem jest wzajemna wymiana doświadczeń i umiejętności. Grupy takie zazwyczaj organizowane są przy wydziałach informatyki co pozwala na uczestniczenie w ich pracach zainteresowanych studentów. Rzecz tylko w tym, by studenci trafili w miarę szybko pod opiekę praktyków. Ci z braci akademickiej, którzy czują powołanie do tworzenia oprogramowania szybko odnajdą się w takiej grupie. Ci co poszli na informatykę dla kasy lub szpanu... niech ich /dev/null pochłonie

pozdrawiam Koziołek

Tomasz Kowalczyk pisze...

"Ci co poszli na informatykę dla kasy lub szpanu... niech ich /dev/null pochłonie."

Amen++. Oczywiście chodzi o szpan, bo w końcu kiedyś trzeba się będzie z czegoś utrzymać, więc kasa się trochę liczy. Ale zawsze powinno się mieć szczere podejście do tematu.

Anonimowy pisze...

Nie no jasne, zrobic przedmiot o svn, i co roku zmieniac program - co aktualnie w temace kontoli wersji na rynku piszczy, a od nowego semetru poznajemy mercuriala. Skonczyles szkole i nie znasz hudsona!!?? Moze w poniedzialki cotygodniowy przeglad nowosci na sourceforge.

rafek pisze...

@Anonimowy: Nie przedmiot o SVNie jest potrzebny. Takie rzeczy mogą być poruszane na przedmiocie typu "inżynieria oprogramowania" (i temu pochodne). Udział w projekcie z użyciem systemu kontroli wersji (jakikolwiek by on nie był). To czy nauczysz się kontroli wersji na SVNie w wersji X czy Y nie ma najmniejszego znaczenia. Idea jest z grubsza ta sama, niezależnie od tego jakiego systemu kontroli wersji używasz.

Anonimowy pisze...

Jakiś czasem również wyraziłem opinię o systemie nauczania oraz studiach:

http://blog.y3ti.pl/2009/12/studia-nie-sa-ci-do-niczego-potrzebne/

Anonimowy pisze...

Wszystko pięknie ładnie tylko tytuł nie ten bo to nie nauka informatyki a rzemiosła, pytanie brzmi kogo ma dać na wyjściu dana uczelnia/szkoła/kurs

Anonimowy pisze...

Artykuł trafiony. Problemem jest jednak sam system edukacji od podstaw. Zapewne, niewiele się pomylę gdy określę, że 95% wykładowców Informatyki jest jedynie teoretykami książkowymi. Ich wiedza to na ogół doświadczenie wyczytane z książek o jakimś kompilatorze. Ewidentnie to widać było na wykładach Turbo Pascala, C, C++ czy Visual "coś tam".. A w końcowym efekcie, to poza podstawową biegłością MS Office, niewiele było obszarów w których mogli zabłysnąć.
Może obecnie coś się zmienia, bo na stanowiska wykładowców z informatyki, powoli zaczynają wchodzić ludzie, którzy mieli styczność z programowaniem... Choć to też być może na wyrost, bo programowaniem nie można nazwać pisanie witryn internetowych obsługiwanych php... Ale to zawsze ciut większe doświadczenie niż tylko wyczytana wiedza z książek o programowaniu.

Anonimowy pisze...

A ja mam jeszcze inną refleksję do tego oto zdania: "Jeśli nie przeklinasz co tydzień swojego dostawcy hostingowego, nie walczysz z systemem kontroli wersji każdego dnia, nie odszyfrowywujesz raportów błędów od swoich użytkowników co godzinę -- nie byłeś uczony informatyki. "

Tak panowie i panie, dokładnie tak. Jeżeli dopiero chcecie iść na informatykę, to się DOBRZE zastanówcie. Zastanówcie się, czy chcecie grzebać godzinami w jakimś syfiaście napisanym kodzie, poprawiać czyjeś błędy (najpierw ich szukając), czy chcecie planować sobie wykonanie czegoś 'na dany dzień' a potem raz po raz utwierdzać się, że coś takiego jak dokładny plan czasowy nie istnieje. INFORMATYKA JEST FRUSTRUJĄCA! Pomyślcie 2x zanim wybierzecie takie zawodowe życie...

Prześlij komentarz

Related Posts with Thumbnails