Rozpoczęcie nauki na CompSci

Pierwsze dni na CompSci są dość nudne. Przez pierwszy tydzień wszyscy zbierają się w jednej sali, by wyjaśnić co i jak robimy, jak wyglądają wykłady, zajęcia praktyczne, jak wykonywać work-sheety, za co są oceny itp.

Na pierwszym roku dwa pierwsze tygodnie były ok – wprowadzanie do perla w 8 krokach, 8h zajęć tygodniowo, rozłożone na 2 dni. W ciągu godziny mieliśmy rozwiązać zadanie wyświetlane na tablicy, 10 minut przed końcem ktoś przechodził i sprawdzał, czy wszyscy je zrobili. Jeśli się nie nadążało, to dziesięć minut po pełnej godzinie rozwiązanie było pisane na tablicy live przez wykładowcę. W roku akademickim 2013/2014 pierwszoroczni mieli wprowadzenie do Ruby1.9.  Po zakończeniu zadań jest wprowadzenie do narzędzi ułatwiających pracę programistom jak IDE (NetBeans, NotePad lub Eclipse), BlueJ. Jeśli zostaje jeszcze niewykorzystany czas, to robi się wprowadzenie do systemów kontroli wersji. Kiedy przeglądałem polskie fora, często widziałem posty narzekających osób, które pytały, czemu uczelnia nie uczy ich takich rzeczy. Aber wypada na tym tle znacznie lepiej.

 

Pierwszy projekt, jaki mieliśmy do zrobienia, to była gra konsolowa Cross The Square. Gra miała mieć zaprogramowane dwa poziomy trudności, poruszało się po planszy 10×10 pól. Gracz musiał się na niej jak najdłużej utrzymać. Projekt oceniany był pod kątem OO kodu, jakości kodu, “poziomu” re-usability. Dokumentacja techniczna wymagała poprawnego diagramu klas w UML2, minimum JavaDoc.

 

Drugim projektem była aplikacja z GUI – generator diagramu klas UML, w którym ze stworzonego diagramu można było wygenerować sformatowany kod źródłowy dla Javy ze wszystkimi getterami i setterami. Oczywiście aplikacja miała być kompletna, diagram i generator miały obsługiwać klasy, metody, atrybuty w pełnym zakresie, czyli z atrybutami widoczności private, public, protected. Był to mały projekt grupowy, który można było pisać w dwie, trzy lub cztery osoby. Gdy w pierwszych tygodniach nie zdążyliśmy przerobić VCS, to i tak nie uchroniło nas przed nauczeniem się ich na tym etapie. Przed grudniem pierwszego roku musieliśmy mieć opanowane podstawy systemu git. Program oceniany był głównie pod kątem jakości kodu, OO i poprawności diagramu klas. Dodatkowe punkty można było zdobyć za “WoW”, czyli wykonanie czegoś co nie było wymagane, co się dorzuciło od siebie lub gdy jakiś element był tak świetnie wykonany, że aż warto było dać więcej punktów.

 

Trzecim projektem programistycznym była prosta kasa fiskalna dla małej pizzerii. Miała proste wymagania: przyjazny UI, wbudowaną listę produktów, zapis rachunku do pliku XML oraz przeglądanie historii rachunków z tych plików, możliwość zmiany zamówienia, dania rabatu w % lub w funtach. Tutaj ponownie oceniana była jakość kodu, poprawność i kompletność dokumentacji technicznej, poprawność UML i UI. Także tutaj były WoW marks, które było bardzo łatwo zdobyć np. używając baz danych czy JTable do wyświetlania listy produktów (coś czego nie było na wykładach ani practicalach, nauczyłeś się sam, żeby akurat tego użyć).

 

[Total: 0    Average: 0/5]