GoldenLine
Zaloguj się
Michał A.

Michał A. Programista
Microsoft Dynamics
AX

Temat: Architektura aplikacji windows

Witam,

Chciałbym usłyszeć waszą opinię. Czy pisząc jakąkolwiek aplikację (głównie mam na myśli aplikacje pod windows) stosujecie jakaś architekturę takich aplikacji. Podział na warstwy biznesowe, warstwę bazy danych i prezentacji? Niezależnie od wielkości i zastosowania tej aplikacji.

Czy macie jakieś wybrane architektury? Co sądzicie o http://www.mvcsharp.org/ tym frameworku. Czy może lepiej iść w zupełnie innym kierunku?

Pozdrawiam
Link do wypowiedziLink

konto usunięte

Temat: Architektura aplikacji windows

Dobieram wzorzec do aplikacji. MVP jest dobre, wymaga troche nakladu jak implementujesz to sam, ale zyskujesz prostote i przejrzystosc kodu ktora docenisz po tym jak aplikacja z malego programiku rozrosnie Ci sie do troche wiekszego programu albo duzego projektu skladajacego sie z wielu aplikacji, serwisow, webserwisow itp itd.

Poczytaj na ten temat w patterns&practices z MS, czesto mozesz znalezc gotowe scenariusze ktore moga byc punktem wyjscia dla Twojego rozwiazania.

Co do mvcsharp to nie znam, wiec sie nie wypowiadam :)
Link do wypowiedziLink
Acg N.

Acg N. .

Temat: Architektura aplikacji windows

Jeśli przyjąć, że np. NHibernate stanowi niezależną warstwę, to "samo się dzieli na 2 warstwy" :)

To indywidualna kwestia. Raczej nie, w aplikacjach nawet większych, jeśli nie będzie w nich mieszania technologii (czyli elementów wymiennych), i sposobów prezentacji danych (wspomniane już webserwisy). Za to programowanie modularne i długo analizowany model obiektowy - jednak taki, jaki pasuje mnie, z punktu widzenia tego, co aplikacja ma robić, a nie pakowania go na siłę w "dokument/widok" czy "model/widok/kontroler".

Czyli podejście - "z modelu obiektowego samodzielnie wyniknie odpowiednia struktura" zamiast "struktura ma być dopasowana do modelu". Ale nie jako "11 przykazanie".

Nie odważyłym się jednego podejścia do każdego typu aplikacji. Tam, gdzie aplikacja jest stricte biznesowa, zwykle podejście: "formatka = funkcjonalność" (fragment odpowiedzialny za konkretną funkcjonalność - od bazy po widok - zamknięty jest w osobnym module, formatce). Tam, gdzie "naukowo-techniczna" - zdecydowanie wzorzec rozdzielający dane od widoku i logiki, np. gdy dany problem ma do wyboru kilka algorytmów (aplikacje inzynierskie, (de)kompresory).

Z modelu obiektowego tak naprawdę wyjdzie tak czy inaczej podział na elementy widoku i dokumentu. Np. weźmy pod uwagę listę, która potrafi wyświetlać różne edytory i reagować na zdarzenia zależnie od tego, jakiego typu dane przyjmuje w komórce - sama taka lista (kontrolka) jest w modelu MVC, a i ona sama stanowi element widoku aplikacji.

Wszystko zależy od tego, czy i jak planujesz rozwijać aplikację, czy będzie nad nią pracował jeden, czy wiele zespółów. Czy będzie wiele widoków a jeden dostawca, czy różni dostawcy (provider) danych a jeden widok, czy wszystko na raz. A może jeszcze logika będzie "wymienialna"? A jeśli ani jedno, ani drugie, ani trzecie, to szkoda czasu.

Wg mnie nie jest dobrym podejściem sztywne stosowanie sztywnych reguł niezależnie od tego, czy trzeba, czy nie. Oczywiście od wieków toczą się wojny na ten temat :)

W końcu nawet do słynnego "Dokument/Widok" w MFC dodano... "dialog based" :)
Link do wypowiedziLink
Michał M.

Michał M. Professional .NET
Developer

Temat: Architektura aplikacji windows

Do tej pory stosuje wzorzec MVP, z własnym frameworkiem (napisanym za pomocą jakiegos narzędzia typu Dependency Injection np. Unity) lub korzystając WCSF grupy P&P. W najprostszych aplikacjach, gdzie nie przewiduje się dalszej rozbudowy, ani nie testuje się widoków, używam zwykłego podziału na warstwy (np. "gateway" do bazy etc.), bez specjalnych frameworkow. ASP.NET MVC zajmowałem się jak narazie tylko od strony testowania, w większości wypadków, nie używam w projektach komercyjnych narzędzi, których nie ma wersji finalnej. A poza tym, nie do końca pasował mi do tworzonych aplikacji.
Podstawowa zasada jest moim zdaniem prosta: frameworki/narzędzia/architektura ma byc dobrana do projektu i sposobu w jaki ma powstac a nie odwrotnie. Wspomniane tutaj narzędzia tyczą się aplikacji webowych (takimi głównie się zajmuję), jednak podobna zasada ma też zastowanie w aplikacjach desktopowych. MVP lub MVC nadają się jak najbardziej. Polecam zapoznanie się ze SmartClient Software Factory a jeżeli używasz WPFa to Composite App Guidance for WPF. Generalnie czym większy projekt to tym bardziej warto trzymac się jakiegos modelu. Oszczedza sie mnostwo czasu np przy testowaniu, wyszukiwaniu błędów i wprowadzaniu zmian. Poza tym taka struktura jest czytelna dla wszystkich (przynajmniej powinna byc), a nie tylko dla Ciebie.Michał Miszczyszyn edytował(a) ten post dnia 12.02.09 o godzinie 15:19
Link do wypowiedziLink

konto usunięte

Temat: Architektura aplikacji windows

Michał Andruchów:
Niezależnie od wielkości i zastosowania tej aplikacji.
Nie da się abstrahować architektury od wielkości aplikacji i innych wymagań. Nie będę powtarzał tego co Adrian napisał, ale podpisuję się pod jego postem.

Robiąc małą fuszkę przez tydzień nie mam żadnej architektury - po prostu na szybko tworzę wszystko przy użyciu designerów VS czyli tzw. RAD.
W przeciwnym wypadku - duży projekt, nie zamknięte wymagania, kilku programistów - polecam np. http://www.codeplex.com/CompositeWPF (dla WinfFormów Smart Client Software Factory)

Pozdrawiam
Link do wypowiedziLink
Michał A.

Michał A. Programista
Microsoft Dynamics
AX

Temat: Architektura aplikacji windows

Dzięki Panowie za tak szerokie, merytoryczne i rozbudowane odpowiedzi.
Na pewno trzeba, przy tworzeniu aplikacji przemyśleć wiele czynników jak czytam w powyższych postach. Jest także wiele dokumentacji do przeglądnięcia.
Osobiście stosowałem 3-warstwową architekturę: logika biznesowa, warstwa odpowiedzialna za dostęp do baz danych oraz warstwa prezentacji. Nie miałem okazji tworzyć programów (czytaj większych systemów) jednak patrząc w przyszłość chciałbym wiedzieć nieco więcej.

Architektura programu jest mi potrzebna do porządku kodu w programie który piszę. Chcę wiedzieć za rok bez większych problemów "co autor miał na myśli".

PozdrawiamMichał Andruchów edytował(a) ten post dnia 12.02.09 o godzinie 20:02
Link do wypowiedziLink
Acg N.

Acg N. .

Temat: Architektura aplikacji windows

To przede wszystkim IMHO należy:

- starannie przemyśleć model obiektowy (by "by sam się w głowie układał w logiczną całość" :) )

Jeśli na diagramie UML coś będzie trudne do uzasadnienia, to na mur beton będzie wymagało wysiłku umysłowego za jakiś czas "po ***** ja to tu jest?!".

Bolesna prawda - "brudnych" rozwiązań nie da się często uniknąć tanim kosztem, a wartość funkcji kosztu (szeroko pojętego) jest głównym wskaźnikiem opłacalności projektu...

Zdarza się, że po jakimś czasie, gdy patrzymy na brudny kod (ogólniej - rozwiązanie) umiemy go "oczyścić". Czasem nie. I niech tak zostanie. Ważne jest jednak, by -------->

- komentować (ale nie każdą linijkę kodu, a moduły, algorytmy, spostrzeżenia i wynik co bardziej złożonej gimnastyki myślowej. To, nad czym należało się zastanowić, czyli było nieoczywiste).

Sztuka właściwego (subiektywnie) komentowania kodu to nietrywialne zagadnienie. To faktycznie SZTUKA :)

A dopiero w dalszej kolejności zastanowić się nad pewnymi kwestiami standaryzacji (nieraz nawet za cenę dodatkowej pracy, jak to w modelu obiektowym - co się potem szybko zwraca).Adrian Olszewski edytował(a) ten post dnia 12.02.09 o godzinie 21:05
Link do wypowiedziLink
Daniel Dąbrowski

Daniel Dąbrowski Właściciel, 42n

Temat: Architektura aplikacji windows

Co do komentowania to jezeli pojawiaja sie komentarze w algorytmie to znak ze tam powinna byc wydzielona metoda przyklad:

{

// Super kalkulacja mojego costam w zaleznosci od siakis parametrow
// Jezeli jednak cos jest skonczone to powinno sie dodac 20 a jak
// nie to 10
var costam = x * y - 3.55 + (this.IsComplete ? 20 : 10);

}

powinno byc tak

{

var costam = this.CalculateConditionalyWithCompletion(x, y, this.Complete);

}

jezeli musimy komentowac kod to juz oznacza ze jest on zbyt skomplikowany :)
Link do wypowiedziLink
Acg N.

Acg N. .

Temat: Architektura aplikacji windows

W takim razie często gęsto kod musiałby się składać z samych metod, w których i tak trzeba pisać komentarze, ponieważ przenieśliśmy tam algorytm. A z kolei te komentarze świadczą o potrzebie wydzielenia funkcji, w której znów będzie komentarz, który poinformuje nas, gdzie szukać reszty do tego fragmentu algorytmu. A na koniec jeden wielki komentarz, jak to wszystko działa :)

Za chwilę braknie nazw dla tych metod, albo nazwy będą miały długości tasiemca.

W bardziej złożonych programach co chwila pojawia się problem a to policzenia rozmiarów, przeskalowania, złożonych warunków, a wszystko ma sens, gdy patrzy się na to całościowo, widzi się cały kod, który jest odpowiedzialny za dane zagadnienie. I dopiero takie kompletne zagadnienie można wydelegować do metody, która robi coś od A do Z. Ewentualnie powtarzające się (podobne) bloki kodu deleguje się do metody pomocniczej, sparametryzowanej.

Innymi słowy - jeśli pojawia się komentarz, to zwykle oznacza, że powinien tam być. I przesuwanie czegoś gdzieś z nową nazwą niewiele zmieni, poza tym, że narobi drobnicy, która potem trudno ogarnąć, w dodatku nie widząc całości kodu rozbitego po metodach.
I teraz dziesiątki zmiennych lokalnych w klasie, albo potężne listy parametrów.

Rozsądek nade wszystko. Wszystko jest dla ludzi, ale z umiarem i rozsądkiem.

Metody mają wykonywać konkretne zadania, a nie stawać się zastępnikami dla komentarzy. Szczególnie w algorytmice czy operacjach graficznych.

W dodatku w .NET po to właśnie wprowadzono słowo kluczowe #region / #endregion. Co oczywiście nie oznacza z kolei, że metoda ma mieć po 500 linii kodu i komentarz rozmiarów epopei.

Jeśli okazuje się, że komentarze są makabrycznej długości i to co chwilę, to znaczy, że kuleje analiza funkcjonalna i techniczna, do których to powinny być odwołania w komentarzach (strona, paragraf, punkt, rysunek, etc.).Adrian Olszewski edytował(a) ten post dnia 13.02.09 o godzinie 13:27
Link do wypowiedziLink

konto usunięte

Temat: Architektura aplikacji windows

Daniel Dąbrowski:
jezeli musimy komentowac kod to juz oznacza ze jest on zbyt skomplikowany :)

Podpisuje sie pod komentarzem Adriana. Chcialem dodac, ze komentarz to nie tylko "co kod robi" ale rowniez "po co". Podczas zlozonych procesow biznesowych uruchamianych jest tysiace lub dziesiatki tysiecy metod i wtedy istotne jest DLACZEGO ten kawalek kodu ustawia taki a nie inny stan zmiennej.

Wracajac do pytania. Stosuje najczesciej wartwy DAO, logiki (z IoC), obiektow UI (Value Objects) i interfejsu uzytkownika. Ta struktura wydaje sie byc najbardziej odporna na znaczne zmiany wymagan - z czym mam do czynienia na codzien.
Link do wypowiedziLink
Daniel Dąbrowski

Daniel Dąbrowski Właściciel, 42n

Temat: Architektura aplikacji windows

Jezeli pojawia sie komentarz w algorytmie to znaczy ze z kodu nie wynika co autor mial na mysli... Chyba ze ktos uwielbia pisac komentarze typu

// Jestem super bo teraz zmniejszamy jakis procent na koncie o dokladnie jeden.
AccountRate--;

"Podczas zlozonych procesow biznesowych uruchamianych jest tysiace lub dziesiatki tysiecy metod i wtedy istotne jest DLACZEGO ten kawalek kodu ustawia taki a nie inny stan zmiennej"

??!

Ktorej zmmiennej .. lokalnej ? Bo jezeli mowisz o jakis properties obiektow to po pierwsze
Stosując Single Responsibility Principle ... nie obchodzi mnie ze logika biznesowa posiada 1000 metod Uklad obiektow i ich nazwy powinny byc oczywiste

np.

public void CalculateRateAmount(Account account)
{
var rateStrategy = account.RateStrategy;
if(rateStrategy == null)
rateStrategy = new SimpleRateStrategy(account);

return rateStrategy.CalculateRate();
}

Czy sa potrzebne jakies komentarze w ciele tej metody ?
(Powinien byc tu zastosowany Null Object Pattern ale dla przykladu to pominalem)

Jezeli chcesz opisywac dlaczego ustawiasz wartosc jakiejs lokalnej zmiennej w algorytmie opisującym proces biznesowy to cos jest nie tak.. Chyba ze na zasadzie stosowania jakiegos hacka ale to jest jedyny wyjatek.

Operacje graficzne roznia sie tym od procesow biznesowych ze maja byc szybkie i nie musza byc elastyczne. Ale z tego co sie orientuje watek nie tyczy sie tego typu aplikacji tylko aplikacji biznesowych.

"Co oczywiście nie oznacza z kolei, że metoda ma mieć po 500 linii kodu i komentarz rozmiarów epopei."

No wlasnie ... czytajac dana metode programista ma ja zrozumiec za pierwszym razem a nie pogubic sie juz po 30tej linijce

"I przesuwanie czegoś gdzieś z nową nazwą niewiele zmieni, poza tym, że narobi drobnicy, która potem trudno ogarnąć, w dodatku nie widząc całości kodu rozbitego po metodach.
I teraz dziesiątki zmiennych lokalnych w klasie, albo potężne listy parametrów."

Czy chodzi Ci o pola w klasie ? takie przesuwanie nie doklada pol w klasie. Listy parametrow ? a po co ? Jezeli piszesz jakis komentarz to tyczy sie on np najblizszych kilku linijek kodu wiec jezeli zrobimy przeksztalcenie Extract Method tych linijek to raczej tam nie znajda sie dziesiatki parametrow do metody
Link do wypowiedziLink
Acg N.

Acg N. .

Temat: Architektura aplikacji windows

Ja się nie zamierzam kłócić, ani nie mam czasy na debaty o wyższości świąt jednych nad drugimi :)

Obaj przedstawiliśmy swoje punkty widzenia, a potencjalny czytelnik sobie wybierze, co mu będzie pasować.

Programuję różne rzeczy, odkąd skończyłem 15 lat - i pierdółki, o których nie warto wspominać i duże aplikacje. I rzeczywiście - Twoje podejście także stosowałem, bo ono mówi o ogólnej zasadzie delegowania dobrze określonych bloków kodu do metod. Z tym się nie sprzeczam, bo to jest normalne podejście, nad którym nie trzeba się rozwodzić.

Można komentowanie doprowadzić do absurdu, wiem o tym i na prawdę, NIE musisz tutaj stosować ironii ("jestem super i teraz zmniejszam..."), jeśli dyskutujemy poważnie - a tak zakładam. Od ironicznych dyskusji mam inne forum.

Komentuję to, co uważam, że powinienem skomentować. Pracuję w wielu różnych projektach, z wielu różnych dziedzin i nie mam zamiaru spędzać potem czasu na odcyfrowywaniu tego, co miałem na myśli kiedyś w danym miejscu. Komentuję dla wygody własnej i dla wygody moich potencjalnych następców, którzy będą musieli przegryźć się przez kod.

Masz rację, kod staram się pisać tak, bym mógł do niego możliwie najmniej boleśnie wrócić, nawet zmienne nazywam opisowo + notacja węgierska - bo tak mi wygodniej (chociaż wielu to wyśmiewa, że to archaizm w dobie hintów z typem zmiennej)

Ale wielokrotnie miałem do czynienia z "brudnymi" rozwiązaniami, które były dla mnie wygodne, szybkie, natomiast wymagały "rozgryzienia" problemu i z punktu widzenia kosztów były wg mnie odpowiednim rozwiązaniem.

Nie muszę i nie chcę (i nie powinienem) pamiętać, dlaczego dany parametr zakomentowałem (bo chcę o nim pamiętać, a nie jest mi potrzebny) i jak to wpływa na zachowanie aplikacji - np. przy programowaniu z użyciem domen aplikacji czy remotingu pod Vistą, czy ręcznym drukowaniem metapliku ze zrenderowanym raportem..

Programowanie, poza akademickimi przypadkami, to nie zawsze konkurs na piękny, samoopisujący się kod. Decyduje o tym wiele kwestii, a także podejście indywidualne programisty. Nie każdy ma czas na upiększanie kodu zgodnie z każdą możliwą techniką. I nie każdy potem odczytuje kod tak, jak sobie wymyślił autor. Kto programował w dużych grupach programistów, wie, o czym mówię. A nie zawsze się programuje w XP.

O operacjach graficznych nie pisałem w kontekście OpenGL, tylko np. rysowania kontrolki. Osobiście nie lubię mieć mnóstwa metod, które mi "robią" jakąś tam drobnostkę, skoro mogę mieć to w kodzie i opakowane w #region.

Ale - jak mówiłem, to indywidualna kwestia. Przedstawiliśmy obie i niech tak pozostanie. Przecież o to chodzi, by pokazać różne podejścia temu, kto pyta.Adrian Olszewski edytował(a) ten post dnia 13.02.09 o godzinie 18:18
Link do wypowiedziLink
Michał M.

Michał M. Professional .NET
Developer

Temat: Architektura aplikacji windows

Moim zdaniem, jak najwięcej kodu powinno komentowac się samo. A komentarze powinno się ograniczyc to niezbednego minimum aby były łatwiejsze w utrzymaniu. Chociazby dlatego, ze komentarzy sie nie testuje, a czesto podczas refactoringu, cos gdzies przeniesiemy, zmienimy, test przejdzie a komentarz moze zostac stary i nieaktualny. Pisze o tym m.in. Jeffrey Pallermo:

http://jeffreypalermo.com/blog/limiting-code-comments-...

w skrócie:
Problems with code comments:

* Code comments are not compiled
* Code comments are not tested
* Code comments are not verified frequently
* Out-of-date comments have negative consequences
* They are likely to remain when the code changes

Jeffrey podaje także prosty przykład. W moich projektach, zawsze "walcze" z uzywaniem skrótow, nie żywaniem w pelni opisowych nazw. Jest zreszta wiele regul, w jakiej formie uzywac slow odnoszacych sie do roznych elementow kodu.

Ja piszę juz ponad 15 lat, mniej więcej od 12 roku życia i od kilku lat, właśnie staram się ograniczac komentarze, na rzecz dobrze opisującego się kodu.

Osobiscie uwazam, ze najwazniejsza rzecza jest jednak dyscyplina i konsekwencja. Jak wiadomo, balagan zaczyna sie od jednej rozrzuconej rzeczy. Tak tez jest w programowaniu. W jednym miejscu zluzujemy i to jest poczatek balaganu w solucji....
Link do wypowiedziLink

konto usunięte

Temat: Architektura aplikacji windows

Michał Miszczyszyn:
Problems with code comments:

* Code comments are not compiled
* Code comments are not tested
* Code comments are not verified frequently
* Out-of-date comments have negative consequences
* They are likely to remain when the code changes

Jeffrey podaje także prosty przykład. W moich projektach, zawsze "walcze" z uzywaniem skrótow, nie żywaniem w pelni opisowych nazw. Jest zreszta wiele regul, w jakiej formie uzywac slow odnoszacych sie do roznych elementow kodu.

Ja piszę juz ponad 15 lat, mniej więcej od 12 roku życia i od kilku lat, właśnie staram się ograniczac komentarze, na rzecz dobrze opisującego się kodu.

Pracuję na codzień z kodem, na którym wykonujemy głównie maintenance i z mojego doświadczenia wynika coś dokładnie odwrotnego. Skomplikowane operacje wymagają komentarza, nikt bez niego nie znalazłby się w kodzie. Nie chodzi o to co metoda robi w znaczeniu dosłownym tylko w szerszym kontekście. Popatrz na dwa przykłady:

Komentarz bezużyteczny i zbędny:


// kopiuję obiekt rates'ów

this.CurrentQuote.Rates = this.OriginalQuote.Rates;

// ustawiam original rates na false

this.CurrentQuote.Rates.UseOriginalRates = false;


Komentarz jak najbardziej wskazany:


this.CurrentQuote.Rates = this.OriginalQuote.Rates;

// przełączenie kalkulatora w tryb pracy ze zmodyfikowanymi ratesami

this.CurrentQuote.Rates.UseOriginalRates = false;


W drugim przypadku odkrywam więcej niż sam kod mi powie - nie wprost informuję, że ratesy będą zmodyfikowane i że muszę do tego ustawić tą flagę. Nie musi zdarzyć się to w tej metodzie, w tym module lub nawet podsystemie, więc samym kodem nie da się tego opisać. Przy okazji mam za darmo dobry test-case dla NUnita :)

Inna sprawa gdy budujesz prostszy kod, który "umie" opisać się sam, tu się z Tobą w 100% zgadzam.
Link do wypowiedziLink
Acg N.

Acg N. .

Temat: Architektura aplikacji windows

W tym przypadku dałoby się jeszcze zastosować enumerację, one trochę więcej mówią niż true/false, mogą mieć więcej wartości.

Np.
this.CurrentQuote.Rates = RatesType.MODIFIED;


Ale to już wymagałoby refaktoringu istniejącego kodu.

Być może liczba komentarzy zależy także od specyfiki tego, co się pisze.

A także od tego, ile jest czasu na przygotowanie projektu. Że nie wspomnę o analizie i dokumentacji. Teoria teorią, praktyka praktyką. Czasem jest z przedwczoraj na wczoraj.
Obiektowy kod, wzorce, samoopisujący kod, "best practices" - tak, jak się zaczyna od początku i ma się nieco czasu na to. Ale czasem tak nie jest, pisze się prototyp na wczoraj, aby działał, praktycznie bez żadnych analiz (analiza jest w głowie analityka-programisty). Buduje się tylko ogólny wzorzec, a reszta, byle działało do zatwierdzenia. Potem porządkowanie kodu, refaktoring i decyzja, jak to dalej pisać... Takie "pranie brudów", przy założeniu szybkiego prototypu, a potem długich etapów między raportowaniem postępów, gdy powstaną poprawnie napisane zręby aplikacji i można zająć się szczegółami.

Komentarze przydają się, gdy wchodzi się na nowy teren. Dla mnie nowością były domeny aplikacji (system pluginów, ładowanych loaderem ładowanym do nowej domeny), WCF. Komentowałem dlaczego nie ustawiam jakiejś flagi (np. "brudne rozwiązanie"). Potem, z
biegiem czasu komentarze się usuwało, fakt... A najczęściej pchało w #region/#region. Dopiero, gdy #region stawał się zbyt długi i przeszkadzał przy "outline", delegacja do metody.

A czasem komentuję coś, co jest dla mnie oczywiste, ale już z własnego doświadczenia wiem, że mój styl się zmienia i wolę to opisać. Akurat specyfika mojej pracy jeszcze nigdy nie wykazała negatywnych stron komentowania - być może stanie się to w przyszłości.Adrian Olszewski edytował(a) ten post dnia 16.02.09 o godzinie 13:00
Link do wypowiedziLink
Michał M.

Michał M. Professional .NET
Developer

Temat: Architektura aplikacji windows

Nikt nie neguje komentowania. Chodzi tylko o to, aby używac go własciwie, czyli tam gdzie przyniesie wartosc dodaną, a JEŻELI TO MOŻLIWE, to używac własciwie napisanego kodu.
Adrian bardzo trafnie zauważył możliwośc użycia enumeracji, ale oczywiscie wymagało by to refactoringu. Sebastian pokazał, że jedna linia dobrego komentarza jest 1000x lepsza niż dwie bez sensu. Więc chyba wszyscy myślimy podobnie.

PS.
Co do wchodzenia na nowy teren, czy wręcz przy nauce, użycie komentarzy o jakim wspomniał Adrian jest jak najbardziej trafne, jednak usunąłbym częśc z nich w wersji finalnej.

Ja dodam jeszcze, że jak przejmowałem po kimś kod, to przewaznie bardziej zakomentowane kody były o wiele trudniejsze do rozszyfrowania. Były to wręcz przykłady nadużycia komentarzy w bardzo kiepsko napisanym kodzie i przy słabej architekturze.

Na koniec znowu odwołam sie do moich programistycznych idoli, tym razem Martina Fowlera:

"Any fool can write code that a computer can understand...
But only good programmers write code that humans can understand."

I nie ważne czy będzie tam dużo komentarzy czy nie będzie ich w ogóle, liczy się obraz całości.
Link do wypowiedziLink
Daniel Dąbrowski

Daniel Dąbrowski Właściciel, 42n

Temat: Architektura aplikacji windows

Michał Miszczyszyn:
Osobiscie uwazam, ze najwazniejsza rzecza jest jednak dyscyplina i konsekwencja. Jak wiadomo, balagan zaczyna sie od jednej rozrzuconej rzeczy. Tak tez jest w programowaniu. W jednym miejscu zluzujemy i to jest poczatek balaganu w solucji....

Swiete slowa, balagan rodzi balagan :) StyleCop Rulez :)

Co do powyzszego przykladu z rates to komentarz ten spelnia role HACK-a. Gdyz z kodu nie wynika dlaczego jest ustawianie na false... Powinno byc zrefaktorowane jak pisze Adrian

Zakladam ze te linijku kodu czemus sluza wykonaniu jakiegos dzialania .. np "Przelaczeniu trybu kalkulatora" (whatever) czyli mozemy zastosowac kod bedacy zarazem komentarzem

private void SetCalculationToOriginalQuotes()
{
this.CurrentQuote.Rates = this.OriginalQuote.Rates;
this.CurrentQuote.Rates.UseOriginalRates = false;
}

Wg mnie ... nigdy jedna linijka kodu nie stanowi o jakiejs spojnej logice biznesowej wiec nie nalezy jej komentowac a jak jest juz ich kilka to skladaja sie one na metode. Wyjatkiem sa hacki.
Link do wypowiedziLink
Daniel Dąbrowski

Daniel Dąbrowski Właściciel, 42n

Temat: Architektura aplikacji windows

Co do #region to wg mnie mogloby ich nie byc.

Kiedys bylem wielkim zwolennikiem regionow a to tylko dlatego ze w praktyce (co stwierdzilem po latach) bardziej pisalem strukturalnie niz obiektowo. Regiony wciskalem wszedzie. #region Public properties; #region Private properties etc etc a to jest bzdura gdyz:

1. Jezeli zmienimy "widzialność" naszej metody czy pola to wowczas musimy przenosic ja miedzy regionami bo inaczej to (balagan rodzi balagan)

2. Jezeli chcemy sobie grupowac kod na zasadzie publiczne metody do publicznych metod etc to lepiej uzyc sortowania kodu za pomoca ReSharpera

3. Jezeli chcemy za pomoca regionow grupowac sobie metody w klasie wzgledem funkcjonalnosci to oznacza ze zaprzeczamy SRP (Single Responsibility Principle)

4. Jezeli regionow uzywamy wewnatrz ciala metody to wyraznie oznacza ze cialo metody jest zbyt skomplikowane i powinno zostac rozbite na podmetody.

Jedyne uzasadnienie dla regionow widze w ujmowaniu w region kodu generowanego.

Pozatym regiony i tak sa uzytewczne tylko w VS gdzie mozemy sobie naciasnac [+] przy podgladzie kodu np z notepada one sie nie przydadza. A skoro ogladam kod pod VS to jest tam tyle pomocniczych rzeczy w poruszaniu sie po kodzie ze wystarczy
Link do wypowiedziLink
Acg N.

Acg N. .

Temat: Architektura aplikacji windows

Ano właśnie - i tu święte słowa - wszystko zależy od tego, na jakims "poziome ewolucyjnym" jesteśmy jako programiści.

Ja tam nie będę ukrywał, że wymiataczem-koderem nie jestem (i będe nim coraz mniej), bo zajmuję się już nieco innymi rzeczami (analizy, statystyka, organizacja), chociaż cały czas także programuję zawodowo. (Ale na pewno nie wypełnia mi to całości pracy zawodowej.)

Tak więc - skoro wszyscy zmierzamy w podobnym kierunku, to oznacza dla mnie tyle, że generalnie nie jest źle, ale trzeba się dalej uczyć w kierunku pisania jak najbardziej samoopisującego się kodu.

Natomiast nie padła tu jeszcze jedna kwestia - programowanie w grupie o zróżnicowanym poziomie, ale bez XP... Rany, czasem bez komentarza co trzecią linijkę nie pójdzie... ja to przeszedłem......

Zresztą cały kod był tak pisany, że autentycznie wrzucało się w kod
// Do NOT touch! Do NOT touch! Do NOT touch! Do NOT touch!

:)

PS: a kod generowany, jeśli chodzi Ci np. o zapytania SQL/HQL, albo jakiś język interpretowany podawany do parsera (np. "R"), to tak :)Adrian Olszewski edytował(a) ten post dnia 16.02.09 o godzinie 13:52
Link do wypowiedziLink
Daniel Dąbrowski

Daniel Dąbrowski Właściciel, 42n

Temat: Architektura aplikacji windows

Adrian Olszewski:
Natomiast nie padła tu jeszcze jedna kwestia - programowanie w grupie o zróżnicowanym poziomie, ale bez XP... Rany, czasem bez komentarza co trzecią linijkę nie pójdzie... ja to przeszedłem......

Zresztą cały kod był tak pisany, że autentycznie wrzucało się w kod
// Do NOT touch! Do NOT touch! Do NOT touch! Do NOT touch!

:)

PS: a kod generowany, jeśli chodzi Ci np. o zapytania SQL/HQL, albo jakiś język interpretowany podawany do parsera (np. "R"), to tak :)Adrian Olszewski edytował(a) ten post dnia 16.02.09 o godzinie 13:52

Wiem o co Ci chodzi. I tu jest wlasnie pewien paradoks.

Mamy powiedzmy wymiatacza i ucznia. Wiadomo ze Wymiatacz bierze iles razy wiecej za godzine niz uczen. W momencie kiedy wymiatacz napisze jedna linijke komentarza to i tak nie nauczy tym programowac ucznia. Musialby napisac ich znacznie wiecej aby np wyjasnic potrzebe zastosowania takiego wzorca a nie innego. Zatem dochodzimy do momentu ze placimy slone pieniadze za pisanie komentarzy, a i tak uczen po suchym czytaniu komentarzy bedzie stosowal tylko wzorzec Copy-Paste.

Jedynym ekonomicznym rozwiazaniem jest stosowanie wlasnie XP. Jezeli osoba decyzyjna nad Toba nie pozwala na to, to czas zmienic prace :) bo oznacza to brak wyobrazni lub znajomosc mechanizmow tworzenia oprogramowania a to oznacza ze rowniez Ty nigdy nie zostaniesz doceniony przez tę osobe. :)

Najczesciej jest tak ze osoba decyzyjna stwierdza ze to jest marnotrastwo pieniedzy praca w parach. Jezeli tak to co taki uczen ma robic w miedzyczasie skoro nie ma doswiadczenia ? Robic copy paste tego co napisal wymiatacz ?

Stosowanie "DO NOT TOUCH" tez jest bez sensu. Taki kawalek kodu powinien byc pokryty testem jednostkowym. I teraz przy zastosowaniu continuous integration, jezeli uczen zmieni cos w kodzie od razu bedziemy mieli popsutego builda

Naprawde niestosowanie metodyk adaptacyjnych/zwinnych nie ma sensu w dzisiejszym swiecie.

Kod generowany - chodzi mi o generowanie jakiegokolwiek kodu C# np za pomoca obcych narzedzi takich jak np MyGeneration czy T4... Aczkolwiek kod generowany powinien byc w klasie partial wtedy wogole regionow nie bedzie (MyClass.cs i MyClass.generated.cs)
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Windows Forms a WPF




Wyślij zaproszenie do
Anuluj