Tag: software engineering

Entries for tag "software engineering", ordered from most recent. Entry count: 31.

Uwaga! Informacje na tej stronie mają ponad 3 lata. Nadal je udostępniam, ale prawdopodobnie nie odzwierciedlają one mojej aktualnej wiedzy ani przekonań.

Pages: > 1 2 3 4

22:55
Tue
01
May 2007

Singletony precz!

W ramach porządków w kodzie pozbyłem się dzisiaj wszystkich singletonów zamieniając je na zwykłe, globalne zmienne wskaźnikowe. Tak, wiem co sobie teraz pomyślą wszyscy obrońcy programowania obiektowego... Ja nie mam nic do OOP ani nawet do wzorców projektowych, ale jednak krócej niż res::ResManager::GetInstance().Cośtam jest napisać res::g_ResManager->Cośtam. Poza tym to działa szybciej, bo mówcie co chcecie, ale sprawdzać czy obiekt już istnieje tysiące razy na klatkę to nie jest zerowy narzut czasu.

Przede wszystkim jednak mam teraz kontrolę nad tym, kiedy obiekt powstaje i kiedy jest niszczony, bo... robię to sam. Mogę więc powiedzieć dokładnie, czy w pewnej chwili to czy tamto jest utworzone, w jakiej kolejności jest alokowane i zwalniane oraz zagwarantować, że w danym momencie dany obiekt na pewno istnieje. Słowem - mam w pełni formalnie zdefiniowany czas życia obiektów. To rozwiązało problem, który miałem podczas finalizacji różnych modułów, a z którym nie sposób było inaczej sobie poradzić. Co za ulga! A już zaczynałem wierzyć, że singletony są OK...

Comments (0) | Tags: c++ philosophy software engineering | Author: Adam Sawicki | Share

14:12
Fri
13
Apr 2007

Dobra dokumentacja na wagę złota

Dokumentacja... Najbardziej znienawidzona część każdego programu. Prawie nikt nie lubi jej pisać, ale wszyscy wiedzą, że jest niezbędna. Dokumentacja jest tym, co najlepiej odróżnia prawdziwy, dopracowany program od eksperymentu/prototypu.

Dla odbiorcy danego programu (czy - przede wszystkim - biblioteki) dobra dokumentacja to nieoceniona pomoc. Zaawansowani tym się właśnie różnią od początkujących, że nie boją się do niej zaglądać, bo wiedzą, że znajdą tam systematyczny i szczegółowy opis każdej funkcji, jej działania i parametrów. Tylko czy na pewno kompletny?

MSDN zawsze pozostaje dla mnie pod tym względem wzorem. Ale już dokumentacji w DirectX SDK można co nieco zarzucić, szczególnie jej części poświęconej D3DX. Oprócz braku rozdziałów opisujących ogólnie sposób używania poszczególnych interfejsów doskwierają liczne drobiazgi. Na przykład:

D3DXMACRO Macros[MACRO_COUNT+1];
for (int i = 0; i < MACRO_COUNT; i++) {
  Macros[i].Name = // ...
  Macros[i].Definition = // ...
}
Macros[MACRO_COUNT].Name = NULL;
Macros[MACRO_COUNT].Definition = NULL;

Comments (0) | Tags: directx philosophy software engineering | Author: Adam Sawicki | Share

09:54
Fri
30
Mar 2007

Architektura serwera MMO

Czytając sobie różne materiały dochodzę do wniosku, że architekturę rozproszonego serwera gry MMO można podzielić na dwa rodzaje:

  1. Podział na węzły ze względu na pełnioną funkcję - na przykład osobny serwer nazw, osobny AI, osobny walki, osobny przedmiotów itd.
  2. Podział na węzły ze względu na symulowany obszar świata gry

W swoich na razie tylko teoretycznych rozważaniach skłaniałbym się obecnie ku opcji drugiej, bo wydaje mi się znacznie prostsza w implementacji i bardziej skalowalna.

Comments (0) | Tags: software engineering networking | Author: Adam Sawicki | Share

21:18
Tue
27
Mar 2007

Dobry pomysł firmy Psiloc

Kod powinien być jak najbardziej ogólny i uniwersalny, przenośny i pozbawiony zależności. Tak uczy inżynieria oprogramowania. Wtedy nadaje się do ponownego użycia skracając czas pisania nowych produktów i stanowiąc nową cegiełkę do zasobów wiedzy programisty albo firmy. Tyle teoria. W praktyce, jak wiadomo, bywa różnie. Żadna klasa (oprócz tych najprostszych) nie możne się obejść bez odwołania do "warstw niższych" danej aplikacji, często łatwiej jest coś napisać od nowa niż przerabiać wcześniejszy kod, a pisanie wszystkiego jak najbardziej ogólnie i uniwersalnie to prosta droga do tego, żeby nigdy niczego nie skończyć.

W związku z tym ludzie radzą sobie w różny sposób. Na przykład pisząc większe moduły, które stosują w wielu swoich projektach. Ja już jakiś czas temu zorientowałem się, że często zamiast gotowej do wykorzystania klasy warto zachować kawałek kodu, który w razie potrzeby skopiuję do nowego programu dostosowując w nim co trzeba. Kody takie wraz z wszelką inną wiedzą trzymam w pliczkach tekstowych, których mam już ponad 700.

To, o czym chciałem tutaj napisać, to nowy pomysł, który usłyszałem na tegorocznej konferencji, na prezentacji firmy Psiloc. Można sobie mianowicie napisać oprogramowanie, które będzie automatycznie (nawet jakoś bardzo prosto) katalogowało nasz kod poszukując *specjalnych komentarzy*, a my będziemy zaznaczali tymi komentarzami szczególnie ciekawe fragmenty w swoim kodzie, jak na przykład wywołania potrzebne do sprawdzania numeru MAC karty sieciowej czy jakiś sprytny algorytm. Potem można będzie łatwo taki fragment odnaleźć. Zastanawiam się, czy to nie jest całkiem dobry pomysł...

Comments (0) | Tags: software engineering | Author: Adam Sawicki | Share

18:44
Sat
24
Feb 2007

Enkapsulacja

Enkapsulacja - piękna idea... Używamy klasy poprzez jej interfejs nie myśląc o tym, jak wygląda jej wewnętrzna implementacja. Ale to nie tylko jedno z założeń programowania obiektowego, to także naczelna zasada całego programowania (zawsze piszemy kolejne warstwy kodu korzystając z warstw niższych, z jakiś bibliotek czy funkcji systemowych). Zastosowanie ma nawet w życiu codziennym - sterujemy radiem za pomocą przycisków nie wiedząc nawet, jak to radio jest zbudowane ani jak działa.

Niestety nie wszędzie enkapsulacja ma zastosowanie. Nie sposób używać jej w matematyce. Wyprowadzenia czy dowody można pomijać, ale nie sposób zastosować wzoru bez zrozumienia co on reprezentuje, jak jest zbudowany, jak działa ani skąd się wziął. Czemu równanie matematyczne nie może być niczym biblioteka C++ - funkcją, której podajemy dane na wejście i otrzymujemy dane na wyjściu? Dlaczego skopiowany skąś wzór czy algorytm, choć poprawny, nigdy nie zadziała dopóki go w pełni nie zrozumiemy i nie poprawimy w nim jakiegoś drobiazgu? Czy życie programisty nie byłoby wtedy prostsze? :)

Comments (0) | Tags: philosophy software engineering math | Author: Adam Sawicki | Share

13:06
Sat
13
Jan 2007

Rozważania nad instalatorami

Ilekroć instaluję jakiś program, zastanawiam się jak te instalatory są pisane, kto je pisze i jak one działają, że proces instalacji trwa tak długo, jest tak złożony i wymaga tylu różnych rzeczy tudzież pokazywania 10 razy paska postępu podążającego spokojnie ku wartości 100%, by znowu się wyzerować? Cóż takiego trudnego jest w wypakowaniu kilku, nawet kilkudziesięciu czy kilkuset plików, w zapisaniu jakiś danych do rejestru systemowego, utworzeniu skrótów w menu Start i ewentualnie sprawdzeniu, czy coś w systemie już istnieje i w jakiej jest wersji, że trwa to wielokrotnie dłużej niż gdyby użytkownik skopiował sobie te pliki ręcznie? Rozumiem gry, które muszą skopiować na dysk całe gigabajty danych z płyty CD, ale ileż czasu może instalować się kilkumegabajtowy program?

Jeszcze bardziej śmieszy mnie deinstalacja niektórych programów. Przecież usunięcie pliku to jest umłamek sekundy, a deinstalatory nierzadko potrzebują sporo czasu by pogmerać po dysku robiąc niewiadomo co, zanim w końcu łaskawie usuną swoje pliki, i tak pozostawiając na dysku i w rejestrze pełno śmieci.

Czy tak musi być? Czy też może programiści po prostu nie przywiązują wagi do instalacji i korzystają z gotowych kreatorów instalatorów, które ktoś kiedyś napisał niespecjalnie przejmując się szybkością, bo przyjęło się że instalacja musi wyglądać (i trwać) tak a nie inaczej? Pod tym względem godne uznania są gry firmy Blizzard, które choć na dysku zamują całe gigabajty, ich deinstalacja trwa około sekundy.

Comments (0) | Tags: philosophy software software engineering | Author: Adam Sawicki | Share

13:49
Sun
19
Feb 2006

Wzorce projektowe

Skończyłem wczoraj czytanie książki Wzorce projektowe i powiem szczerze, że mam mieszane uczucia. Z jednej strony Banda Czworga dokonała rewolucyjnego odkrycia, skatalogowała pewne koncepcje na zupełnie nowym poziomie abstrakcji. Z drugiej strony to nic nadzwyczajnego - ot pewne układy klas i obiektów, których i tak każdy z nas używa. Z jednej strony pokazują, jak najlepiej wykorzystać hermetyzację, polimorfizm i wszelkie zalety obiektowości, z drugiej nakłaniają żeby wszędzie gdzie tylko się da wszystko rozbijać na drobne klasy, stosować dziedziczenie i metody wirtualne. Z jednej strony dzięki nim można pisać kod lepiej zorganizowany, łatwiejszy w modyfikacji i ponownym użyciu, ale z drugiej pisanie wszystkiego jak najbardziej ogólnie i uniwersalnie to jeden z najlepszych sposób żeby nigdy nie skończyć swojego programu :)

Tak czy owak, na pewnym etapie programowania warto poznać tą dziedzinę. Ale uwaga - książkę czyta się dość ciężko i jej zrozumienie wymaga już znajomości nie tylko języka programowania, ale i programowania obiektowego (w sensie nie tylko składniowym, ale i "ideologicznym").

BTW: Mam do sprzedania trzy książki. Może ktoś się skusi? :)

Comments (0) | Tags: software engineering | Author: Adam Sawicki | Share

Pages: > 1 2 3 4

STAT NO AD [Stat] [Admin] [STAT NO AD] [pub] [Mirror] Copyright © 2004-2016 Adam Sawicki
Copyright © 2004-2016 Adam Sawicki