Tydzień z grub­sza zajęło mi dopro­wa­dze­nie do uży­wal­no­ści kodu, który otrzy­ma­łem w spadku po pew­nym urlo­po­wi­czu. Dobrze, że nie mam wło­sów, bo z pew­no­ścią bym je dawno wyrwał, choć z — dru­giej strony — na pro­gra­mo­wa­niu cierpi moja broda. Kolega wypo­czywa w Ira­nie, a my pró­bu­jemy dojść, co też pod­miot liryczny miał na myśli. Kiedy czy­ta­nie źródeł dłuży się ponad lek­turę Nad Nie­mnem, znak to, że czas na notkę.

Jak nie należy programować

Na wstę­pie już zazna­czę, że w ITS Ltd. zaj­mu­jemy się budo­wa­niem apli­ka­cji webo­wych w opar­ciu o Pythona i Django, więc nie­któ­rym poniż­szy tekst może wydać się płytki/nudny/pozbawiony sensu (nie­po­trzebne skreślić).

Porad­nik niniej­szy zale­cany jest dla pro­gra­mi­stów, któ­rzy w różny spo­sób zwią­zani są z ser­wi­sem The Daily WTF — czy to przez umi­ło­wa­nie do czy­ta­nia publi­ko­wa­nych tam histo­rii, czy to przez bycie boha­te­rem tych ostat­nich. Redak­cja zastrzega sobie prawo do skró­tów myślo­wych i prze­lot­nego braku poczu­cia humoru.

Redundancja

Naj­waż­niej­szą cechą sys­te­mów klasy Enter­prise (jeden do tele­por­ta­cji) jest ich wysoka dostęp­ność (i cena). Jest to fakt tak nie­za­prze­czalny, jak nie­za­prze­czalna jest wysoka jakość pro­duk­tów z rodziny Gadu-Gadu. Auto­rzy apli­ka­cji klasy E (uni­wer­salny, auto­mat i do tka­nin czar­nych) czę­sto uwa­żają, że ich pro­dukty z powo­dze­niem sta­wać mogą w kon­kury z apa­ra­turą czasu rze­czy­wi­stego. Cóż, każdy może się mylić, ale jakież tajemne recep­tury zapew­niają taką pew­ność sie­bie? Dziś Via­grę nabyć można na każ­dym baza­rze, skupmy się więc na tech­ni­kach programowania.

Autor apli­ka­cji staje wie­lo­krot­nie przed trud­nymi pyta­niami egzy­sten­cjal­nymi. Gdzie jest spe­cy­fi­ka­cja tech­niczna? Jak ja wczo­raj wró­ci­łem do domu? Skąd weź­miemy tyle gala­retki, żeby napeł­nić basen? To tylko nie­które z nich. Naj­waż­niej­sze pyta­nie, jakie zadają sobie auto­rzy apli­ka­cji klasy E (E303, E301, może zawie­rać śladowe ilo­ści orze­chów), to jak unik­nąć uży­wa­nia biblio­tek, któ­rych sami nie napi­sa­li­śmy, wszak któ­re­goś ranka gotowe prze­stać dzia­łać. Na szczę­ście tutaj z pomocą przy­cho­dzi dogmat Copiego-Paste’a. Wystar­czy zatem sko­pio­wać klu­czowe ele­menty fra­me­worku do uży­wa­ją­cej go apli­ka­cji i już możemy spać spo­koj­nie — co dwie kopie to nie jedna, praw­do­po­do­bień­stwo mówi, że obie nie popsują się jednocześnie.

Optymalizacja czasu pracy

Jeśli brać z kogoś przy­kłady (a klasa E czyni to nie­chęt­nie, sami wszakże sta­no­wią elitę), to tylko z ame­ry­kań­skiej mary­narki. Tra­dy­cyjne poję­cia deadline’ów i zarzą­dza­nia zaso­bami zastą­pić można spraw­dzo­nym na wielu woj­nach ŻULU time. W fir­mie naj­waż­niejsi są ludzie, więc zawsze jest czas się napić! Pozwala to płyn­nie regu­lo­wać stres powo­do­wany przez pracę, a naukowcy dowo­dzą, że może w zupeł­no­ści wyeli­mi­no­wać ryzyko wystą­pie­nia ner­wicy (sto­su­jący tę meto­dykę rzadko doży­wają czterdziestki).

Ważne jest rów­nież, by pro­gra­mi­sta miał podej­ście ana­li­tycz­nie i potra­fił myśleć out­side the box, co w języku pol­skim ozna­cza dosłow­nie myśl, jak cią­gle być poza kubi­kiem. W prak­tyce spraw­dza się naj­le­piej obra­nie nie­kon­wen­cjo­nal­nych godzin pracy (na przy­kład godzin noc­nych) i pla­no­wa­nie prze­strzenne (koduję od tego kie­liszka do pod­łogi).

Generalizacja

Gene­ra­li­za­cja to dar patrze­nia na rze­czy z dystansu. Dla przy­kładu pies i samo­chód z dystansu wyglą­dają podob­nie. Dla­czego więc nie umie­ścić ich w bazie danych we wspól­nej tabeli rzecz, odpo­wied­nio pomi­ja­jąc kolumnę rasa w przy­padku samo­chodu i poda­jąc zero w kolum­nie liczba_drzwi w przy­padku psa? Tak zbu­do­wana baza danych jest dużo prost­sza do pro­gra­mo­wa­nia, zwłasz­cza jeśli w uży­ciu jest szkie­let ORM.

Dodat­kowe punkty komi­sja przy­zna za uprosz­cze­nie tabeli do jed­nego pola, w któ­rym umie­ścić można zse­ria­li­zo­wany obiekt dowol­nego typu.

Obfuskacja

Duży pro­jekt klasy E czę­sto jest oczkiem w gło­wie kor­po­ra­cji. Nie można zatem dopu­ścić, by sekrety jego dzia­ła­nia poznał nie­po­wo­łany śmier­tel­nik. Lata doświad­cze­nia w dzie­dzi­nie refak­to­ry­za­cji uczą, że naj­pew­niej­szym środ­kiem zapo­bie­gaw­czym jest obszerne sto­so­wa­nie obfu­ska­cji. Sto­so­wa­nie jed­no­li­te­ro­wych nazw zmien­nych i funk­cji nie tylko unie­moż­li­wia zro­zu­mie­nie geniu­szu kry­ją­cego się za kodem, ale także znacz­nie zmniej­sza miej­sce, jakie kod zaj­muje na dysku. Jest to zaleta nie do pomi­nię­cia w przy­padku pro­jek­tów, które korzy­stają dodat­kowo z tech­nik pro­gra­mo­wa­nia życze­nio­wego (ale o tym za chwilę).

Nie­zwy­kle ważne jest też kon­se­kwentne nie­umiesz­cza­nie komen­ta­rzy w kodzie. Łatwo poli­czyć, że prze­ciętna metoda o dłu­go­ści dzie­się­ciu ekra­nów, sta­łaby się nie­zno­śnie długa, gdyby co drugi wiersz wsta­wić komen­tarz i prze­pro­siny dla naszego zastępcy.

Zaawansowane techniki zabezpieczania kodu

Kolejną tech­niką obfu­ska­cji jest, pocho­dzący z lite­ra­tury, syn­kre­tyzm języ­kowy. Dla zmy­le­nia poten­cjal­nego prze­ciw­nika i lep­szego utrwa­le­nia w pamięci dawno nie­uży­wa­nych tech­nik, sta­ramy się co jakiś czas wtrą­cić ekran kodu napi­sa­nego na przy­kład w PHP. W tym celu ogra­ni­czamy się do czę­ści wspól­nej składni obu języ­ków, dodat­kowo emu­lu­jąc zacho­wa­nie zupeł­nie innego frameworku.

Mało znaną, ale opa­no­waną do per­fek­cji przez elitę, metodą wpro­wa­dza­nia zakłó­ceń w kodzie jest tak zwane prawo wol­nego rynku (import bez ogra­ni­czeń). Główne zasto­so­wa­nie tej metody to napra­wia­nie wadli­wych języ­ków, któ­rych auto­rzy zło­śli­wie wpro­wa­dzili prze­strze­nie nazw. Wystar­czy jed­nak kilka instruk­cji from foo import * sta­ran­nie poroz­rzu­ca­nych po kodzie (nie zapo­mnijmy czę­ści z nich umie­ścić w instruk­cjach warun­ko­wych) i jeste­śmy z powro­tem w sta­rym, dobrym bashu. Przy­jemny sku­tek uboczny to fakt, że nikt nigdy nie będzie w sta­nie odtwo­rzyć zależ­no­ści apli­ka­cji poza naszym środo­wi­skiem rozwojowym.

Programowanie życzeniowe i stubenci

Jedną z pod­sta­wo­wych prawd na temat pro­gra­mo­wa­nia jest taka, że każdą apli­ka­cję trzeba utrzy­my­wać, a rzadko która nie ewo­lu­uje wraz z upły­wa­ją­cym cza­sem. Prag­ma­tyczny pro­gra­mi­sta dba o to już od pierw­szej linii kodu. Zanim jesz­cze zaj­mie się imple­men­ta­cją wyma­ga­nej funk­cjo­nal­no­ści, stara się prze­wi­dzieć moż­liwe przy­szłe drogi roz­woju. Jeśli pro­gra­mi­sta zna się na fachu, owo­cuje to umiesz­cze­niem w kodzie roz­licz­nych z pozoru nie­po­trzeb­nych metod. Są one z natury zepsute bądź puste i nazy­wamy je stu­bami, sam zaś autor nosi fachowe miano stu­benta.

Stu­benci zapew­niają apli­ka­cji bez­pieczny mar­gi­nes nad­mia­ro­wo­ści, podob­nej w natu­rze do redun­dan­cji, co z kolei zmniej­sza ryzyko, że przy­szły opie­kun pro­jektu w wyniku zmie­sza­nia nie­chcący usu­nie coś nie­zbęd­nego. Jedną z rza­dziej spo­ty­ka­nych metryk jako­ści kodu klasy E jest wła­śnie pro­cen­towy udział kodu, który można usu­nąć bez wpływu na dzia­ła­nie apli­ka­cji. Naj­lepsi w branży utrzy­mują się w prze­dziale od czter­dzie­stu do sześć­dzie­się­ciu procent.

Testy jednostkowe i UMŁ

Jak sama nazwa wska­zuje, są to testy, które prze­pro­wa­dza się tylko raz. Dla pew­no­ści, że zbędne dane nie wpłyną na wynik ani czas trwa­nia testu, naj­le­piej prze­pro­wa­dzić go w środo­wi­sku roz­wo­jo­wym, przy pustej bazie danych. Już samo słowo wdro­że­nie suge­ruje, że klient musi liczyć się z dodat­ko­wymi kosz­tami w celu póź­niej­szego dopro­wa­dze­nia pro­duktu do dzia­ła­nia w środo­wi­sku pro­duk­cyj­nym. Testy jed­nost­kowe, z natury, mogą być cięż­kie do powtó­rze­nia nawet w warun­kach labo­ra­to­ryj­nych, stąd nie należy mieć opo­rów przed sko­rzy­sta­niem z wygod­nego narzę­dzia, jakim jest UMŁ (u mnie łaziło).

Cóż, na dziś to wszystko, do zoba­cze­nia w kolej­nym odcinku porad­nika Jak nie należy pro­gra­mo­wać, gdzie wspól­nie wzbo­ga­cimy wachlarz sto­so­wa­nych prak­tyk. Czy­tał Lucjan Szołajski.