eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingDlaczego w branży rozrywkowej najsłabiej płacą?Re: Dlaczego w branży rozrywkowej najsłabiej płacą?
  • Data: 2011-10-12 22:51:28
    Temat: Re: Dlaczego w branży rozrywkowej najsłabiej płacą?
    Od: Wojciech Jaczewski <w...@o...pl> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    Andrzej Jarzabek wrote:

    >>> Tylko że jedną z praktyk pisania niezawodnego oprogramowania jest żeby
    >>> w większych projektach opakować systemowe API w coś bardziej
    >>> abstrakcyjnego, czy to bibliotekę in-house czy third-party.
    >>
    >> Z tym się zdecydowanie nie zgodzę. To jest praktyka pisania
    >> oprogramowania przenośnego między platformami. Do pisania niezawodnego
    >> nie jest to wymagane.
    >
    > Do pisania oprogramowania niezawodnego potrzebna jest abstrakcja i
    > czytelność kodu. Kod, który sobie po cichu zakłada, że int ma 32 bity ma
    > niedobory w jednym i drugim.

    Mowa o funkcjach systemowych, a nie zakładaniu ile bitów ma int. Trudno mi
    sobie wyobrazić, aby ktoś korzystał z tego założenia, mając do dyspozycji
    alternatywę w postaci int32_t.

    >> Co jeśli poziom abstrakcji API systemowego jest właśnie idealnie
    >> dopasowany do zadania? Opakowywać go w coś, co ma te same możliwości, ale
    >> NIESTANDARDOWY interfejs?
    >
    > Jeśli mówisz o programie, którego najlepszym opisem jest "wywołuje
    > taką-a-taką funkcję systemową" to może i jest to najlepszy poziom
    > abstrakcji. Jeśli jednak mówimy o dużych projektach pisanych przez
    > zespoły, to raczej norma jest taka, że operują na wyższym poziomie
    > abstrakcji.

    Bardzo jest dla mnie zagadkowe, że tak wiele osób uważa, iż interfejs
    opracowywany i testowany przez kilka dziesięcioleci koniecznie wymaga
    opakowania w jakąś abstrakcję, bo inaczej korzystać z niego nie należy...
    Nie wiem jak jest z interfejsami windowsowymi, bo z nimi doświadczenie
    miałem znikome, ale interfejsy POSIX-owe są bardzo dobre. Abstrakcja w
    postaci deskryptora pliku - coś wspaniałego.
    Również dla krytykowanych przez niektórych uniksowych sygnałów daje się
    czasem znaleźć fajne zastosowanie, gdzie bez sygnałów program byłby dużo
    bardziej zawiły.

    Oczywiście w każdym API dałoby się wskazać jakieś wady, ale na jakiej
    podstawie miałbym przypuszczać, że zrobiona w dużo krótszym czasie
    abstrakcja będzie istotnie lepsza?

    Dla ścisłości: nie mam nic przeciwko takim abstrakcjom, jak np. baza danych
    - tam rzeczywiście nie używa się systemowego API do komunikacji
    międzyprocesowej, tylko API udostępnionego przez twórcę bazy danych. Ale ja
    tego nie nazwałbym "opakowywaniem systemowego API", tylko zrobieniem modułu
    wykorzystującego systemowe API.
    Dla mnie "opakowywanie systemowego API" to takie wynalazki jak np. QSocket z
    Qt. Dla programów międzyplatformowych - może ma sens. Dla programów na jedną
    platformę - żadnego. Interfejs udostępniany przez system (POSIX) jest
    lepszy. Testowałem też kiedyś Boost::Asio - nieczytelny w porównaniu z tym,
    co można zrobić korzystająć bezpośrednio z POSIX. I ciężki do integracji,
    jeśli program ma reagować jednocześnie na zdarzenia innego typu.

    >> Ja wiem, że mamy trochę inne spojrzenie, ze względu na inne
    >> doświadczenia. Przechodziłem kiedyś przez taki etap rozwoju, że
    >> próbowałem opakowywać API systemowe. Z czasam osiągałem taki efekt, że
    >> moja "abstrakcja" powielała dokładnie to, co dawało API systemowe. Po
    >> prostu większość szczegółów API systemowego była mi rzeczywiście
    >> potrzebna.
    >
    > Pracowałem przy kilku większych projektach i normą było korzystanie z
    > biblioteki opakowującej API, chociaż nie takiej, która jest tworzona pod
    > konkretny projekt: albo były to biblioteki third party, albo robione w
    > firmie na potrzeby wielu projektów. To, czy korzystają czy nie
    > korzystają ze wszystkich funkcji API nie ma znaczenia - istotne jest, że
    > reprezentują wyższy poziom abstrakcji.

    Czy wyższy poziom abstrakcji w sensie np. baza danych zamiast bezpośredniego
    czytania z plików i synchronizowania przy pomocy fcntl/flock? czy tylko
    pozbierane kilka funkcji systemowych do kupy i pozamykane w obiekty?

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: