Note to self (żebym mógł to później znaleźć)
Te trzy artykuły. (poniższe zdania to nie jest jakiś gotowy tekst, tylko luźny zapis moich uwag, bo mam wrażenie, że będę to kiedyś wykorzystywał)
Primo - pisanie programów jest designem. Kod źródłowy to nie gotowy produkt, a jedynie specyfikacja. Wytworzeniem produktu zajmuje się kompilator. Przez analogię do budowania budynków - designem jest stworzenie planów budynku (symulacje komputerowe, etc), a to, że samo budowanie wymaga jeszcze ludzi, a nie jest w pełni zautomatyzowane, jest tylko winą naszej prymitywnej technologii, która akurat w przypadku komputerów pozwala na pełną automatyzację samego budowania.
Przy tym jest problem różnego poziomu designu. Oczywiście obowiązuje zasada od ogółu do szczegółu i dobrze by było, żeby ogół był dobry, ale nie można przy tym przesadzać. UML wydaje mi się zbyt szegółowy jak na ogół, ale nie mam żadnego doświadczenia z nim, także musiałbym coś poczytać i porobić, żeby się wypowiadać. Przy czym warto zaznaczyć, że jeśli samo pisanie kodu też jest designem (tylko na innym poziomie), to, jeśli w trakcie pisania stwierdzimy, że gdzieś we wstępnych etapach designu mamy błąd, to poprawienie go nie jest równoważne ze stwierdzeniem błędu w designie, gdyż proces designu cały czas trwa.
Analogia do pisania esejów - jeśli mam jakiś ogólny pomysł i sobie go powypisuję w punktach (zresztą tak jak to, co właśnie piszę), to jeszcze nie oznacza, że w trakcie samego pisania nie znajdę luk w rozumowaniu, bądź lepszych/bardziej oczywistych argumentów, wniosków, czy czegośtam. Tak samo z pisaniem programów - dopiero w momencie, w którym muszę fizycznie zapisać swoją konepcję tak, żeby komputer mógł ją zrozumieć (w przypadku esejów - czytelnicy), to jestem w stanie wyłapać wszystkie błędy w rozumowaniu.
Poza tym warto by się zastanowić, czy, naturalne dla open source, inkrementalne pisanie programów nie jest po prostu pełnoprawnym wariantem highlevelowego projektowania (as in UML). Zamiast rysować sobie śmieszne kwadraciki i łączyć je liniami, od razu piszę kawałek kodu i sprawdzam jak mój pomysł sprawdza się w praktyce.
Powszechnie wiadomo, że wymyślenie systemu w każdym szczególe i dopiero przystąpienie do kodowania jest skazane na porażkę. Strasznie mi się to gryzie z samym faktem istnienia UMLa i tego typu highlevelowych projektów. Zwłaszcza biorąc pod uwagę to, jak bardzo nieżyciowo wyglądały dla mnie próby zbudownia większego systemu informatycznego w ramach jakiegoś projektu na polibudzie. Jedyne wyjście jakie widzę w tej sytuacji, to że formalne modelowanie wysokiego poziomu powinno służyć tylko i wyłącznie do wstępnego projektowania poszczególnych części systemu i do niczego więcej. Możliwe, że jest też przydatne przy omawianiu projektu, gdy robimy na odwrót, czyli z gotowego już kodu generujemy diagramy UMLowe, ale tego nie jestem pewien. Kilkadziesiąt lat temu było powszechnie wiadome, że programom powinny towarzyszyć schematy blokowe opisujące dokładnie działanie programu. Oczywiście 'wszyscy' wiedzieli, że tak to robią profesjonaliści, a jednocześnie ci wszyscy sobie zdawali w pełni sprawę, że jest to do niczego nie przydatne i tylko zwykła strata czasu. I rzeczywiście, dwa pokolenia później już nikt o tym nawet nie wie. Może z umlem jest tak samo?
Primo - pisanie programów jest designem. Kod źródłowy to nie gotowy produkt, a jedynie specyfikacja. Wytworzeniem produktu zajmuje się kompilator. Przez analogię do budowania budynków - designem jest stworzenie planów budynku (symulacje komputerowe, etc), a to, że samo budowanie wymaga jeszcze ludzi, a nie jest w pełni zautomatyzowane, jest tylko winą naszej prymitywnej technologii, która akurat w przypadku komputerów pozwala na pełną automatyzację samego budowania.
Przy tym jest problem różnego poziomu designu. Oczywiście obowiązuje zasada od ogółu do szczegółu i dobrze by było, żeby ogół był dobry, ale nie można przy tym przesadzać. UML wydaje mi się zbyt szegółowy jak na ogół, ale nie mam żadnego doświadczenia z nim, także musiałbym coś poczytać i porobić, żeby się wypowiadać. Przy czym warto zaznaczyć, że jeśli samo pisanie kodu też jest designem (tylko na innym poziomie), to, jeśli w trakcie pisania stwierdzimy, że gdzieś we wstępnych etapach designu mamy błąd, to poprawienie go nie jest równoważne ze stwierdzeniem błędu w designie, gdyż proces designu cały czas trwa.
Analogia do pisania esejów - jeśli mam jakiś ogólny pomysł i sobie go powypisuję w punktach (zresztą tak jak to, co właśnie piszę), to jeszcze nie oznacza, że w trakcie samego pisania nie znajdę luk w rozumowaniu, bądź lepszych/bardziej oczywistych argumentów, wniosków, czy czegośtam. Tak samo z pisaniem programów - dopiero w momencie, w którym muszę fizycznie zapisać swoją konepcję tak, żeby komputer mógł ją zrozumieć (w przypadku esejów - czytelnicy), to jestem w stanie wyłapać wszystkie błędy w rozumowaniu.
Poza tym warto by się zastanowić, czy, naturalne dla open source, inkrementalne pisanie programów nie jest po prostu pełnoprawnym wariantem highlevelowego projektowania (as in UML). Zamiast rysować sobie śmieszne kwadraciki i łączyć je liniami, od razu piszę kawałek kodu i sprawdzam jak mój pomysł sprawdza się w praktyce.
Powszechnie wiadomo, że wymyślenie systemu w każdym szczególe i dopiero przystąpienie do kodowania jest skazane na porażkę. Strasznie mi się to gryzie z samym faktem istnienia UMLa i tego typu highlevelowych projektów. Zwłaszcza biorąc pod uwagę to, jak bardzo nieżyciowo wyglądały dla mnie próby zbudownia większego systemu informatycznego w ramach jakiegoś projektu na polibudzie. Jedyne wyjście jakie widzę w tej sytuacji, to że formalne modelowanie wysokiego poziomu powinno służyć tylko i wyłącznie do wstępnego projektowania poszczególnych części systemu i do niczego więcej. Możliwe, że jest też przydatne przy omawianiu projektu, gdy robimy na odwrót, czyli z gotowego już kodu generujemy diagramy UMLowe, ale tego nie jestem pewien. Kilkadziesiąt lat temu było powszechnie wiadome, że programom powinny towarzyszyć schematy blokowe opisujące dokładnie działanie programu. Oczywiście 'wszyscy' wiedzieli, że tak to robią profesjonaliści, a jednocześnie ci wszyscy sobie zdawali w pełni sprawę, że jest to do niczego nie przydatne i tylko zwykła strata czasu. I rzeczywiście, dwa pokolenia później już nikt o tym nawet nie wie. Może z umlem jest tak samo?
02 III 2005 o 09:30:22
IMHO wszelakie diagramy mimo wszystko są przydatne, choćby po to by po miesiącu nie zajmowania się jakimś modułem móc szybko do niego wrócić zamiast zastanawiać się "gdzie to k... było".
Szybko i przyjemnie się np. rozwiązuje relacje między poszczególnymi tabelami w bazie danych (IMHO już nawet kilka wystąpień foreign key się ciężko czyta, a na schemacie to jest po prostu oczywiste).
Swoją drogą gdy piszesz program też pewnie masz w głowie "narysowany" jakiś schemat jak to ma działać i później po prostu piszesz kod. Tylko w tym momencie istnieje ryzyko, że albo Ty albo Twój współpracownik w pewnym momencie zapomni, że w danym momencie dzieje się coś specyficznego i zamiast szybko odnaleźć błąd zmarnuje godzinę na wgryzanie się w kod.
Ponadto wyobraź sobie model komercyjny, gdzie po wykonaniu projektu programiści po prostu odeszli z firmy (lub zostali zwolnieni, różnie bywa) a po to by poprawiać błędy w kodzie zostałeś zatrudniony Ty - życzę miłego zaznajamiania się z setkami tysięcy linii kodu bez choćby ogólnego schematu ;)
02 III 2005 o 12:29:01
Nie przeczę, że wizualizacja danych jest często bardzo przydatna. Ale już np. próby wymyślenia od razu wszystkich obiektów i ich interfejsów uważam za idiotyczne. Po 20 linijkach kodu i tak się okaże, że połowa pomysłów była błędna. Stąd 'rapid prorotyping' jest takim strasznym 'postępem'.
Wizualizacja tak, ale cały sens tych artykułów jest taki, że pisanie kodu też jest designem skutkiem czego sztywne trzymanie się tego, co się wyklika w umlu, jest kompletnym bezsensem. Czyli wizualizacja to coś, co pomaga w zarządzaniu ogólnymi koncepcjami rządzącymi programem (bądź przyglądaniu się jakiemuś modułowi), ale nie służy tworzenia ostatecznego designu. Bo pisanie kodu to też design :)
02 III 2005 o 16:09:01
Dlatego też obecna narzędzia pozwalają na bieżąco synchronizować kod ze schematami, tak że nawet jeśli programista wymyśli coś inaczej to schemat będzie to odzwierciedlał.
BTW kompilacja programu to też design, tylko z mniejszą kontrolą ze strony programisty ;)
02 III 2005 o 16:25:13
BTW, u nas na uczelni przy okazji wprowadzenia ,,projektu grupowego'' padło stwierdzenie: ,,Klienta interesuje dokumentacja, i za jej wytworzenie nam płaci. Sam software jest elementem koniecznym, ale niewystarczajacym. Pisanie kodu jako czynnosc dajaca radosc tworzenia powinna byc potraktowana jako hobby i za to zaplata sie nie nalezy''. Ale moja uczelnia ostatnio sobie wymyslila, ze zrobi ze studentów murzynów odwalania czarnej roboty i przy okazji na tym zarobi, wiec nie wiem, czy nalezy traktowac powaznie to co zapodaja.
02 III 2005 o 16:56:39
Ano pozwalają i jest powszechnie wiadome, że 'programowanie jest procesem nieliniowym, blablablabla, nie można się trzymać szczegółowego planu, blablablabla'. A ten facet już ponad 10 lat temu przedstawił bardzo zgrabną koncepcję myślową jasno i precyzyjnie tłumaczącą ten fakt.
04 III 2005 o 00:54:55
Chyba jednak musisz troche poczytac, jesli sadzisz, ze to kompilator generuje produkt z biznesowego punktu widzenia... Kodowanie to design, ale implementation. Jest jeszcze management, bez ktorego zaden wiekszy projekt nie ma szans (nie mowie o managemencie biznesowym, bo to osobna dzialka). Czy wiesz, co oznaczaja te skroty: RUP, USDP, MSF, SCRUM, Crystal? Poczytaj. I o zarzadzaniu projektami informatycznymi tez. Czy uczestniczyles kiedys w projekcie, ktorego budowanie zajmowaloby wiecej niz godzine? Narysowales kiedys diagram klas trwalych? Jesli po 20 linijkach widzisz blad w modelu, ktory zrobiles, to znaczy ze jestes programista, a nie projektantem...
04 III 2005 o 00:57:54
W kazdym razie: nie pisz takich farmazonów, ja Cię proszę... poczytaj trochę aktualnych książek, porozmawiaj z ludzmi, ktorzy tworza systemy wieksze niz sklep w php/mysql.
04 III 2005 o 12:03:19
Heh. Ale właśnie rzecz polega na tym, że ja poczytałem i wiem, że samo malowanie w umlu i tworzenie dokumentacji nigdy nie jest wystarczające, gdyż zawsze się okazuje, że trzeba wprowadzać zmiany w początkowych założeniach na podstawie tego, jak się koduje oraz zmian w wymaganiach klientów (borgowe metody mają na to różne sposoby, np. robienie paru iteracji po całym procesie; znalazłem fajną książkę w bibliotece polibudzianej i tam jest rozdział o RUP, to poczytam jak to jest tam rozwiązane). I traktowanie pisania kodu też jako części designu jest bardzo zgrabną konstrukcją myślową tłumaczącą dlaczego tak jest.
A właśnie - gdyby borgowe metody były rzeczywiście jedynie słuszne, to nikt by nigdy nie usłyszał o xp, prawda? Już nie wspominając o takich kurduplach, jak kde, gnome, x.org, czy linux (przy czym linux dostarcza technologii... ale kde i gnome już nie).
I jeszcze jedno - nie lubię rozmawiać z anonimami.
05 III 2005 o 20:52:57
1. XP nie wyklucza UML...
2. Kolejne requesty klientów oddziaływują zarówno na model, jak i kod
3. o RUP poczytaj moze na www.rational.com...
4. projektujac zlozone aplikacje spojrzenie na kod jest zbedne, bo kod jest naprawde kilka ladnych poziomow abstrakcji nizej
5. nie zawsze sie ma to, co sie lubi, prawda?
05 III 2005 o 21:45:11
Nigdzie nie twierdzę, że xp wyklucza uml.
Wszędzie gdzie czytałem jest info na temat konieczności zapewnienia feedbacku programiści -> architekt. Takoż wszystko się zaczynało od "nie da się stworzyć dokładnego planu i tylko kazać programistom się go trzymać".
05 III 2005 o 23:31:59
Widze, ze Cie wciagnelo ;). Dla pewnosci: nie twierdzilem ani przez chwile, ze mozna opisac system w UML, dac koderom plik diagramow, wyznaczyc deadline i oczekiwac produktu - tak nie jest. Ale Ty mowiles, ze chcialbys pominac modelowanie i od razu zaczac klepac - to nie jest mozliwe w przypadku duzych systemow, zupelnie nie do przyjecia w powaznych zastosowaniach. Poczytaj o enterprisowych wzorcach projektowych (np. J2EE Core Patterns, Microsoft Application Building Blocks), rozpoznaj troche tych skrotow, ktore wymienilem wczesniej - byc moze zainteresujesz sie architektonicznym spojrzeniem na wytwarzanie oprogramowania. Metodyki zwinne to nadal dosc swiezy pomysl, szczegolnie w Europie - najwiekszy znany projekt prowadzony zgodnie z XP (dla uwagi: XP to zdecydowanie nie tylko pair programming, ale przede wszystkim stały feedback, refaktoryzacja i ciagla integracja) skupial 100 developerow, precedens nie zostal powtorzony. Wlasciwie kazda duza firma ma wlasna metodyke, dostosowana zarowno do umiejetnosci zespolu, jak i liderow. A samo XP, mimo "zwinnosci", wymaga bardzo duzego rygoru i dyscypliny. Pamietaj takze o tym, ze wiekszosc oprogramowania typowo biznesowego nie jest tworzona od zera, a sa to raczej wdrozenia produktow standardowych jak ERP (np. leciwy SAP).
I jeszcze:
"trzeba wprowadzać zmiany w początkowych założeniach na podstawie tego, jak się koduje" - jesli tak jest to znaczy, ze albo projektanci sa do dupy, albo programisci nie potrafia wykorzystac technologii; przy standardowych projektach to nie do pomyslenia
"oraz zmian w wymaganiach klientów" - to jest zawsze prawda, ale oddzialywuje na wszystkie aspekty produktu, z modelem i kodem wlacznie; od tego sa wlasnie metodyki i cala dyscyplina zarzadzania projektem, by prowadzic projekt tak, zeby mogl on adaptowac sie do zmian
05 III 2005 o 23:34:06
I nie kojarz UML z rysowaniem diagramow opisujacych kazda najmniejsza klase - tak nikt tego nie robi, bo to nie do tego sluzy. A same diagramy klas to tylko jeden rodzaj diagramow ze wszystkich jakie oferuje UML.
05 III 2005 o 23:50:28
"Modelowanie związków encji" o ile pamiętam. Po prostu graficzna reprezentacja zależności zachodzących pomiędzy jakimiśtam abstrakcjami. Akurat wizualizacja rzeczy typu sql, czy też wygenerowanie diagramu wzajemnych powiązań klas w kodzie jest dla mnie sensowne -- zapewne ułatwia szybsze wgryzienie się w jakiśtam kod.
Odnośnie pominięcia etapu formalnego definiowania architektury systemu, to był to skrót myślowy (jak zaznaczyłem na wstępie, ten wpis to nie jest gotowy tekst :). Chodzi o wzajemne zazębianie się takich koncepcji, jak 'kodowanie to design', 'rapid prototyping' i inkrementalne tworzenie oprogramowania z uwzględnieniem mocnego refactoringu. To jest właśnie 'prawidłowy' sposób tworzenia projektów opensource, dający największe szanse na powodzenie projektu (ale tutaj wchodzi kilka dodatkowych czynników, które są albo nieobecne, albo mają inne znaczenie w projektach komercyjnych), a, jak widać, można by go po prostu opisać tymi kilkoma definicjami.
W ogóle cały sens tego wpisu jest taki, że jak mi się będzie nudziło i będę miał ochotę opisać funkcjonowanie projektów open source w odniesieniu do terminologii stosowanej w inżynierii oprogramowania, to żebym miał punkt odniesienia (bo sam takie informacje pewnie pozapominam). Dlatego do wszystkich powyższych zdań trzeba sobie pomyśleć dlaczego to jest dobre w open source.
Przy czym temat jest wart rozważnie *zwłaszcza* biorąc pod uwagę istnienie projektów wielkości linuksa, kde, czy gnome, gdzie stwierdzenia typu 'ale my tu mówimy o dużych produktach, a nie jakiś programikach' już tak jakby traci swój jawiemlepiejszy wydźwięk.
06 III 2005 o 00:06:11
A właśnie - to jeśli zapewnienie feedbacku programiści -> architekt nie wynika z ewentualnych problemów, jakie mogą wyniknąć przy próbie rzeczywistej implementacji danego projektu, to z czego?
Bo jedyne co mi przychodzi do głowy, to że architekt nie może próbować zdefiniować każdego jednego pierdolnika w implementacji. Skoro nie może, to takie rzeczy zostawia samym programistom, a ci mogą w trakcie implementacji znaleźć jakieś niedociągnięcia w planie. Akurat czytam książkę o kierowaniu zespołami programistów (właśnie w niej jest cały rozdział o RUP) i tam nawet jest opisane, jak w podobnej sytuacji zespół stwierdził, że będzie robił bezpłatne nadgodziny, byle by zmienić jakieśtam założenie, dzięki czemu będzie im wygodniej w przyszłości.
Ale ty z kolei twierdzisz, że w takich wypadkach to po prostu znaczy, że architekt dupa. To ja już się pogubiłem (acz skłaniam się w kierunku twierdzenia, że nie architekt dupa, tylko nie da się przewidzieć wszystkiego).
06 III 2005 o 10:36:03
1) Mówię nie o projektach typu linux, ale takich, w których istotny jest kompromis pomiędzy: czas wykonania, jakość wykonania, koszt wykonania. Hobbystyczne dziubanie poza godzinami pracy to nie to samo.
2) Nie wiem, jak się wizualizuje SQL - pewnie miałeś na myśli schemat relacji. btw, poczytaj o O/R mapping
3) btw, potrafisz podać przykłady projektów open-source, które wykorzystywałyby rapid-prototyping?
4) o "metodykach" stosowanych w projektach open-source jest rozdział w pdf-ie "Agile software...", do którego link ci wzuciłem - nie ma co wyważać otwartych drzwi
5) a wiesz, ze programista zarabia zwykle mniej od sekretarki...?
06 III 2005 o 11:40:43
1. A ja o takich mówię tylko jako o tle właśnie ze względu na niewystępowanie i inny wpływ sporej ilości czynników.
3. Każdy? Przy inkrementalnym tworzeniu oprogramowania jest jak najbardziej normalne, że na początku się tworzy coś, co służy przetestowaniu założeń (budowa programu, interfejs, czy co tam).
4. O. W takim razie trzeba będzie to przeczytać.
5. Programista Java (j2ee i jeszcze kilka fajnych skrótów)? Coś mi się nie wydaje.
06 III 2005 o 12:36:35
1) ok
3) rapid-prototyping to nie do konca to, o czym mowisz - zawsze robi sie cos, co pokazuje sie klientowi przed koncem projektu (dla dospecyfikowania wymagan, okreslenia ryzyka, wprowadzajacego szkolenia dla koncowych uzytkownikow). Ale ja chyba nie znam popularnego projektu open-source, ktory *najpierw* generowalby stos zrzutow ekranu, a dopiero potem bral sie za implementacje konsekwentnie realizujaca szkice. Z popularnych metodyk najblizej "rapida" jest chyba XP. Rapid prototyping generalnie jest drogi.
4) java jest mi blizsza niz wszystko inne... a dobra sekretarka jest jak skarb ;)
06 III 2005 o 13:45:22
Akurat w open source nie istnieje klasyczny klient oraz biznesowa część projektu (kierownictwo), które wymagają pewnych formalnych rozwiązań. Implementacja konsekwentnie realizująca szkice? Po co - wystarczy wyprodukować jakiś helloworldowy kawałek kodu, pogadać na jego temat i zastosować wnioski w praktyce.
Życie jest piękne, jak się przed nikim nie odpowiada :)
10 III 2005 o 15:57:17
Powiem wprost: w życiu nie czytałem takie steku bzdur. Czego uczą na tej informatyce?
20 VI 2005 o 12:07:38
anonim, nie bierz tego serio. oni sobie jaja robią xD