Projektowanie oprogramowania po akademicku
Na zebraniu microsofciarzy było osiem osób, więc zamiast mojego występu odbyło się to, co było planowane, czyli projektowanie 'systemu kariery studenta'. Jezu. To się powinno 'inżynieria marnowania czasu' nazywać. Jakbym ja próbował cokolwiek robić w ten sposób, to bym w życiu nic nie zrobił.
Zacznijmy od początku, czyli od faktu, że panowie studenci pierw muszą sobie zgadnąć kto ich projektu ma używać, w jaki sposób, na ile jest to realne, że będzie używał i jakie są potencjalne sposoby integracji z resztą baz danych o studentach. Mam dziwne wrażenie, że to jakiś perwersyjny sposób uświadomienia im jak wygląda praca w korporacjach produkujących oprogramowanie na potrzeby klientów. Tak, czy siak, skoro nie ma praktycznie żadnych szczegółów implementacji, zostaje wielce skomplikowany problem wprowadzania informacji o studentach i wykładowcach do bazy danych (która nawiasem mówiąc nie ma być częścią projektu... ma być warstwa abstrakcji wokół bazy danych, bez konkretnej implementacji dla danej bazy :), a potem wypluwania tych informacji przez jakąś stronę www. Ja mam bardzo bardzo dziwne wrażenie, że to jest praktycznie zero roboty, ale profilaktycznie się zapisałem na ciąg dalszy projektu, może się przekonam, że jest inaczej. Choć poważnie w to wątpię.
Zacznijmy od początku, czyli od faktu, że panowie studenci pierw muszą sobie zgadnąć kto ich projektu ma używać, w jaki sposób, na ile jest to realne, że będzie używał i jakie są potencjalne sposoby integracji z resztą baz danych o studentach. Mam dziwne wrażenie, że to jakiś perwersyjny sposób uświadomienia im jak wygląda praca w korporacjach produkujących oprogramowanie na potrzeby klientów. Tak, czy siak, skoro nie ma praktycznie żadnych szczegółów implementacji, zostaje wielce skomplikowany problem wprowadzania informacji o studentach i wykładowcach do bazy danych (która nawiasem mówiąc nie ma być częścią projektu... ma być warstwa abstrakcji wokół bazy danych, bez konkretnej implementacji dla danej bazy :), a potem wypluwania tych informacji przez jakąś stronę www. Ja mam bardzo bardzo dziwne wrażenie, że to jest praktycznie zero roboty, ale profilaktycznie się zapisałem na ciąg dalszy projektu, może się przekonam, że jest inaczej. Choć poważnie w to wątpię.
28 X 2004 o 22:39:32
Może o to właśnie chodzi, żeby najpierw zrobić z tego "problemu" coś strasznie skomplikowanego, a następnie pokazać, że "dzięki .NET" można to w paru linijkach zrobić ;-)
28 X 2004 o 23:04:48
Zawsze mi mówili że początki są trudne, ale że aż tak :| Szkoda że nie mówiłeś o programowaniu.
28 X 2004 o 23:13:24
A właśnie. Jak wspomniałem o cvsie i subversion, to na mnie patrzyli jak na wariata. Ustalili, że będą przychodzić z dyskietkami co pewien czas i ładować to na jednego kompa. Gdyby nie ciekawość jak im to będzie szło, to bym uciekł w popłochu.
29 X 2004 o 00:35:51
O ROTFL.
Stary, nie zadawaj sie z nimi.
29 X 2004 o 06:58:29
Czekamy na dalsze raporty!
29 X 2004 o 10:18:52
Hi hih iihi hi dyskietkami? buuhhaaaaaaaaa...
Przepraszam ;)
31 X 2004 o 17:05:44
Klasyka gatunku: absolwenci wiodących polskich uczelni technicznych nigdy nie słyszeli o cvs ani svn. Potwierdzone wielokrotnie.
Natomiast jeśli chodzi o planowanie... tutaj w pewnym sensie się z nimi zgadzam. W świecie juniksa i FLOSS esensją oprogramowania jest porządna specyfikacja, pewne konwencje i dokumentacja, czyli idea. Nawet w przypadku odrobinę bardziej rozbudowanych skryptów backupowych (czy czegoś na tym poziomie skomplikowania) brak poświęcenia dwóch papierosów na przemyślenie problemu to potencjalne potwory (nie mylić z potworkami).
31 X 2004 o 17:07:21
s/esensją/esencją/g
31 X 2004 o 18:15:16
Nie utożsamiałbym specyfikacji i dokumentacji z ideą. Specyfikacja czy dokumentacja to spisane dokumenty. A projekty FLOSS, czesto oparte na dobrym pomyśle i nawet bardzo dobrze przemyślane często czegoś takiego nie mają. I okazuje się, że bez tego też mogą się jakoś rozwijać. Oczywiście zawsze jest lepiej, gdy dokumentacja istnieje.
31 X 2004 o 20:26:53
Jajcus: nie stawiam tutaj znaku równości. Oczywiście to dwie różne rzeczy, ale są w opozycji do podejścia "siadamy, piszemy, jakoś to będzie".
Jeśli chodzi o idee... miałem na myśli nawet bardzo abstrakcyjne matefory rodem ze świata juniksów - np. wszystko jest plikiem - które przetrwały dłużej niż konkretny kod.
Specyfikacje i dokumentacje są już bardziej konkretne i na tym polu - począwszy od roadmapów, a kończąc na o wiele bardziej konkretnych papierach - nie jest też tak źle w przypadku FLOSS.
31 X 2004 o 20:29:38
Podejście "siadamy, piszemy, jakoś to będzie" też czasem się przydaje... do zrobienia prototypu. Tylko trzeba od razu wtedy założyć, że jak prototyp zadziała to to co się zrobiło się napisze od nowa, tak jak należy. Parę razy tak robiłem i to się sprawdziło. Czasami nawet prototyp okazywał się wystarczająco dobry, aby go rozwijać jako właściwy produkt robiąc tylko kosmetyczne poprawki.