Uczelnia jest ważna. Student przychodzi z niewielką wiedzą i w trakcie studiów informatycznych zaczyna powoli wszystko rozumieć – dorasta do bycia programistą. Trzeba jednak uważać i nie jeść wszystkiego, czym karmią wykładowcy. Jest to zadanie trudne – bo kogo słuchać, jeśli nie wykładowców? Najpierw posłuchaj mnie, skoro już tutaj trafiłeś. ;-) Na końcu wrócę do tego pytania i postaram się odpowiedzieć.
Ten wpis kieruję do osób, które jeszcze studiują i nigdy nie pracowali w firmie wśród doświadczonych developerów.
UML, ISO, TQM gwarancją jakości oprogramowania
UML to mainstream na uczelniach. Każdy student wie, że dobry projekt i twardy proces to gwarancja wykonania najlepszego oprogramowania. Zespoły należy dzielić na analityków, projektantów, architektów, programistów i testerów. Użycie konkretnych wzorców projektowych planuje się już na etapie modelowania.
Proces wytwarzania oprogramowania oraz jego utrzymywania trzeba normować, aby mieć gwarancję jego najwyższej jakości. Dlatego powstały różne normy ISO albo TQM. Zaś diagramy w języku UML to wspólny język programistów i klientów.
Nawet jeśli z ust wykładowców pada czasami słowo agile, nie ma ono takiej siły przebicia, jak ciężkie metodyki. Student rzadko usłyszy, że dzięki zwinnemu procesowi wychodzi lepszy software, a gwarancją jakości są: ścisła współpraca z klientem, testy jednostkowe z dobrym pokryciem i działający serwer ciągłej integracji.
Singleton – świetny wzorzec projektowy
Singleton to świetny wzorzec projektowy, który gwarantuje istnienie tylko jednej instancji obiektu. Gdy ten student pójdzie do pracy, zacznie pisać własne singletony. Okazuje się potem, że taki kod trudno testować jednostkowo. Nic dziwnego, skoro wewnątrz różnych klas umieszczone są na stałe wywołania typu Database.getInstance().
Student nie zawsze usłyszy, żeby zamiast singletona wykorzystać kontener wstrzykiwania zależności, a wszystkie zależności definiować jako parametr konstruktora.
Bird extends Animal, to jasne
Ptak jest zwierzęciem, więc całkowicie jasne jest, że klasa Ptak powinna rozszerzać klasę Zwierzę. To typowy, akademicki przykład.
Dziedziczenie wielobazowe powinno się znajdować w każdym języku programowania. Ograniczenie wprowadzane przez dziedziczenie jednobazowe to tylko uproszczenie twórców języków, aby łatwiej pisało się im kompilatory.
Nie spotkałem się, by radzono studentom programować interfejsami, a nie implementacjami (code for interfaces, not implementations). Nikt na uczelni mi nie powiedział, aby najpierw rozważyć kompozycję zamiast dziedziczenia.
Komentarze w kodzie
Wśród wykładowców raczej panuje przekonanie, że wysoki stosunek liczby komentarzy do ilości kodu świadczy o dobrym projekcie. Potem student idzie do pracy i myśli, że komentowanie naprawdę jest ważne, w efekcie czego kod wygląda tak:
class Site {
/**
* Właściciel tej strony.
*/
private final Person owner;
/**
* Ta metoda znajduje największy wspólny dzielnik dwóch liczb.
*
* @param a
* @param b
* @return
*/
public int fi_nw(int a, int b) {
// ...
}
}
Wykładowcy chyba nie czytali Clean Code Boba Martina lub Test-Driven Development Kenta Becka. W bibliografiach slajdów najczęstszymi pozycjami są stare książki zasłużonych profesorów wychwalające UML, twarde procesy wytwórcze i “dobrze” udokumentowany kod.
KISC – Keep It Stupid Complicated
Wykładowcy najczęściej lubią rozwiązania przekombinowane. Musisz się namęczyć, aby zasłużyć na ocenę. Proste, sensowne rozwiązania nie wchodzą w grę.
Sieć komputerowa w trzyosobowej firmie z branży księgowości musi mieć cztery różne routery, dwa poziomy firewalla, switch zarządzalny, serwer www w strefie DMZ, dwa serwery kopii zapasowej i serwer bazy danych odcięty od Internetu. Proste i dobre rozwiązanie z jednym switchem i jednym serwerem na firewall, a drugim na bazę i backup jest niedopuszczalne. Biuro księgowe potrzebuje profesjonalnych rozwiązań.
Program do tagowania plików na dysku powinien działać na bazie Microsoft SQL Server. SQLite to rozwiązanie nieeleganckie i prostackie.
Aplikacja internetowa na zaliczenie projektu nie może zostać napisana przy użyciu jakiegokolwiek frameworka PHP. Użycie jQuery również jest zabronione. Po co pisać elegancki, wysokopoziomowy kod?
Potem najczęstszym grzechem studenta, który przychodzi po studiach do pracy jest łatwość, z jaką przychodzi mu utrudnianie sobie życia. Wszystko chce sam implementować oraz wprowadzać niepotrzebne rzeczy. Pamiętaj o KISS i YAGNI.
Napisz i wyrzuć
Wydaje mi się, że problemem jest sposób prowadzenia projektów. Student otrzymuje zadanie – dla zobrazowania sytuacji niech będzie to napisanie aplikacji, wykorzystującej Java Persistence API. Nadchodzi termin oddawania projektu – student przynosi program i go prezentuje. Prowadzący sprawdza, czy wszystko działa, jak należy i wystawia ocenę. Najczęściej działa, bo w 5 minut błędu się pewnie nie znajdzie.
W biznesie samo wytworzenie oprogramowania to dopiero początek. Schody rozpoczynają się dopiero w fazie utrzymania. Wykrywane są błędy, potrzebne są nowe funkcjonalności, itd. Jak nauczyć studenta, żeby dogłębnie testował swoje programy? Nie znam niestety odpowiedzi na to pytanie.
Podsumowanie
Wykładowcy nie są tacy źli, jak by się mogło wydawać po tym wpisie. To mądrzy ludzie, którzy dzielą się z Tobą wiedzą. Należy jednak wybaczyć im brak wiedzy i umiejętności typowych dla biznesu. Wykładowcy rzadko mają możliwość pracowania w grupie nad oprogramowaniem. Nie tworzą software’u dla klientów, którzy mają wygórowane wymagania.
Kogo słuchać jeśli nie wykładowców? Słuchaj zarówno wykładowców, jak i profesjonalistów z branży. Konferencje informatyczne, płatne czy darmowe, to sposób na poznanie takich ludzi. W uproszczeniu możesz przyjąć, że prelegenci dużych konferencji to osoby, których warto posłuchać.
Trzecim źródłem wiedzy są książki pisane przez doświadczonych developerów. Warto zainteresować się pozycjami podpisanymi takimi nazwiskami, jak jak Robert C. Martin, Kent Beck, Dave Thomas, Andy Hunt, Martin Fowler.
Jest już 18 komentarzy ↓
Tomasz Kowalczyk // gru 15, 2010 at 19:16
Trudno się z Tobą nie zgodzić. Nie twierdzę, że jestem wolny od tych wszystkich uczelnianych “zaleceń”, ale to, że dużo programuję poza uczelnią zarówno na swoje potrzeby jak i pod zlecenia od klientów pozwala się nieco “odciąć” od papki serwowanej przez ogólny przekaz. Polecam każdemu, kto chce być lepszym programistą – po prostu usiąść i pisać kod. Rozwijać własną, nawet trywialną i nikomu niepotrzebną bibliotekę. Przepisując po raz kolejny te same mechanizmy w końcu przyjdzie ten moment, kiedy połączenie kilkunastu wzorców projektowych w skomplikowanej, wielowarstwowej strukturze aplikacji pojawi się przed waszymi oczami jak dobrze zaprojektowany rysunek architektoniczny, gdzie każdy korytarz prowadzi do odpowiedniego rozwiązania.
QAZ // gru 15, 2010 at 21:41
Niestety ale uczelniana teoria nie ma pokrycia z realnym wytwarzaniem oprogramowania dla prawdziwych Klientów. Dużo takich “akademickich” programistów zapomina że program powstaję żeby wykonać określone funkcje a stosowanie “super profesjonalnych” teorii tylko nadmiernie komplikuje kod i wydłuża czas realizacji.
servee // gru 17, 2010 at 08:04
Ja bym na rolę uczelni popatrzył z trochę innej strony. Wydaje mi się, że na uczelni powinniśmy zdobyć przede wszystkim solidne podstawy (algorytmy, struktury danych, itp.) . Pisanie projektów na zaliczenie nie ma na celu wytworzenia nowego dobrze działającego oprogramowania, tylko pokazania czy student potrafi sobie poradzić z określonym problemem – przykładowo jaki jest sen napisania programu, który ma posortować jakieś elementy, gdy możemy skorzystać z biblioteki z algorytmami sortującymi? lub co nam da umiejętność korzystania z np XPath’a, gdy pliki które musimy zaimportować do naszego nowego systemu są XML’owymi tylko w 99% i XPath sobie z nimi nie poradzi (poprzedni system takie właśnie generował i umiał sobie z nimi poradzić). Dlatego raczej nie żądał bym od uczelni wytworzenia programisty, który będzie umiał korzystać z frameworków, ale takiego który będzie miał na tyle solidne podstawy że potrafi sobie poradzić z każdym problemem. W mojej firmie właśnie tacy są przyjmowani do pracy w pierwszej kolejności.
PS. Znam wielu programistów, którzy uważają się za dobrych a nie potrafią odróżnić przekazywania parametrów przez referencję od przekazywania przez wartość.
Damian Nowak // gru 17, 2010 at 12:03
Ad. PS. Ja też znam takiego “dobrego programistę”. Nie potrafił napisać prostego skryptu PHP, który wypełniał tabelę docelową danymi. Sama tabela źródłowa nie była relacyjna i trzeba było odrobinę ruszyć głową, by na niej popracować. Algorytm trywialny, żadnej filozofii, a ten beton robił to 6 godzin i ostatecznie nie zrobił. Ja to zrobiłem w 15 minut…
Krzysztof Kowalczyk // gru 18, 2010 at 12:00
Kwestia uczelni, książki większości osób które zacytowałeś w artykule poznałem z powodu swoich wykładowców ;)
Paweł Stawicki // gru 19, 2010 at 18:17
A dlaczego tylko płatne konferencje? Darmowe też są ok. Też można na nich posłuchać profesjonalistów, ludzi z doświadczeniem. [REKLAMA] Np. na http://java4people.com/ :) [/REKLAMA]
Damian Nowak // gru 20, 2010 at 01:12
Sprostowanie – nie tylko płatne!
codesmuggler // sty 15, 2011 at 19:49
W pełni się zgadzam z treścią wpisu, natomiast nie należy aż tak zniechęcać ludzi do studiowania informatyki. Mimo, że robi się wiele głupich projektów jednokrotnego użytku, to można poznać podstawy wielu różnych technologii oraz podejść oraz spotkać się z wieloma mądrymi ludźmi prowadzących ciekawe badania. A na pewno człowiek nie mając zaliczonego projektu za brak jakiejś prozaicznej rzeczy (np. wymienionych wyżej komentarzy oczywistego kodu) uczy się cierpliwości ;)
Zyx // sty 22, 2011 at 09:24
Ad. KISC, to tutaj pominąłeś moim zdaniem jedną istotną rzecz. Dydaktyka, a rzeczywistość to dwie różne sprawy. Jak prowadzę jakieś kursy, piszę poradniki czy wykłady, też często daję do zrobienia rzeczy wyciągnięte lepiej nie mówić skąd, które z codzienną praktyką mają tyle wspólnego, co piernik z wiatrakiem. Jednak nie służą one pokazaniu “róbcie tak”, tylko “ten przykład jest bez sensu, ale pozwoli Wam zrozumieć, jak działa rzecz XXX i zdobyć pewną perspektywę”. Pomijam już fakt, że generalnie trzeba się nauczyć patrzeć krytycznym okiem na proponowane rozwiązania i po prostu myśleć. Gdyby student miał podawane wszystko na tacy, później przyjmowałby za pewnik największe bzdury i nawet nie przyszłoby mu do głowy by się nad tym głębiej zastanowić. Więc tu popieram wykładowców. Dydaktyka, a życie to dwa odmienne światy i paradoksalnie zastąpienie dydaktyki życiem nie zawsze wychodzi człowiekowi na zdrowie. Inaczej nie byłoby sensu robienia szkół i uczelni.
“Bird extends Animal, to jasne” -> u, to współczucia, jeśli faktycznie miałeś tak, jak piszesz. U nas na technologiach obiektowych już na wstępie powiedziano, byśmy najlepiej zapomnieli o dziedziczeniu na czas jakiś :). Ba, nawet był wykład o lekkich metodologiach całkiem fajnie zrobiony. Z drugiej strony, były przedmioty typu “Projektowanie systemów informatycznych” czy jeszcze gorsza “Inżynieria oprogramowania”, gdzie człowiek nie wiedział już, czy się ciąć czy płakać.
Jakub Spręga // maj 20, 2011 at 12:08
Albo się nauczysz sam, albo w robocie. Finito.
Bartek P // maj 26, 2011 at 09:42
Widziałem, że studiujowałeś na ETI. Muszę ci powiedzieć, że trochę się pozmieniało (albo jesteś na drugim strumieniu ;)). Przynajmniej na systemach nie słyszę rzeczy o których piszesz. O agile jest całkiem sporo (jeden przedmiot pół na pół RUP i Scrum) i wydaje mi się, że dość uczciwie. Jeśli chodzi o singletony, nigdy nie słyszałem, żeby ktoś wychwalał ten wzorzec projektowy, natomiast słyszałem od jednego z doktorów na wykładzie, że jest często nadużywany. Ponadto tenże mówił trochę o depency injection, używaniu interfejsów i testach. Propaguje on również teorię, że dobry kod nie potrzebuje komentarzy, albo potrzebuje ich bardzo mało. Czyli w dużym stopniu to co byś chciał…
bystander // cze 23, 2011 at 12:21
Absolutnie nie zgadzam się z komentarzem o “solidnych podstawach”. Widzisz, musimy się zastanowić, czy uczelnie mają kształcić naukowców czy specjalistów i pracowników. Widzisz, bo rodzi się problem. Co z tego, że wiem jakie są reprezentacje grafów i które są szybsze dla jakich zastosowań, jeśli poszedłwszy pierwszy raz do pracy w zawodzie nie wiedziałem nawet jak się wersjonuje albo testuje? O test-driven development nie wspomnę…
Przyszedłem do pracy i ode mnie oczekuje się przede wszystkim szybkiej funkcjonalności biznesowej. I tu się okazuje, że jak chcę coś mieć szybko, to nie będę implementował reprezentacji grafu! Ją dostarczy mi narzędzie! Nie mam pisać z pamięci quicksorta w czystym c, tylko coś posortować i dalej z tym coś zrobić, tu pobrać coś z bazy danych, tu połączyć się przez ssh z jakimś serwerem i cośtam zrobić… Nikt mi nie płaci za ponowne wynajdywanie koła i implementowanie jakiegoś API do ssh czy struktur danych, kontenerów, algorytmów! Nie będziesz budował własnych interfejsów łączących twoje aplikacje poprzez pipe’y, kolejki itp rzeczy, których się uczyłeś na Systemach Operacyjnych – wykorzystasz coś, co ktoś już napisał! A jednak zalcizenia na studiach z mnóstwa przedmiotów polegają na ręcznym rysowaniu tablic i tabelek i wykonywanie rękoma różnych algorytmów, czy to simpleksa, czy to rozwiązujących problem plecakowy itp. Po co to komu?! Powiem pracodawcy, że w pamięci rozwiązuję problemy programowania nieliniowego sprowadzalne do programowania liniowego?
Wg mnie studia powinny znacznie bardziej skupiać się na umiejętnościach, nie wiedzy. Umiejętności znalezienia zaplecza teoretycznego do danego problemu, a nie uczenia się wszystkich teorii wszystkich problemów w razie gdybyśmy któryś z nich napotkali. Umiejętności pisania kodu w grupie, według różnych standardów panujących w różnych firmach, pracowania z często zbyt skomplikowanymi z powodów historycznych systemami których teraz nikt nie będzie stawiał na nowo. Pisania dobrego, czystego i elastycznego kodu, który łatwo czytać i modyfikować. Pisania dokumentacji też nie uczą na studiach, co najwyżej “do tego projektu ma być dokumentacja” i każdy student wie ile sam się dowiedział, a że na zaliczenie to nawet prawdziwej dokumentacji (takiej POMOCNEJ użytkownikowi/innemu programiście) przypominać nie musi, to cóż…
Gdybyśmy tylko mieli amerykański system z wyborem przedmiotów, być może nie musiałbym marnować czasu na przedmioty związane z tak niepotrzebnymi rzeczami, jak systemy eksperckie, pisanie kompilatorów itp. To są bardzo wąskie dziedziny, i przeciętny inżynier na rynku pracy ich nie potrzebuje, a jeśli będzie w nich pracował, to i tak będzie się dłuuugo w pracy dokształcał, mając braki zarówno dziedzinowe, jak i “rzemieślnicze”!
A co do referencji – to pewnie dlatego, że obecnie koduje się na naprawdę wysokim poziomie, i tam już cię nie obchodzi, jak wewnętrznie w języku wygląda wskaźnik, co jest referencją itp. I to jest według mnie bardzo dobre! Są powody, dla których pracujemy na coraz wyższych poziomach abstrakcji, gdyby nie to, wciąż pisalibyśmy w assemblerze.
co do wpisu: Jednak nie służą one pokazaniu „róbcie tak”, tylko „ten przykład jest bez sensu, ale pozwoli Wam zrozumieć, jak działa rzecz XXX i zdobyć pewną perspektywę” to też nie do końca się zgodzę, niestety. Bo takie podejście kończy się tym, że student potem myśli, że tak się robi, bo nigdy w życiu nie pokazano mu ani jednego przykładu “tak rób”. Takie rzeczy powinno się połączyć z rasowym kursem rzemiosła, gdzie nauczy się studenta, jak zrealizować cokolwiek mu się w głowie urodzi.
Agnieszka M. // lip 17, 2011 at 17:42
Takich jak ty, którzy uważają się za geniuszów mogących krytykować program uczelniany, jest na pęczki. Z kim nie porozmawiasz, poda ci setki przykładów INNYCH programistów, którzy uważają się za dobrych a nie umieją tego lub tamtego (“a mnie zajęło to 15 minut!”). Typowe zwłaszcza dla młodziaków, co to jeszcze mgr nie mają, a już “wiedzą jak się programuje”. Tylko w takim razie kto jest tym beznadziejnym programistą, który robi “szkolne błędy”, skoro wszyscy uważają się za alfy i omegi? ;) Trochę więcej pokory koleżko. Również pokory wobec własnej wiedzy. Widzę, że urodziłeś się w 88 roku. Ile możesz mieć w tym momencie doświadczenia zawodowego, rok, 2 lata? Co to jest? Krytykujesz studentów, a sam jesteś jeszcze studentem, bo na to wskazywałby twój rocznik i brak mgr przed nazwiskiem. Jak możesz mówić, jakie rozwiązania są poprawne, a jakie niepoprawne w biznesie, skoro ledwie liznąłeś prawdziwego programowania. Przyszedłby inny programista z 5-letnim stażem, spojrzał w twój kod i wyśmiał cię właśnie jako studenta, tak jak ty wyśmiewasz tego przysłowiowego studenta. Bo nie ma możliwości, żebyś był nieomylny i pisał idealny kod, bo zwyczajnie brak ci DOŚWIADCZENIA. I to słowo jest tu kluczowe. Nie psiocz na uczelnię, że nie nauczyła cię robić tego wszystkiego, co robisz w pracy, bo to nigdy nie było jej zadaniem (swoją drogą jakaś kiepska uczelnia, ja po mojej w pracy czułam, że robię dokładnie to samo, co robiłam studiując). Uczelnia ma ci dać podstawy do rozpoczęcia zdobywania doświadczenia. I to doświadczenie to jest 90% twojej wartości. Samo to, że studia trwają 5 lat, a praca połowę życia powinno dać ci już coś do myślenia. Żadnego pracodawcy nie będzie interesowało co robiłeś na studiach, czy pisałeś taki czy taki projekt, tylko to, czego się nauczyłeś w praktyce zawodowej. I jak się zarządza prawdziwymi projektami nauczysz sie przy prawdziwych projektach właśnie, nie na uczelni, bo tam zwyczajnie prawdziwych projektów nie ma :) Jakby uczelnia mogła cię wszystkiego nauczył, to płaciliby ci tyle samo, co człowiekowi z 10-letnim stażem – ale jakoś nie płacą. I trochę więcej pokory – ten program uczelniany układali ludzie, którzy się na tym znają, zajmują się tym i wiedzą co robią.
Damian Nowak // lip 17, 2011 at 17:58
Zachęcam koleżankę do przeczytania i zrozumienia tego wpisu.
Przy okazji na przyszłość Ci zasugeruję, o ile w ogóle mogę pouczać wykształconą panią magister, żebyś wyrażała konstruktywną krytykę – np. z czym się nie zgadzasz, dlaczego, itd. Argumentację skupiłaś zaś praktycznie wyłącznie na mojej osobie, o której… och, nie wiesz nic? Twoja wypowiedź wypadła więc bardzo marnie w stosunku do rzeczowych komentarzy innych, droga pani magister. (Z premedytacją użyłem argumentu ad personam wobec Ciebie – może zrozumiesz.)
Agnieszka M. // lip 17, 2011 at 18:45
Wlasnie ja wyrazilam przed 5 sekundami i chcalam wyslac, w punktach, ale ta rewelacyjna stronka wyswietlila mi komunikat (na nastepnej stronie!) “brak adresu e-mail” i caly tekst poszedl sie ….. Wiec przykro mi ale po raz kolejny pisac mi sie nie chce.
Agnieszka M. // lip 17, 2011 at 18:51
Oto fragmenty, ktore mnie zainspirowaly: - tytul: “Do przyszłych programistów” – prawie jak dziadek do wnukow ;) - “Należy jednak wybaczyć im brak wiedzy i umiejętności typowych dla biznesu. ” – ohohooo student wybacza wykładowcom brak wiedzy :) - “Wśród wykładowców raczej panuje przekonanie, że wysoki stosunek liczby komentarzy do ilości kodu świadczy o dobrym projekcie.” – ktorych wykladowcow? Nazwiska, konkrety, jakies statystyki? Twoich? Wspolczuje. - “Nie spotkałem się, by radzono studentom programować interfejsami, a nie implementacjami (code for interfaces, not implementations).” – jeszcze raz, jaka to uczelnia?? Bo moi wykladowcy, wyobraz sobie, czytaja te same ksiazki co ty :) Sa one powszechnie dostepne i zadna to wiedza tajemna… - “Student rzadko usłyszy, że dzięki zwinnemu procesowi wychodzi lepszy software, a gwarancją jakości są: ścisła współpraca z klientem, testy jednostkowe z dobrym pokryciem i działający serwer ciągłej integracji.” – says who? Damian N.? To jest tylko jedno z wielu podejsc, to nie jest prawda uniwersalna – metodyki zwinne sprawdzaja sie w niektorych przypadkach, ale nie we wszystkich. Wyglaszanie takich prawd uniwersalnych przez poczatkujacego programiste budzi moje rozbawienie.
Adam // paź 14, 2011 at 13:35
Slaba jestes agnieszka. A Eti jest spoko ; )
Karol // paź 14, 2011 at 17:33
Czytając to mam wrażenie, że trafiłeś kulą w płot. Problemem szkół jest wmawianie, że pokazane rozwiązania są najlepsze i takie należy wykuć i tylko je stosować. Szkoła ma nauczyć myślenia a jedynych słusznych rozwiązań. Zresztą szkoła powinna uczyć tego czego ludzie chcą się nauczyć. Też trochę pisałem o tym jak być dobrym programistą na swoim blogu. Zapraszam!
Zostaw swój komentarz