Projektowanie aplikacji - niepopularne

0

Z tego co widzę bardzo mało osób projektuje swój kod i aplikacje.
Dlaczego tak się dzieje?
Może jestem w błędzie?

4

Ale co rozumiesz przez "projektuje"? Że siadasz, wszystko najpierw projektujesz a dopiero potem kodzisz? Nikt tak nie robi bo juz 100 lat temu empirycznie przekonano sie że Waterfall nie działa.
90% wymagań dotyczących systemu pojawia sie w trakcie jego realizacji ;]
Zaprojektować to sobie można z grubsza architekturę aplikacji i wybrać odpowiednie technologie i może uda sie projekt skończyć bez rewolucji w tym względzie (ale nie zawsze).

0

Uzywam i dlugopisu i UMLa, co mam zaznaczyc? :(

0

@Shalom Cokolwiek, chociażby sam diagram sekwencji.
Część moich znajomych pisze kod jak wiersze - co w głowie to zaraz w źródłach

1

Dlaczego tak się dzieje?

Dlatego, że często łatwiej i szybciej jest po prostu pisać kod.

4

@spartanPAGE ale takie diagramy muszą mieć powód do istnienia. Jaka jest różnica między narysowaniem diagramu a napisaniem kodu który robi dokładnie to samo? Jak dla mnie wartość dodana tego diagramu jest zerowa w takiej sytuacji. W prawdziwym projekcie to jeszcze gorzej, bo kod sie zmieni 700 razy a diagramu nikt poprawiać nie będzie (podobnie jak z komentarzami w kodzie, kod już dawno się zmienił a komentarze nadal te same ;]).
Co innego jeśli masz jakiś skomplikowany flow i chcesz iść z diagramem do analityka i wypytać czy dobrze zrozumiałeś co sie ma dziać. To wtedy ma sens, bo dla analityka diagram będzie czytelny a poryty kod w brainfucku już mniej.
Diagramy maja też czasem takie zalety że można sie dzięki nim zorientować gdzie szukać modułu odpowiedzialnego za coś i gdzie sie można "wpiąć" z jakąś funkcjonalnością. Szukanie takich rzeczy w kodzie to masakra. Ale znów to są zwykle dość ogólne diagramy - architektury czy komponentów.
Diagramy wdrożenia mogą sie też przydać ludziom którzy będą stawiać system u klienta, żeby wiedzieli jak to wszystko ze sobią "spiąć".

Ale malowanie diagramów klas czy sekwencji tak dla samego siebie uważam za stratę czasu. Nalezy napisać kod a diagramy generować na jego podstawie.

1

Jak robię coś dla siebie, a w pracy kiedy po prostu implementuję to co mam do zrobienia, smaruję długopisem po kartkach. Przed implementowaniem w pracy piszemy (a przynajmniej powinniśmy ;-) dokumentację projektową na różnych poziomach - architektury, wymagań funkcjonalnych, ogólnym i szczegółowym. Wszystko co nie jest tekstem jest najczęściej UMLem.

1

Ja gdy programuję dla siebie, to zwykle rozpisuję na kartkach swoje algorytmy i struktury danych (tzn wymyślam sobie swoje).

1

Ja z reguły trzymam wszystko w głowie i przelewam od razu na linie kodu; Czasem wspomagam się kartką i długopisem (ale bardzo rzadko), bo czasami lepiej jest sobie coś rozpisać i to po prostu zobaczyć;

Jeśli program/biblioteka/algorytm ma mniej niż 10KLoC, to nic nie projektuję, bo raczej szkoda czasu, a i tak w praktyce sporo się zmieni; Wszystko zależy od przypadku - np. TreeStructInfo czy TFuriousLabel miałem i mam w całości w głowie.

5

Uważam, że ZAWSZE projekty powinny być rozrysowane w jakiś sposób na diagramie. Czy to będzie UML, czy coś innego lub nawet autorskiego - nie ma znaczenia. Byle spełniało wymagania i realizowało swoje zadanie.

Programiści piszący kod na szybko i bez napisania diagramu zazwyczaj nie piszą kodu optymalnie - jest to zachowanie nieprofesjonalne a co gorsza napisany w taki sposób projekt ma złą strukturę. Programiści często w taki sposób piszący nie widzą tego problemu i myślą, że wszystko robią dobrze, ale dopiero gdy zobaczą diagram dochodzi do nich jak duży popełniali błąd.

W moich projektach zawsze stosowałem PROSTĄ architekturę UML, gdyż zgodnie z tym co koledzy wyżej napisali - założenia projektu oraz jego funkcje zmieniają się w czasie - nie ma więc sensu tworzyć dokładnego projektu UML, gdyż takiego nie znamy na początku.

Prosta struktura jest jednak KONIECZNA, by program zobaczyć niejako "z góry" i zbudować w nim odpowiednie struktury. Dobry programista natomiast szacuje jakie mogą być założenia w przyszłości i jak mogą zmienić się potrzeby biznesowe.

Odpowiadając, więc na pytanie:
Tak buduję zawsze diagram reprezentujący wstępne założenia projektu, wiedząc że ulegnie on zmianie w pewnym okresie czasu. Staram się też diagram aktualizować oraz dodawać do niego nowe założenia.
Uważam, że każdy tak powinien robić. Brak jakiegokolwiek diagramu jest oznaką braku profesjonalizmu. Programista - profesjonalista natomiast podchodzi poważnie do każdego projektu który tworzy i robi to zgodnie ze sztuką.

4

Programiści piszący kod na szybko i bez napisania diagramu zazwyczaj nie piszą kodu optymalnie - jest to zachowanie nieprofesjonalne a co gorsza napisany w taki sposób projekt ma złą strukturę. Programiści często w taki sposób piszący nie widzą tego problemu i myślą, że wszystko robią dobrze, ale dopiero gdy zobaczą diagram dochodzi do nich jak duży popełniali błąd.

Bzdura. Diagramy nie mają nic do tego. Jak ktoś nie umie wymyślić dobrego rozwiązania pisząc kod, to nie wymyśli go też malując diagram. Szczególnie jak kod pisze metodą top-down.

Prosta struktura jest jednak KONIECZNA, by program zobaczyć niejako "z góry" i zbudować w nim odpowiednie struktury

Z tym się zgadzam - tak jak pisałem wyżej, warto zrobić diagramy architektury i komponentów, żeby było wiadomo co gdzie jest. Szczególnie jeśli aplikacja jest rozbudowana i nie wystarczy nam jeden wielki moduł na całą logikę ;]

Uważam, że każdy tak powinien robić. Brak jakiegokolwiek diagramu jest oznaką braku profesjonalizmu. Programista - profesjonalista natomiast podchodzi poważnie do każdego projektu który tworzy i robi to zgodnie ze sztuką.

A to znów jakieś bzdury. Są projekty gdzie diagram jest potrzebny, ale są takie gdzie nie. Jak projekt jest stosunkowo mały i prosty to nie ma co marnować czasu. Chyba że chcesz coś pokazać osobom nie-technicznym, wtedy można sie bawić w malowanie. Profesjonalizm nie ma nic do tego. Liczy się wartość dodana albo jej brak. Jeśli taki diagram nic nie wnosi i jest tylko po to "żeby było zgodnie ze sztuką" to jest to głupota i marnowanie czasu.

1

Z praktyki w pracy - stosujemy typowego SCRUMA, opieramy sie o dokumenty ze specyfikacja wymagan.
Oczywiscie wymagania i tak sie zmieniaja co sprint, jak to zwykle bywa ;)
Jedyne diagramy to jakies skomplikowane workflowy, ktore latwiej wytlumaczyc 'obrazowo' niz slownie.
I to i tak nie jest stricte typowy UML, tylko po prostu graficzne przedstawienie pewnych procesow.

4

Bzdura. Diagramy nie mają nic do tego. Jak ktoś nie umie wymyślić dobrego rozwiązania pisząc kod, to nie wymyśli go też malując diagram. Szczególnie jak kod pisze metodą top-down.

Programista tworząc diagram lub go widząc, ma szerszy obraz całości dzięki czemu łatwiej wymyśla wzorce i sposoby wykorzystania klas, niż "mając to jedynie w głowie". W głowie to można mieć mózg, z którego trzeba skorzystać.
Dużej aplikacji nie wymyślisz w głowie, bo jest zbyt duża. Trzeba ją rozpisać na kartce lub w odpowiednim do tego celu programie, aby poukładać odpowiednie struktury i elementy na swoim miejscu.
Podczas takiej analizy często uzyskuje się informacje, gdzie jest potencjalny problem oraz w jaki sposób najlepiej go rozwiązać.
Proces wytwarzania oprogramowania (nie programu Hello world) jest tak skomplikowany, że mówienie o tym, że w głowie da się to rozpisać i przelać bezpośrednio na kod jest niepoważne. Nie mówimy tutaj o programie typu "Wywołaj i wykonaj", tylko o normalnej aplikacji - o jakimś tam stopniu komplikacji.

Pisząc kod natychmiast po wymyśleniu rozwiązania (tak się tylko wydaje) programista nagle natknie się na fragment gdzie zapędził isę w kozi róg i musi wybrać mniejsze zło by kontynuować pracę. Wstępna analiza i diagramy pozwalają takie miejsca wychwycić dużo wcześniej, dzięki czemu oszczędzany jest czas.

Oczywiście diagramy trzeba umieć robić i to wymaga pewnej wprawy.

Z tym się zgadzam - tak jak pisałem wyżej, warto zrobić diagramy architektury i komponentów, żeby było wiadomo co gdzie jest. Szczególnie jeśli aplikacja jest rozbudowana i nie wystarczy nam jeden wielki moduł na całą logikę ;]

No własnie. Jeśli program ma skomplikowaną i rozbudowaną logikę biznesową oraz całość projektu jest całkiem pokaźnych rozmiarów to ciężko od razu pisać kod. Gdy się tak zrobi najprawdopodobniej struktury będą nieprzemyślane, a całość robiona na "Wydaje mi się, że tak będzie ok", po czym programista za 2 tygodnie będzie przeklinał wcześniejszy pomysł, bo zapędzi się w ślepą uliczkę z której wyjście będzie obejściem problemu.
Po to są diagramy by takich sytuacji nie było.

A to znów jakieś bzdury. Są projekty gdzie diagram jest potrzebny, ale są takie gdzie nie. Jak projekt jest stosunkowo mały i prosty to nie ma co marnować czasu. Chyba że chcesz coś pokazać osobom nie-technicznym, wtedy można sie bawić w malowanie. Profesjonalizm nie ma nic do tego. Liczy się wartość dodana albo jej brak. Jeśli taki diagram nic nie wnosi i jest tylko po to "żeby było zgodnie ze sztuką" to jest to głupota i marnowanie czasu.

mamy inne podejście i spojrzenie na temat widocznie.
To co dla mnie jest podstawą i ogólnym zarysem, który trzeba wykonać, gdyż jest się świadomym zmiennych wymagań (nawet najmniejsze projekty w przyszłości ewoluują), a co za tym idzie - należy przygotować dobry grunt na przyszłość i umożliwić sobie szybsza pracę, gdy nadejdzie chwila dodania nowych funkcji między innymi poprzez przemyślane struktury oraz ogólny zarys architektoniczny na diagramie, dla Ciebie jest tylko dodatkiem i rzeczą, którą się kalkuluje.

Już od dawna wiem, że proces architektoniczny nie podlega kalkulacjom, gdyż pominięcie go lub spłycenie tylko do prostych pomysłów rodzących się w głowie kończy się tragicznie lub w najlepszym wypadku - nie fajnie.
Zazwyczaj programista nie stworzy odpowiednich struktur i podczas zmian potrzeb biznesowych lub podczas dodawania nowych funkcji:

  • Musi przebudować wcześniejsze elementy
  • Musi przenieść wcześniejsze elementy
  • Musi zmienić elementy (najgorsza rzecz)
  • Musi wymyślać obejścia, bo istniejąca struktura jest nieelastyczna (trudno wymyśleć w głowie elastyczną formę dla normalnej wielkości aplikacji)

Piszesz także o oszczędności czasu - pomijasz tylko to o czym była mowa wcześniej. Zmienne założenia biznesowe i dodawanie nowych funkcji.
Nie ma programu, który by nie przeszedł przez te elementy jeśli jest faktycznie wykorzystywany.
Jeśli program jest niewielki to zbudowanie diagramu nie zajmie wiele czasu - jaka w tym korzyść czasowa? Wykonanie diagramu zajmie niewiele czasu, programista będzie miał mocny architektoniczny projekt, a w przyszłości zaoszczędzi czas na przypominaniu sobie "jak to wszystko działało", gdyż posiadać będzie konkretny projekt.

Natomiast w dużych aplikacjach brak utworzenia diagramu skorńczy się katastrofą w postaci licznych błędów architktonicznych, które będzie trzeba naprawiać. A skoro będzie trzeba naprawiać to zajmie programiście czas, który mógłby oszczędzić realizując / otrzymując wcześniej architektoniczny projekt aplikacji.

To o czym napisałem teraz nazywa się "Długiem technologicznym" - zapoznaj się :)

0

Temat nadaje się do Inżynierii Oprogramowania

3

Programista tworząc diagram lub go widząc, ma szerszy obraz całości dzięki czemu łatwiej wymyśla wzorce i sposoby wykorzystania klas, niż "mając to jedynie w głowie"

A to niby czemu? Jeśli kod jest pisany top-down to moim zdaniem obraz całości jest taki sam.

Podczas takiej analizy często uzyskuje się informacje, gdzie jest potencjalny problem oraz w jaki sposób najlepiej go rozwiązać.

Nigdy nie byłem świadkiem takiej sytuacji. Problemy zwykle pojawiają się już w trakcie implementacji bo wcześniej po prostu trudno jest ocenić czy coś będzie problematyczne czy nie. Póki nie spróbujesz, nie będziesz wiedział.

Gdy się tak zrobi najprawdopodobniej struktury będą nieprzemyślane, a całość robiona na "Wydaje mi się, że tak będzie ok", po czym programista za 2 tygodnie będzie przeklinał wcześniejszy pomysł, bo zapędzi się w ślepą uliczkę z której wyjście będzie obejściem problemu.
Po to są diagramy by takich sytuacji nie było.

Jak się pisze bottom-up to może tak być. Jak piszesz top-down to tego typu problemy, szczególnie w projekcie rozwiąznia wykryjesz dużo dużo wcześniej. A nawet jeśli pojawi się problem to od tego jest refaktoring ;)

Zazwyczaj programista nie stworzy odpowiednich struktur i podczas zmian potrzeb biznesowych lub podczas dodawania nowych funkcji:

  • Musi przebudować wcześniejsze elementy
  • Musi przenieść wcześniejsze elementy
  • Musi zmienić elementy (najgorsza rzecz)
  • Musi wymyślać obejścia, bo istniejąca struktura jest nieelastyczna (trudno wymyśleć w głowie elastyczną formę dla normalnej wielkości aplikacji)

Nie rozumiem jaki to ma związek z malowaniem diagramów albo zabawą w Waterfall ;] Zmienne wymagania i wynikający z niego ciągły refaktoring kodu to są fakty. Nie da się tego ominąć i nawet jak będziesz miał milion diagramów to się nie zmieni. Twierdzisz że diagram pomaga w napisaniu lepszego kodu? Ale niby czemu? To czy ktoś napisze elastyczny kod czy nie, to kwestia kodera a nie tego czy namalował UMLa do tego kodu czy nie. No chyba że zakładamy że chodzi o to że malując UMLa i pisząc kod poświęcił więcej czasu na myslenie niż gdyby tylko pisał kod. Ale w takim razie można po prostu więcej mysleć w trakcie pisania ;]
Ostatniego zdania nie rozumiem. Przeciez to oczywiste że nikt nie wymyśla w głowie całej aplikacji na wszystkich mozliwych jej poziomach. To nie ma sensu. Zresztą pisałem już wcześniej - jeśli mamy skomplikowany przepływ albo musimy sie zastanowić jak coś zrealizowac to diagram stanowi wartośc dodaną. Jeśli nie, to nie.

Wykonanie diagramu zajmie niewiele czasu, programista będzie miał mocny architektoniczny projekt
(...)
Natomiast w dużych aplikacjach brak utworzenia diagramu skorńczy się katastrofą w postaci licznych błędów architktonicznych, które będzie trzeba naprawiać

A od kiedy fakt posiadania diagramu architektury sprawia że achitektura projektu jest dobra? :D Pracuje aktualnie w miejscu gdzie króluje niemalże "document driven development", do wszystkiego są formalne dokumenty, do wszystkiego są rzeczowe opisy, diagramy etc. I wcale nie sprawia to magicznie że tak tworzone systemy są wolne od błędów, hacków, workaroundów ;) Bo liczy się to czy w projekcie sa ogarnięci architekci a nie to czy namalujesz 100 diagramów czy też nie ;]

3

A to niby czemu? Jeśli kod jest pisany top-down to moim zdaniem obraz całości jest taki sam.

Nie masz obrazu całości. Myślisz aktualnie an innym poziomie abstrakcji.
Jeśli masz do zaimplementowania bibliotekę do obróbki grafiki to ok - programujesz top-down i może wyjść to całkiem nieźle (chociaż gwarantuję, że architektura będzie i tak gorsza niż gdyby ją przemyśleć na diagramie), problem polega na tym, że cała aplikacja nie polega tylko na tym jednym elemencie jakim jest dll-ka graficzna (w tym przykładzie), ale X innych bibliotek i wszystkie ze sobą powiązane w jakiś sposób.
W takim przypadku programowanie zstępujące ma się nijak do dobrej architektury, gdyż nie widzisz całości programu, a jedynie jego modularność.

Programując top-down myślisz o modularności, ale nie za bardzo wiesz jak połączyć ze sobą odległe elementy aplikacji, gdyż ten poziom abstrakcji jest daleki od aktualnie wykonywanej pracy. Co za tym idzie - małe moduły są przemyślane na niskim poziomie, zaś na wysokim poziomie to wszystko ze sobą nie jest dobrze połączone lub też są klasy, obiekty i ogólne elementy w kodzie umieszczone w złych miejscach, gdyż w danym okresie czasu wydawało się to sensowne.

Problem z programowaniem (jakimikolwiek technikami) bez przystąpienia do stworzenia diagramu polega na tym, że brakuje całości obrazu i tworzone elementy w danym czasie wydają się mieć sens. Potem jednak nadchodzi czas dodania nowych rzeczy i kod przestaje mieć tyle sensu.
W tym przypadku mamy dwa wyjścia:

  • Robimy obejście - czyli w zasadzie psujemy kod.
  • Robimy Refaktoring - czyli w zasadzie tracimy czas, który można było zaoszczędzić tworząc diagram i wcześniej wychwycić pewne zależności w kodzie.

Nigdy nie byłem świadkiem takiej sytuacji. Problemy zwykle pojawiają się już w trakcie implementacji bo wcześniej po prostu trudno jest ocenić czy coś będzie problematyczne czy nie. Póki nie spróbujesz, nie będziesz wiedział.

Niestety, ale to świadczy tylko o tym, że nigdy nie stworzyłeś lub też nigdy nie pracowałeś z dobrze zaprojektowanym diagramem.
Zły diagram jest gorszy od braku diagramu, gdyż ten pierwszy powoduje zamęt i błędy, a brak diagramu przynajmniej nic nie psuje.

Diagramy trzeba umieć robić i z mojego doświadczenia wynika, że stworzenie dobrego diagramu rozwiązuje około 50-75% problemów, które wyszłyby na jaw przy procesie implementacyjnym. Oczywiście zależne jest to od wielkości projektu i jego zaawansowania.

Pracowałem w swoim życiu zarówno bez diagramów jak i z diagramami. jednoznacznie mogę powiedzieć, że stworzenie diagramu powoduje, że program pisany jest dużo szybciej, bezpieczniej, bardziej przemyślanie i co najważniejsze - elastycznie. Programując zstępująco nie osiągnie się takiej elastyczności, gdyż programista ogranicza swój punkt widzenia tylko do tego nad czym aktualnie pracuje.

Jak się pisze bottom-up to może tak być. Jak piszesz top-down to tego typu problemy, szczególnie w projekcie rozwiąznia wykryjesz dużo dużo wcześniej. A nawet jeśli pojawi się problem to od tego jest refaktoring

Refkatoring to coś o czym pisałeś wcześniej, ale w kontekście diagramu. Otóż refaktoring to ratowanie kodu i zajmowanie czasu, który to czas można było zaoszczędzić tworząc sensowny diagram. Gdy aplikacja posiada jakikolwiek diagram całości, refkatoring zdarza się nadwyraz rzadko i zazwyczaj z błędów programisty, gdyż nie zastosował się do wymogów.
Programując natomiast bez diagramu, refaktoring jest kolejnym krokiem iteracji w procesie implementacji, co z kolei zajmuje niepotrzebnie czas (bo można było się pozbyć tej iteracji robiąc diagram) oraz oznacza, że kod wcześniej pisany był błędnie zaprojektowany, co jest dowodem na to, że nie da się zaprojektować aplikacji poprawnie bez diagramu, gdyż wszelkie takie próby kończą się prędzej czy później przebudową struktur i refkatoryzacją większą lub mniejszą.

Nie rozumiem jaki to ma związek z malowaniem diagramów albo zabawą w Waterfall ;] Zmienne wymagania i wynikający z niego ciągły refaktoring kodu to są fakty

Otóż to. Są to fakty, na które trzeba się przygotować. Pisząc kod myśląc tylko o realizacji aktualnych wymagań nie napiszesz kodu elastycznie. Elastycznie aplikację możesz napisać tylko wtedy kiedy widzisz całość jej potrzeb. Wtedy też łatwiej ocenisz jakie potrzeby mogą wystąpić w przyszłości.

Nie da się tego ominąć i nawet jak będziesz miał milion diagramów to się nie zmieni. Twierdzisz że diagram pomaga w napisaniu lepszego kodu? Ale niby czemu?

Oczywiście, że da się pominąć. Refaktoring, który znasz jest częścią iteracji wytwarzania oprogramowania, ale gdy masz diagram całej aplikacji refaktoring nie jest potrzebny, gdyż struktura jest od początku implementacji znana. Co byś tutaj chciał refkatorować? Jedynie błędy ludzkie - nie przystosowanie do wymogów jakościowych, ale to jest już czynnik ludzki.

Diagram poprawia jakość kodu, gdyż od początku kod pisany będzie zgodnie z obowiązującymi wymogami biznesowymi oraz z tymi które mogą wystąpić.
W ten sposób klasy i struktury w aplikacji mają dużo lepsza złożoność oraz połączenia między sobą aniżeli programując je bez przemyślenia całej aplikacji.
Z tego też powodu jakość kodu wzrasta - jakość, którą w Twoim przypadku próbujesz nadgonić poprzez refaktoring. Niestety sam refaktoring wszystkiego nie załatwi, gdyż przy dużej złożoności aplikacji będzie on bardzo czasochłonny i trudny.

To czy ktoś napisze elastyczny kod czy nie, to kwestia kodera a nie tego czy namalował UMLa do tego kodu czy nie.

Chyba nie bardzo masz rację. Otóż UML w swoim pojęciu jest zbiorem klas i metod. Architektonicznie zaprojektowana aplikacja - programista ma tylko przelać na kod to co jest już zaprojektowane.

No chyba że zakładamy że chodzi o to że malując UMLa i pisząc kod poświęcił więcej czasu na myslenie niż gdyby tylko pisał kod. Ale w takim razie można po prostu więcej mysleć w trakcie pisania ;]

Niestety znów nie masz racji. Robiąc diagram robisz cały architektoniczny pomysł na aplikację i go weryfikujesz w różny sposób.
Pisząc i "więcej myśląc" nie zrobisz tego, gdyż będziesz miał nadal obraz tylko pewnej części aplikacji a nie jej całego kształtu. Owszem pozwoli to zaimplementować dane funkcjonalności, ale nie spowoduje to dobrej architektonicznej budowy. Do tego wymagany jest podgląd całości, a tego na poziomie implementacji z pominięciem diagramu się po prostu nie ma.

Ostatniego zdania nie rozumiem. Przeciez to oczywiste że nikt nie wymyśla w głowie całej aplikacji na wszystkich mozliwych jej poziomach. To nie ma sensu. Zresztą pisałem już wcześniej - jeśli mamy skomplikowany przepływ albo musimy sie zastanowić jak coś zrealizowac to diagram stanowi wartośc dodaną. Jeśli nie, to nie.

Diagram ZAWSZE stanowi wartość dodaną i nie ma sytuacji w której by nie był przydatny. Są sytuacje gdy taki diagram jest wstępnie prosty i niezbyt skomplikowany. Struktura całej aplikacji powinna być znana przed przystąpieniem do implementacji, w innym przypadku może mieć to negatywne skutki na jakości kodu jak i funkcjonalności. To, ze niekiedy nie wszystkie aspekty biznesowe sa znane przed przystąpieniem do implementacji to inna sprawa. Ja opsiuję bardziej świat idealny, nie zaś potrzeby realne aktualnych klientów biznesowych.

A od kiedy fakt posiadania diagramu architektury sprawia że achitektura projektu jest dobra?
Pracuje aktualnie w miejscu gdzie króluje niemalże "document driven development", do wszystkiego są formalne dokumenty, do wszystkiego są rzeczowe opisy, diagramy etc. I wcale nie sprawia to magicznie że tak tworzone systemy są wolne od błędów, hacków, workaroundów ;) Bo liczy się to czy w projekcie sa ogarnięci architekci a nie to czy namalujesz 100 diagramów czy też nie ;]

Jeśli przemyślisz architekturę w sposób wystarczająco długi i dobry, to dlaczego diagram miałby być źle wykonany?
To o czym piszesz to popadanie w dokumentacyjne bagno i nic dobrego nie przynosi. Ja nie pisałem nigdzie, że duża liczba dokumentów pozwala na lepsza jakość tylko napisałem o tym, że diagram (nawet prosty) powoduje łatwiejszy sposób pisania aplikacji i jest zalecany, gdyż dużo lepsza jest cała jakość wytwarzanego oprogramowania. Popadanie w skrajnie drugą stronę powoduje równie duże problemy.
Poza tym zbiór zasad Agile mówi coś własnie o nadmiarowej biurokracji podczas pisania oprogramowania :)

3

Diagramy trzeba umieć robić i z mojego doświadczenia wynika, że stworzenie dobrego diagramu rozwiązuje około 50-75% problemów, które wyszłyby na jaw przy procesie implementacyjnym

To znaczy jedynie że diagram jest zrobiony na podobnym poziomie szczegółowości co kod źródłowy. Ergo zamiast niego można było w tym czasie napisać / prototypować kod. Zysk z robienia diagramu zerowy bo jedyne co zrobiłeś to po prostu "namalowałeś" kod.

refaktoring jest kolejnym krokiem iteracji w procesie implementacji, co z kolei zajmuje niepotrzebnie czas (bo można było się pozbyć tej iteracji robiąc diagram) oraz oznacza, że kod wcześniej pisany był błędnie zaprojektowany

Refaktoring oznacza jedynie że "coś dało sie napisać lepiej". Absolutnie nie oznacza że kod był napisany źle albo źle zaprojektowany. Kod mógł być idealny, ale zmieniły się wymagania, zmieniła się technologia i w efekcie zmienić musiał się kod. Nie ma to nic wspólnego z tym czy kod był dobrze czy źle napisany. Wszystkiego nie przewidzisz, choćbyś był jasnowidzem. Nie da się napisać kodu odpornego na wszystkie możliwe zmiany wymagań.

Jeśli przemyślisz architekturę w sposób wystarczająco długi i dobry, to dlaczego diagram miałby być źle wykonany?

Bo diagram prezentuje AKTUALNY rys architektury. Pasujący do AKTUALNYCH wymagań klienta. A jak klient uzna że jednak zmienił zdanie, to moze się okazać że trzeba będzie wprowadzić sporo zmian i ta "dobrze przemyślana architektura" leci do kosza. Bo była dobrana i przemyślana pod kątem konkretnego rozwiązania, które przestało obowiązywać.

A teraz perełki:

Otóż refaktoring to ratowanie kodu i zajmowanie czasu, który to czas można było zaoszczędzić tworząc sensowny diagram.
Gdy aplikacja posiada jakikolwiek diagram całości, refkatoring zdarza się nadwyraz rzadko i zazwyczaj z błędów programisty, gdyż nie zastosował się do wymogów.
(...)
Diagram poprawia jakość kodu, gdyż od początku kod pisany będzie zgodnie z obowiązującymi wymogami biznesowymi oraz z tymi które mogą wystąpić.
(...)
programista ma tylko przelać na kod to co jest już zaprojektowane.
(...)
Struktura całej aplikacji powinna być znana przed przystąpieniem do implementacji, w innym przypadku może mieć to negatywne skutki na jakości kodu jak i funkcjonalności.
(...)

= Waterfall, o którym od 30 lat wiemy że nie działa i działać nie będzie. Poczytaj na ten temat, skoro jeszcze o tym nie wiesz...

Ja opsiuję bardziej świat idealny, nie zaś potrzeby realne aktualnych klientów biznesowych.

No tak, to tak jak z tym idealnym sposobem dojenia krowy wymyslonym przez fizków, który działa dla krowy zawieszonej w próżni w stanie nieważkości emitujacej mleko jednostajnie we wszystkich kierunkach... Nijak się to ma do rzeczywistości.
Jeśli piszesz coś większego niz hello world to nie ma takiej możliwości żeby wszystkie wymagania były znane wcześniej i żeby można było zaprojektować cały system przed przystąpieniem do implementacji. Dlatego dzisiaj stosuje się modele przyrostowe i częste dema dla klienta.

W praktyce te twoje projekty i diagramy które opisujesz, gdyby faktycznie były takie doskonałe, można by wykorzystać do automatycznej generacji kodu. No bo skoro diagram dokładnie opisuje jakieś zagadnienie i jeszcze do tego rozwiązuje wszelkie problemy związane z projektem, to czemu nie generować kodu z diagramów? Nie jest to przecież trudne. Tylko że zrobienie takiego diagramu kosztowałoby dokładnie tyle samo czasu i pracy (albo i więcej) jak pisanie kodu. W praktyce ten diagram to byłby "namalowany" kod, nic więcej. Ja nie twierdzę że malując diagram nie uda sie przemysleć i wychwycić pewnych problemów. Twierdzę tylko że dokładnie to samo można zrobić pisząc kod. Tylko że pisząc kod można wychwycić tych problemów jeszcze więcej. Bo nie wszystko widać na diagramie. Diagram nie pokaże ci problemów z niezgodnościa bibliotek, protokołów czy technologii. A takie problemy mogą skutkować diametralnymi zmianami w strukturze aplikacji bo moze się okazać że cóż nam po idealnym diagramie architektury systemu, skoro nie da się go zaimplementować...

0

To znaczy jedynie że diagram jest zrobiony na podobnym poziomie szczegółowości co kod źródłowy. Ergo zamiast niego można było w tym czasie napisać / prototypować kod. Zysk z robienia diagramu zerowy bo jedyne co zrobiłeś to po prostu "namalowałeś" kod.

Chyba nie rozumiesz co napisałem.
Przeczytaj raz jeszcze: "że stworzenie dobrego diagramu rozwiązuje około 50-75% problemów, które wyszłyby na jaw przy procesie implementacyjnym".

Refaktoring oznacza jedynie że "coś dało sie napisać lepiej". Absolutnie nie oznacza że kod był napisany źle albo źle zaprojektowany. Kod mógł być idealny, ale zmieniły się wymagania,

Zmiana wymagań NIGDY ale to nigdy nie powinna powodować zmian w kodzie już napisanym. Otwartość na rozszerzenie, ale zamknięcie na modyfikalność.
To o czym piszesz oznacza bardzo zły kod.

zmieniła się technologia i w efekcie zmienić musiał się kod.

Zmiana technologii też nie powinna powodować zmian w biznesie. Biznes jest odseparowalną częścią od technologii. Ten kawałek tekstu, który napisałeś oznacza źle zaprojektowaną aplikację.

Wszystkiego nie przewidzisz, choćbyś był jasnowidzem. Nie da się napisać kodu odpornego na wszystkie możliwe zmiany wymagań.

Diagram umożliwia wychwycenie więcej możliwych zmian oraz więcej potencjalnych problemów niż go nie zrobienie. To chyba oczywiste.

Bo diagram prezentuje AKTUALNY rys architektury. Pasujący do AKTUALNYCH wymagań klienta. A jak klient uzna że jednak zmienił zdanie, to moze się okazać że trzeba będzie wprowadzić sporo zmian i ta "dobrze przemyślana architektura" leci do kosza. Bo była dobrana i przemyślana pod kątem konkretnego rozwiązania, które przestało obowiązywać.

Znów popełniasz podstawowy błąd programistyczny. Nie ma czegoś takiego jak zmiana biznesowa powoduje zmiany w kodzie. Zmiana biznesowa rozszerza istniejący kod o nowe funkcje a nie go modyfikuje. To oznacza dobrze zaprojektowaną aplikację. Gdyby za każdym razem gdy klient zmieni zdanie miała nastąpić zmiana w kozdie istniejących elementów to byłby to jednoznaczny znak, że architektura aplikacja leży na całej linii.

= Waterfall, o którym od 30 lat wiemy że nie działa i działać nie będzie. Poczytaj na ten temat, skoro jeszcze o tym nie wiesz...

Bzdury nie poparte argumentami. A ja Ci mogę podać argument, że to co napisałem działa. Może po prostu brakuje Ci nieco wiedzy by zrozumieć o czym piszę? To by wyjaśniało Twoje zdanie na temat modyfikalności kodu według potrzeb klienta.

No tak, to tak jak z tym idealnym sposobem dojenia krowy wymyslonym przez fizków, który działa dla krowy zawieszonej w próżni w stanie nieważkości emitujacej mleko jednostajnie we wszystkich kierunkach... Nijak się to ma do rzeczywistości.
Jeśli piszesz coś większego niz hello world to nie ma takiej możliwości żeby wszystkie wymagania były znane wcześniej i żeby można było zaprojektować cały system przed przystąpieniem do implementacji. Dlatego dzisiaj stosuje się modele przyrostowe i częste dema dla klienta.

Częste dema dla klienta, a może po prostu metodyka Agile zaleca własnie stosowanie diagramów opisujących funkcjonowanie systemu bez nadmiarowej biurokracji. Więc tak jakby...

W praktyce te twoje projekty i diagramy które opisujesz, gdyby faktycznie były takie doskonałe, można by wykorzystać do automatycznej generacji kodu. No bo skoro diagram dokładnie opisuje jakieś zagadnienie i jeszcze do tego rozwiązuje wszelkie problemy związane z projektem, to czemu nie generować kodu z diagramów? Nie jest to przecież trudne.

Aha... czyli nie słyszałeś o narzędziach generujących szkielety klas itp?

No cóż kończę temat bo widzę, iż Ty o niebie ja o chlebie :) Miłego dnia.

0

Zmiana wymagań NIGDY ale to nigdy nie powinna powodować zmian w kodzie już napisanym.
(...)
Znów popełniasz podstawowy błąd programistyczny. Nie ma czegoś takiego jak zmiana biznesowa powoduje zmiany w kodzie. Zmiana biznesowa rozszerza istniejący kod o nowe funkcje a nie go modyfikuje.

Opisz jak chcesz to osiągnąć.

2

Zmiana wymagań NIGDY ale to nigdy nie powinna powodować zmian w kodzie już napisanym. Otwartość na rozszerzenie, ale zamknięcie na modyfikalność.
To o czym piszesz oznacza bardzo zły kod.

Tak to chyba tylko w tym idealnym świecie o którym wcześniej pisałeś :D Super by było gdyby w realnym świecie tak było, ale nie jest. Głównie dlatego że "klient ma zawsze racje" i Manager razem z działem Sales nie są zainteresowani twoim "nie da się zrobić XYZ (bo trzeba by przepisać 1/3 systemu od zera)". Bo jakby ktoś w połowie budowy mostu powiedział że jednak wolałby taki podwieszany a nie taki na betonowych podporach to by go wyśmiali. A w firmach robiących soft się na to zgodzą ;] Jeśli nigdy nie byłeś świadkiem takiej sytuacji to dobrze dla ciebie. Ale nie zmienia to faktu, że takie sytuacje są i to wcale nie rzadko ;]

Bzdury nie poparte argumentami. A ja Ci mogę podać argument, że to co napisałem działa.

No tak, setki Waterfallowych projektów zakończone fiaskiem nie są ważne. Ważne że ty widziałeś kiedyś projekt który się udał :D :D

Aha... czyli nie słyszałeś o narzędziach generujących szkielety klas itp?

Słyszałeś, tylko że one wcale nie generują całej aplikacji. A twoje diagramy, skoro wychwytują nawet problemy implementacyjne, muszą być mega szczegółowe, czyli powinno się dać generować z nich cały system... ;] Przyznaj się, programujesz w IBM Rhapsody? :P

1

Mam wrazenie ze Pijany krawiec nie miales wiecej jak 1-2 projektow.

Oczywiscie male projekty mozesz tak zaprojektowac (i tez nie do konca, no ale zalozmy)
Ale z tym ze zmiana biznesowa nie zmienia kodu tylko go rozszerza... Kurde to co ja robilem w poprzednich firmach? Klient mowil ze jest bug bo on nie chcial by TAK dzialala logika tylko SIAK i trzebabylo przepisywac... hmmm czyli w sumie bugi = feature? Fajnie :)

Projektowanie wszystkiego pod najdrobniejszy szczegol nie ma sensu. Nigdy w zyciu nie uda Ci sie przewidziec wszystkiego bez kodzenia. Baa my po pol roku zauwazylismy ze zapomnielismy o czyms dosc powaznym i przedyskutowalismy to wlasnie. A dlaczego zapomnielismy? Nie bo nie bylo design'ow do tego, oczywiscie byly. Ale jak wzielismy sie za implementacje pewnej czesci systemu to nagle oslenienie... ze cos potrzebujemy.

Refaktoryzacja zdarza sie rzadko?
.
.
.
.
.
.
.
.
.
.
.
.
:DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD

0

@Shalom, skąd Ty w tym wątku wziąłeś ten waterfall, o którym nikt poza Tobą nie pisze? Posiadanie projektu systemu nie oznacza od razu, że projekt jest wykonywany kaskadowo.

Jak niby lepiej niż UML przekazać programistom wyniki pracy analityków biznesowych? Referatem? Opowieścią? Filmem?
UML jest jasny - taka klasa ma takie metody i pola, taki proces przebiega zgodnie z daną sekwencją, itp. To najlepszy wspólny język między ludźmi, którzy bardziej rozumieją potrzeby klienta, a tymi, którzy piszą kod.
Jak wymagania klienta się zmieniają, to zmienia się też projekt aplikacji, i na jego podstawie wprowadza zmiany. Jeśli wymaga się od programisty, aby od razu zmieniał kod, to jest to patologia taka sama jak wprowadzanie zmian bezpośrednio na produkcji.

0

@somekind przecież gość sam napisał

programista ma tylko przelać na kod to co jest już zaprojektowane.
(...)
Struktura całej aplikacji powinna być znana przed przystąpieniem do implementacji

A to jest właśnie idea waterfallu. Że najpierw zbieramy wymagania, potem robimy szczegółowy projekt aplikacji a dopiero potem przystępujemy do implementacji ;]

Zauważ też że @Pijany Krawiec wcale nie pisał o UMLu jako interfejsu między programistami a innymi ludźmi (o takim to akurat ja pisałem), tylko o UMLu jako kroku który wykonuje programista przed przystąpieniem do implementacji.

2

W Waterfallu faza projektowa wystepuje jednorazowo, na poczatku. W zwinnych metodykach tez jest faza projektowa tylko jest realizowana iteracyjnie (tak samo jak inne etapy).

0

@Chdzk caly fun wlasnie na tym polega aby bylo wszystko zakrecone, skomlikowane i wymagalo jakiegos wysilku umyslowego. Ja nie pracuje zawodowo jako progamista, wiec nie musi byc wszystko jakos optymalne. Uzywam po prostu mozgu, zadnego projektowania, rysownia itp. Jest cos w tym zlego?

2

Póki robisz programy dla siebie może i to wystarczy. Popracuj jednak w dużej firmie przy dużym projekcie gdzie będziesz musiał spełniać nie swoje ale **czyjeś **kryteria. Zobaczymy czy UML będzie wtedy zakręcony i skomplikowany, czy też będzie Twoim przyjacielem :)

Inna sprawa, że w dobrej filmie programista nie będzie sam robił diagramów tylko przygotuje je analityk po konsultacjach z biznesem.

1

Jak niby lepiej niż UML przekazać programistom wyniki pracy analityków biznesowych? Referatem? Opowieścią? Filmem?

Za dużo widziałem cudów wymyślonych w diagramach przez tzw. "analityków", żeby wierzyć, że analitycy biznesowi namalują diagramy, które później będzie można zaimplementować.

Referatem i opowieścią - bardzo dobry pomysł. Filmem może mniej, bo przydałaby się jakaś interakcja, aby wyprostować bzdury wymyślone przez analityków. Wielu analityków zapomina, że UML jest tylko dodatkiem do specyfikacji, a nie specyfikacją.

Mieliśmy w poprzedniej firmie kiedyś taką zabawę z analitykiem - klient chciał jakąś nową funkcję, gadał z analitykiem, analityk wyrysował programistom diagramy i dokumentację, programiści zaprogramowali, klient na to, że nie o to mu chodziło. Sytuacja powtórzyła się jeszcze 3 razy, zleciał chyba na to cały miesiąc, w końcu nasz PM się zdenerwował i umówił klienta na spotkanie bezpośrednio z programistami. Problem został rozwiązany w jeden dzień.

A wracając do oryginalnego tematu wątku.
Jeśli ja gadam bezpośrednio z klientem, to nie potrzebuję UML ani żadnego projektowania na papierze. Wystarczy, że zrozumiem, czego potrzebuje klient i przelewam to na kod. I tak, robię zwykle bottom-up, bo w ten sposób jestem w stanie dość szybko mieć działające coś, co mogę pokazać klientowi. Nawet jeśli okaże się, że trzeba pozmieniać / uzupełnić, to w wyniku pierwszej iteracji mam wiele gotowych komponentów, które mogę wykorzystać, i których raczej nie muszę zmieniać. Właśnie cała sztuka pisania dobrego kodu polega na tym, abym nie musiał myśleć o całym systemie jak piszę kod, bo zwykle w dużych projektach nie ma ani jednej osoby, która ma "wizję całości", ani po stronie klienta, ani wykonawcy.

Z UMLem główny problem jest taki, ze UML wszystko przyjmie, nawet największy bezsens. Kompilator nie. Dlatego wolę robić projekt w kodzie niż w UML. UML jest spoko tylko do komunikacji z ludźmi nie rozumiejącymi kodu.

Co do analogii z budownictwem - w budownictwie niby się wszystko projektuje co do śrubki, a i tak na budowie zawsze wychodzą różne, czasem bardzo poważne usterki oraz "nie-da-się". Systuacja ze zmianą mostu na podwieszony może jest przesadzona, ale historię z koniecznością wykuwania dodatkowych otworów w już wylanym stropie a następnie przeliczaniu konstrukcji i dorabianiu odpowiednich wzmocnień aby strop się nie zapadł znam z pierwszej ręki. I to nie w domku jednorodzinnym a budynku biurowym za dziesiątki mln, gdzie raczej projekt był sprawdzany wielokrotnie. :D

1
Krolik napisał(a):

Za dużo widziałem cudów wymyślonych w diagramach przez tzw. "analityków", żeby wierzyć, że analitycy biznesowi namalują diagramy, które później będzie można zaimplementować.

Ja brałem udział w jednym projekcie z pełną dokumentacją w UML, i była całkiem niezła. Nie była doskonała, o niektóre rzeczy trzeba było się dopytać, zdarzały się niespójności, ale i tak miała jakość większą niż większość kodu, który widziałem w życiu.

Spokojnie można opisać przy użyciu UML encje i procesy biznesowe systemu. Za to opisywanie każdego pojedynczego algorytmu i klasy byłoby już bez sensu. Rozsądek przede wszystkim.

Wielu analityków zapomina, że UML jest tylko dodatkiem do specyfikacji, a nie specyfikacją.

Dobry UML wystarczy za całą specyfikację. (Wskazówka - do diagramów można dodawać notatki.)

Mieliśmy w poprzedniej firmie kiedyś taką zabawę z analitykiem - klient chciał jakąś nową funkcję, gadał z analitykiem, analityk wyrysował programistom diagramy i dokumentację, programiści zaprogramowali, klient na to, że nie o to mu chodziło. Sytuacja powtórzyła się jeszcze 3 razy, zleciał chyba na to cały miesiąc, w końcu nasz PM się zdenerwował i umówił klienta na spotkanie bezpośrednio z programistami. Problem został rozwiązany w jeden dzień.

No, ale kto zatrudnił tego kiepskiego analityka?

1 użytkowników online, w tym zalogowanych: 0, gości: 1