Normy programowania - sposób na programistę indywidualistę?

Znajomy inspektor nadzoru budowlanego twierdzi, że budowlani mają we krwi zwyczaj pomijania lub ''upraszczania'' czynności, których wykonania nie można sprawdzić, bo ich efekty kryją stropy i mury. Niektórzy mają podobne mniemanie o programistach.

Znajomy inspektor nadzoru budowlanego twierdzi, że budowlani mają we krwi zwyczaj pomijania lub 'upraszczania' czynności, których wykonania nie można sprawdzić, bo ich efekty kryją stropy i mury. Niektórzy mają podobne mniemanie o programistach.

Nie ma chyba na świecie ośrodka obliczeniowego czy firmy informatycznej, gdzie nie opowiadano by legend o wybitnych jednostkach osiągających nieprzeciętne wyniki w pracy. Jednostkach twórczych, nie ustających w poszukiwaniach i dyskretnie, ale uważnie śledzących dokonania innych. Osobnicy tacy są zazwyczaj dość ekscentryczni, nie zawsze łatwi w kontaktach, a kierownictwo z reguły z pobłażaniem traktuje ich nietypowy styl pracy i takiż stosunek do jej dyscypliny i reguł.

Problem z tego rodzaju pracownikami zaczyna się wtedy, gdy są oni programistami, po których oczekuje się systematycznego, uporządkowanego działania, które jest podporządkowane ścisłym i jednoznacznym regułom.

Dodatkiem do tego problemu, na ogół jeszcze trudniejszym, są zastępy naśladowców takich wybitnych jednostek. Naśladowcy ci to pewnego rodzaju uzurpatorzy - próbują naśladować postępowanie tych wyjątkowych, koncentrując się głównie na stylu i stosunku do pracy, za czym na ogół nie idą porównywalne z wzorcami umiejętności i osiągnięcia.

Programista programiście

Większość dużych ośrodków, w których powstaje oprogramowanie komputerów, stosuje różnego rodzaju zasady bądź normy postępowania obowiązujące przy jego tworzeniu. Zasady te, istotnie ograniczając swobodę programistów, mają doprowadzić do tego, aby pisane przez nich programy były czytelne i łatwo poddawały się modyfikacjom.

Kiedyś wymogi tego rodzaju ograniczały się do stosowania w kodzie programu obszernych komentarzy, wyjaśniających istotę podejmowanych w nim działań i związanych z nimi algorytmów. Już to spotykało się z oporem programistów, którzy albo unikali stosowania komentarzy, albo dorabiali je ex post, już po uruchomieniu programu i bez większej dbałości o ich treść. Braki pod tym względem były, choć niechętnie, ale jednak akceptowane, gdyż program bez komentarzy też działał, a dotrzymanie stale zagrożonych terminów było ważniejsze niż opatrzenie kodu komentarzami. Po jednym zadaniu przychodziły następne, równie pilne, a na uzupełnianie komentarzy na ogół nie wystarczało czasu.

Efekty tego występowały dopiero przy którejś modyfikacji kodu programu, którą wykonywał już ktoś inny. Konkretny moduł często łatwiej było napisać od nowa, niż zrozumieć, o co chodziło autorowi oryginału. W rezultacie powstawały programy, w których te same funkcje były zaprogramowane np. kilka razy, powodując powstawanie tzw. martwego, nigdy nie wykonywanego kodu. Obecność tego kodu zwiększała wielkość programu, jego zapotrzebowanie na pamięć operacyjną i czyniła go mniej odpornym na błędy.

Równy szpaler

Podejmowane od czasu do czasu próby dyscyplinowania programistów sprowadzały się do wprowadzania różnorakich zasad, reguł i norm. Zakres wprowadzanych przez nie regulacji rozpoczynał się od nazewnictwa programów i ich modułów, po nazwy zmiennych, etykiet i typowe algorytmy. Regulacje bywały na ogół dobrze opracowane, uniwersalne i wyczerpujące. Główny problem polegał na braku kontroli ich stosowania. Przymykanie oczu na niedociągnięcia (a czasem bojkot reguł) ze strony wspomnianych tu na początku osób uważanych za liderów, powodowało osłabienie całości systemu. Przeprowadzanie zaś ścisłej, pracochłonnej kontroli najczęściej nie było możliwe. Zmianę pod tym względem mogły przynieść automatyczne narzędzia programowe, jednak na ich pojawienie się trzeba było czekać niemal do czasów współczesnych.

Próby, o których mowa, podejmowano również w celu zwiększenia wydajności pracy programistów (zarówno w trakcie tworzenia programów, jak i ich późniejszej modyfikacji), ograniczenia liczby błędów, przyspieszenia procesu testowania i oddzielenia kodu programu od osoby, która go stworzyła.

Pierwszym problemem napotykanym w trakcie tworzenia takich zasad jest ich uzależnienie od języka programowania, którego dotyczą. Reguły uniwersalne są zbyt ogólne, by cokolwiek w stosowanych praktykach zmienić, zasady szczegółowe odnoszą się zazwyczaj tylko do jednego, konkretnego języka programowania i trzeba tworzyć niemal od nowa kolejną ich odmianę, gdy zachodzi potrzeba stosowania jeszcze jednego takiego języka.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200