Anti-patern predstavlja često korišćeno rešenje za neki problem, ali koje nije dobro i koje najčešće ima negativne posledice. I vrlo je verovatno da smo svi više puta videli i napravili neki anti-patern, a da toga nismo bili svesni.

Većina softver developera se u toku svoje karijere susrela sa nekim dizajn patternima, ili su bar čuli za taj termin. Paterni predstavljaju opšta, dobro poznata i dokumentovana, rešenja koja se koriste za rešavanje najčešćih problema u razvoju softvera.

Ali mnogi ne znaju da postoji i tamna strana, tj. anti-paterni. Anti-patern predstavlja često korišćeno rešenje za neki problem, ali koje nije dobro i koje najčešće ima negativne posledice. I vrlo je verovatno da smo svi više puta videli i napravili neki anti-patern, a da toga nismo bili svesni. Anti-paterni se mogu javiti u svim fazama razvoja softvera – odabiru metodologije, organizaciji, dizajniranju arhitekture, programiranju i ima ih verovatno i više nego dizajn paterna.

Neki od najčešćih anti-paterna su:

Bleeding Edge – Korišćenje najnovijih tehnologija i alata, koji su, iako obećavajući, najčešće nedovoljno dokumentovani ili još uvek u beta fazi i samim tim predstavljaju rizik da budu nepouzdani i da imaju negativan uticaj na kompletno rešenje. Ovakav pristup nije uvek anti-patern, već samo u slučajevima kada tehnologija ili alat ne postanu mainstream ili se napuste posle određenog vremena. Usled toga, neophodno je biti obazriv prilikom odabira neke najnovije tehnologije u razvoju, ali svakako ne treba zbog rizika izbegavati ovakav pristup, već samo dobro analizirati pre upotrebe.

Vendor Lock-In – Sistem koji je u prevelikoj meri zavisan od neke eksterne komponente. Ovakvim pristupom bilo kakva promena od strane vendora može da zahteva velike izmene i dorade kompletnog softvera. Moguće je i da eksterna komponenta/servis prestane sa pružanjem usluga i da to onemogući korišćenje vašeg rešenja. Najbolji način za izbegavanje ovog anti-paterna je korišćenje među-sloja između vašeg softvera i eksterne komponente i da se napravi integracija sa više različitih vendora i da se napravi fail-over scenario u slučaju kada neka eksterna komponenta prestane sa radom.

Reinventing the Square Wheel – Kreiranje alata i funkcionalnosti koji već postoje kao standardizovana rešenja, čiji krajnji rezultat bude lošiji nego što je standardno rešenje pružalo. Ovo se dešava u situacijama kada developer ne zna da postoji standardno rešenje, ili ne poznaje dovoljno problem koji želi da reši, tako da ne može da zna kako ga standardno rešenje prevazilazi. Ovo se može izbeći boljom analizom problema pre pokušavanja primene nekog rešenja. Ovaj anti-patern je često vrlo teško uočiti, a samim tim i otkloniti

Programming by Permutation – Ovo se često naziva i „programiranje pokušaja“. Ovaj anti-patern je verovatno najčešće korišćen od strane junior developera. On podrazumeva rešavanje problema pravljenjem malih korekcija (permutacija) na određenom kôdu, a zatim testiranje kako bi se ustanovilo da li se sada softver ponaša kao što je očekivano. Ovakvo programiranje je posledica nedovoljnog poznavanja problema i česta posledica su rupe i bugovi u drugom delu softvera, koji nastaju usled neobrađenih slučajeva.

Premature Optimization – Optimizovanje performansi sistema na osnovu slobodne procene, gde bi mogla da budu neka uska grla, a ne na osnovu testova i realnih primera nakon puštanja softvera u testni i produkcioni rad. Ovakvim pristupom se često ne dobijaju bolje performanse, a negativne posledice mogu da budu brojne, kao što su kompleksniji kôd i arhitektura, teže održavanje, a ne retko i lošije performanse nego što su bile pre optimizacije.

Golden Hammer – Pretpostavka da će rešenje koje je uspešno implementirano u nekom softveru, u kompletno drugom rešenju, biti takođe uspešno implementirano. Nisu svi softveri identični, pa samim tim i alati i rešenja koja se primenjuju ne mogu da budu identična, već ih je neophodno prilagođavati ili menjati u zavisnosti od problema koji se želi prevazići.

Lava Flow – Predstavlja čuvanje nepoželjnog, nepotrebnog i najčešće loše napisanog koda, a jedini razlog je to što bi, njegovo uklanjanje, možda imalo neplanirane troškove i posledice. Ovakav kôd se najčešće napiše u procesu razvoja, a zatim ne bude prepisan pre puštanja u produkciju. Otuda je i dobio ovaj naziv, jer se ovakav kôd nakon puštanja u produkciju ponaša kao okamenjena lava – čvrsto, nepromenljivo i beskorisno.

Spaghetti Code – Pežorativni naziv za nestruktuiran, loše napisan kôd, koji je vrlo težak za održavanje. Postoje mnogi uzroci koji izazivaju ovaj anti-patern, a najčešći su kratki rokovi za razvoj, nedovoljno iskustvo i nepostojanje pravila za kodiranje. Kako bi se izbegao ovaj problem, potrebno je pratiti najbolje prakse za pisanje kôda i u što je većoj meri smanjiti špagetirani kôd.

Interface Bloat – Ovaj anti-patern opisuje situaciju kada jedan interface ima preveliki broj metoda i klase koje ga implementiraju, ne mogu i ne znaju kako da izvrše sve potrebne operacije i onda neke od metoda ostanu neimplementirane. Ovaj anti-patern je u direktnoj suprotnosti od “I” stavke u SOLID pristupu programiranje, koji se smatra najboljom praksom u dizajniranju softvera.

God Object – Objekat za koji se može reći da zna ili je odgovoran za previše stvari. Najčešće ih odlikuje veliki broj atributa i još veći broj metoda i operacija. Uvezani su sa svim ostalim komponentama sistema i usled toga čak i male izmene na tom objektu mogu imati posledice po, naizgled, nepovezane komponente. Ovo se može izbeći podelom objekta u manje celine, odgovorne samo za određene, logički povezane operacije. U nekim situacija, God objekti mogu da budu i korisni, ukoliko se radi o, npr. mikrokontrolerima, gde je centralizacija kontrole važnija od održivosti i elegantnosti.

Golden Plating – Dodavanje funkcionalnosti ili generalno rad na nekom projektu nakon određene tačke, kada te dorade nisu vredne uloženog rada. Ovo se dešava kada se, nakon ispunjenja svih korisničkih zahteva, krene u dodavanje novih funkcionalnosti za koje mislimo da će se svideti korisniku.

Poltergeist – Poltergajst je tipičan naziv za stateless objekte, čija je jedina uloga da pozovu metodu u nekoj drugoj klasi. Najčešće se pojavljuju kada programer predvidi da će neka metoda imati dodatnu logiku u budućnosti, ali se to nikada ne desi.

Pattern Overuse – Najčešća greška koja se javlja kod programera koji se prvi put susretnu sa nekim paternom. Vođeni željom da pokažu kako su savladali određeni patern, pokušaće da ga “uglave” gde god je moguće. Ovo se dešava sa svim poznatijim paternima kao što su Singleton, Observer, Factory ili Strategy. Nije uvek pametno i poželjno ubacivati paterne. Nekada je dovoljno rukovoditi se KISS principom (Keep It Simple Stupid). Korišćenje paterna u prevelikoj meri može uticati na preteranu kompleksnost sistema i lošije performanse.

Veoma je bitno da se zna za postojanje anti-paterna i na koji način mogu da utiču na performanse i održavanje nekog sistema. Lista anti-paterna je velika i verovatno su mnoge arhitekte i developeri u svom radu napravili više grešaka koje spadaju u tu listu. Ne postoji savršen softver i sigurno će se nekad neka greška pojaviti kao rezultat loše procene, kratkih rokova itd. Samo dobrim poznavanjem najboljih praksi i konstantnim usavršavanjem se nivo ovakvih grešaka može smanjiti i smanjiti njihov uticaj na rad rešenja.