przez RyszardDzegan » Pn sty 25, 2010 11:49 am
Wyobraź sobie taki scenariusz: Przypadkiem lub też celowo odpaliłeś jakąś dużą aplikację. W tym momencie postanawiasz jednak z jakiegoś powodu ją natychmiast zamknąć i zająć się czymś innym. Ale co się dzieje? Na początku poraża Cię w oczy ekran powitalny tej aplikacji, który przy okazji zasłania połowę Twojego pulpitu i inne programy, z których chciałbyś może właśnie skorzystać. Chwilę potem zamula Ci się cały komputer. Próbujesz CTRL+ALT+DEL i próbujesz zabić natrętny proces. Komputer zamula się jeszcze bardziej, przetwarza się i liczy coś tam w tle, okna się wieszają, ikony się nie klikają, a Ty dochodzisz do wniosku, że szybciej będzie zrestartować cały system niż czekać aż ta przeklęta aplikacja wreszcie się zamknie.
Chciałbym żebyśmy poruszyli tutaj ten temat. Dlaczego duże aplikacje sprawiają tyle kłopotów? Dlaczego zamulają komputer? Dlaczego nie reagują na polecenia? Ten artykuł przeznaczony jest dla początkujących programistów, którzy chcą dowiedzieć się czegoś o pisaniu większych aplikacji.
Konstruktory.
W praktyce są wykorzystywane do inicjacji pól i zasobów klasy. Problem pojawia się, kiedy klasa jest duża. Wtedy inicjacja wszystkiego, czego potrzebuje zabiera jej trochę czasu. W praktyce często i tak nie używamy znacznej części funkcjonalności klasy. Po co więc ładować tonę zasobów, a potem tą tonę usuwać, skoro większość z tego w ogóle nie będzie użyta? C# posiada metody, a przede wszystkim właściwości. Postarajmy się inicjować zasoby dopiero wtedy, kiedy staną się potrzebne, a nie w momencie powstania instancji klasy. Niech konstruktory będą minimalne. Jeśli mimo tych zabiegów aplikacja nadal wolno się ładuje, spróbujmy wrzucić część inicjacji do oddzielnego wątku, a gdyby użytkownik przypadkiem zażądał dostępu do niezainicjowanej zmiennej poprośmy go aby chwilę poczekał. Na pewno zareaguje na to lepiej niż na zamulony system.
Wątki.
Jeśli jakaś metoda może potrwać zauważalnie długo z punktu widzenia użytkownika, należy użyć wątku i przypisać mu tryb pracy niskiego priorytetu i jeśli to możliwe również tryb pracy w tle. Wtedy nasz program będzie mógł wykonywać skomplikowane obliczenia w sposób niezauważalny, a w razie konieczności natychmiast zaprzestanie pracy.
Wydajny kod vs zrozumiały kod.
To, co najbardziej przyczynia się do powolności aplikacji, bardzo rzadko wynika z powolnych rozwiązań w kodzie. Tak naprawdę nie ma nic gorszego od napisania stu skomplikowanych linii kodu zamiast dziesięciu prostych, żeby przyspieszyć działanie aplikacji o ułamek sekundy. Problem polega na tym, że kiedy do naszego kodu zasiądzie inny programista aby coś zmienić (a przy dużych aplikacjach to jest prawdopodobne), wtedy będzie tracił czas na próby zrozumienia istoty rozwiązania, co oczywiście negatywnie wpłynie na czas pracy nad projektem. Na domiar złego pojawia się ryzyko, że coś zepsuje, ale nawet jeśli uda mu się niczego nie zepsuć, to bardzo możliwe, że powstawia do kodu jakieś obejścia i swoje rozwiązania, które skutecznie zniwelują Twoje starania o przyspieszenie aplikacji o ułamek sekundy. Ostatecznie powstanie wielki, powolny bajzel. Dlatego pisząc kod w zespole należy pamiętać przede wszystkim o kolegach po fachu, a nie o maszynie. Kod powinien być prosty, zrozumiały i opatrzony dokładnymi komentarzami.
Komentarze.
Mało kto daje komentarze do swojego kodu. Jeśli już jakieś są, to zwykle typu "x = null; // Przypisuję x wartość null" itp. To tylko zaśmieca kod i nikomu do niczego się nie przydaje. C# oferuje komentarze XML, które są równie proste w użyciu co zwykłe komentarze, a pomagają mechanizmowi InteliSense w Visual Studio. Pozostałe komentarze powinny informować nie o tym, co robimy w kodzie, bo to każdy widzi, tylko o tym po co to robimy. Np. "x = null; // Wartość x nie będzie już więcej wykorzystywana.
Zachęcam do wypowiadania się na temat i dodawania swoich uwag.
Ostatnio edytowano Pt sty 29, 2010 8:19 am przez
RyszardDzegan, łącznie edytowano 1 raz