Gadu gadu Skype

Archiwum dla tagu: ‘Reusability’

mar
27

Reusability? Tak, ale z głową

Spook, Marzec 27 2011

Napisz komentarz

Moim pierwszym pecetem był 486 DX/33 wyposażony w dysk twardy o pojemności 300 Mb oraz w 8 Mb RAMu. Choć wydaje się, że jest to bardzo mało, konfiguracja ta była w zupełności wystarczająca, by uruchomić na niej Windows 95. Ponieważ w czasie, który wspominam, funkcjonowała jeszcze zasada Moore’a, kolejny sprzęt, który postawiłem na biurku był już wyposażony w procesor Intel Celeron (800 Mhz) oraz 392 Mb RAMu, co umożliwiło zainstalowanie na nim bodaj najpopularniejszego do tej pory systemu, Windowsa XP.

Współczesne komponenty komputerów stacjonarnych – w porównaniu z czasami, o których wcześniej wspomniałem – są wyjątkowo tanie. Szukałem ostatnio cen RAMu; 4 Gb (czyli maksymalna ilość, którą można zaoferować 32-bitowemu systemowi) całkiem przyzwoitej firmy kosztuje w tej chwili około 160 PLN. Gwałtownego spadku cen doświadczyłem też kupując dyski twarde. Obecnie mam zainstalowane trzy: 80, 160 i 250 Gb. Wszystkie są tej samej firmy, wszystkie kupiłem praktycznie w takiej samej cenie (błąd około 10 PLN), tyle że pomiędzy poszczególnymi zakupami mijał mniej więcej rok czasu. W tej chwili za tą samą cenę można kupić dysk o pojemności 1 Tb.

Kiedyś jednak cena jednego bajtu – czy to zaszytego w kości pamięci, czy też na dysku twardym – była znacznie wyższa. Komputery PC były bardzo popularne, ale programista pisząc programy musiał brać pod uwagę, iż będą uruchamiane w środowiskach ubogich w zasoby; na porządku dziennym była walka o każdy, pojedynczy bajt używanej pamięci operacyjnej.

Wówczas właśnie zrodziła się idea reusability. Polegała ona z grubsza na osiąganiu oszczędności podczas korzystania z zasobów poprzez wielokrotne ich używanie. Sprowadzało się to na przykład do wielokrotnego używania jednej zmiennej do wielu różnych celów. Tym sposobem zadeklarowany na początku bloku int i najpierw służył jako iterator w pętli, następnie stawał się pośrednikiem dla danych wprowadzanych do programu przez użytkownika, by zakończyć życie jako zmienna przechowująca sumę elementów potrzebnych do obliczenia średniej jakiegoś zestawu danych. Uderzało to znacząco w czytelność kodu źródłowego, ale było też czasami jedyną metodą na zrealizowanie zamierzonego celu. Powiem więcej – metoda ta funkcjonuje z powodzeniem do dnia dzisiejszego w sytuacjach, gdy zasoby dostępne dla programisty są mocno ograniczone – na przykład podczas oprogramowywania różnego rodzaju prostych procesorów.

Współczesne trendy programowania bardzo mocno odbiegają od niegdysiejszych, jeśli weźmiemy pod uwagę ilość zużywanych zasobów. Dosyć powiedzieć, że programy na popularne w tym momencie systemy operacyjne dla urządzeń mobilnych (Android, Windows Phone 7) pisze się teraz w językach przeznaczonych dla maszyn wirtualnych, nie zaś w języku kompilowanym do rozkazów procesora. Kiedyś dla wszystkich systemów opartych na Windows CE można było pisać w C++, teraz programy dla Windows Phone 7 uruchamiane są na wirtualnej maszynie .NET postawionej na urządzeniu. Programy dla Androida, z kolei, pisze się w Javie. Żadną tajemnicą jest fakt, iż programy takie pracują nieco mniej wydajnie, niż gdyby ich rozkazy wykonywał sam procesor. Ale jakie ma to znaczenie w erze, w której na rynek niebawem ma zostać wprowadzony telefon z dwurdzeniowym procesorem i spadek wydajności programu jest prawie nieodczuwalny?

Ponieważ dawna reusability (w kontekście implementacji kodu źródłowego) straciła sens, współcześnie pojęcie reusability zostało uogólnione i jest interpretowane w zupełnie inny sposób. Programowanie stało się bardzo istotną gałęzią przemysłu, więc jak grzyby po deszczu zaczęły powstawać różne techniki pozwalające na zwiększenie wydajności pracy programistów i ograniczenie kosztów produkcji oprogramowania. Jedna z nich polega na skupieniu się na modularnej konstrukcji architektury programu. Każdy z modułów musi w jak najmniejszym stopniu zależeć od innych, jednocześnie realizując pewien zamknięty zestaw zlecanych mu zadań. Tym sposobem istnieje możliwość wyekstrahowania go z jednego projektu i włączenia w drugi, w którym istnieje potrzeba zrealizowania podobnej funkcjonalności. Ponowne użycie tego modułu (reuse) pozwala na znaczne ograniczenie czasu potrzebnego na realizację kolejnego projektu, a to właśnie czas jest teraz najdroższym elementem rozwoju oprogramowania.

Mimo iż pierwotna reusability (w kontekście oprogramowania dla komputerów PC) nie ma zwykle większego sensu i współcześnie jest uznawana za technikę, która poprzez obniżenie czytelności kodu źródłowego przyczynia się do zwiększenia zasobów potrzebnych do realizacji projektu, spotkałem się ostatnio z kilkoma przypadkami jej zaistnienia – których skutki były opłakane.

Mówię teraz o lokalizacji programów, czyli o dostosowaniu ich do różnych języków i kultur, a ściślej – o procesie tłumaczenia interface’u użytkownika. Proces ten odbywa się poprzez ekstrakcję wszystkich ciągów znaków, które pojawiają się w programie, a następnie przetłumaczeniu ich na inny język i włączeniu do zasobów programu. Tym sposobem raz napisany i skompilowany program może być uruchamiany w wielu różnych wersjach językowych – włącznie z przełączaniem ich w trakcie jego pracy. Przykładem takiego programu jest ProCalc 2 dostępny w dziale download: w zależności od wersji językowej systemu operacyjnego uruchomi się on z napisami po polsku, po włosku lub – w każdym innym wypadku – po angielsku.

Tłumaczenie interface’u niesie ze sobą również zagrożenia związane z tym, że gramatyki różnych języków są zbudowane w odmienny sposób. Polacy znają tylko trzy czasy, tymczasem ktoś naliczył się u Anglików i Amerykanów aż czterdziestu dziewięciu różnych wariacji na temat czasu przeszłego, teraźniejszego i przyszłego (a czasem nawet ich kombinacji). Z drugiej strony Polak jest w stanie odmienić rzeczownik przez siedem przypadków, podczas gdy Amerykanin korzysta tylko z dwóch – mianownika i – rzadziej – dopełniacza (poprzez dodanie ‚s). Innymi słowy, wyrażenie zapisane tak samo w jednym języku, a mające kilka znaczeń, w innym może wyglądać w każdym przypadku inaczej. Na przykład „Elements saved” oznacza: „Elementy zostały zapisane”. Ale jeśli wyrażenie to wystąpi po liczbie, na przykład: „10 elements saved”, należy je przetłumaczyć nieco inaczej: „10 elementów zostało zapisanych”.

Okazuje się, iż wielu projektantów oprogramowania nie bierze powyższego faktu pod uwagę i podczas ekstrakcji ciągów znaków stosują starą zasadę reusability. Jeśli więc w kilku miejscach w programie (ba, czasem nawet w kilku programach) występuje fraza „Elements saved”, do biblioteki tłumaczeń włączają oni to wyrażenie tylko raz i stosują je wielokrotnie. Tym sposobem tłumacz postawiony jest przed zadaniem niemożliwym do zrealizowania, bo – jak pokazałem wcześniej – nierealne jest przygotowanie tylko jednej wersji tłumaczenia, która będzie pasowała wszędzie.

Wydawałoby się, że opisany przeze mnie problem jest oczywisty i żaden rozsądnie myślący programista nie dopuści do jego powstania. Niestety, najwyraźniej tak nie jest. Otóż bowiem tak doświadczony w projektowaniu wielojęzycznych interface’ów użytkownika developer, jakim jest Microsoft popełnił w swoim programie takie oto tłumaczenie (mowa o wersji release oprogramowania):

Zachęcam do zgadnięcia, o jakim programie mowa, jakie tłumaczenie powinno wystąpić w tym miejscu i z czego wynika zabawna pomyłka tłumacza.

Nieprawidłowe tłumaczenie jest tylko jednym przypadkiem nieprawidłowego stosowania opisanej przeze mnie techniki. W pracy analizowałem kiedyś kod, który pisał dla nas zewnętrzny programista. Stosował on tam archaiczne reusability bez skrępowania i argumentował to zwiększeniem wydajności programu i zmniejszeniem zajmowanych przez niego zasobów. Przesłał nam też tytuł książki, na której bazował wszystkie „optymalizacje” wprowadzone do swojego kodu. Okazało się, iż książka ta traktuje o optymalizowanie kodu dla procesorów Pentium i 486 i została wydana w 1997 roku. Sporo mieliśmy pracy z poprawieniem jego algorytmów tak, by dało się z nimi później pracować.

Nie należy lekceważyć technik związanych z reusability. Pozwalają one na realne ograniczenie czasu pracy programistów. Nawet pierwotną reusability można stosować z powodzeniem w niektórych przypadkach. Jednak – jak to w życiu bywa – technika niewłaściwie zastosowana bardzo szybko obraca się przeciw jej użytkownikowi, utrudniając tym samym pracę nad projektem.

Reusability? Zdecydowanie tak. Ale z głową.