Dobre praktyki kodowania – mniej znaczy więcej?
Tak jak w projektowaniu w stylu minimalistycznym, tak i w kodowaniu, każdy programista powinien kierować się zasadą “mniej znaczy więcej”. Pracując nad własnym oprogramowaniem, lub modyfikując istniejący kod, często spotykamy się z jego nadmiarem.
Może to wynikać z dobrych zamiarów web-developera, który chcąc uczynić swój kod bardziej przejrzystym, rozbudowuje kod o kolejne funkcje i usprawnienia. Czasami wynika to z niewiedzy i braku doświadczenia – prowadzi to do mało optymalnego kodu, lub niepotrzebnego kopiowania kawałków kodu w wielu miejscach. Tworzy to istną sieć połączeń, zależności, gdzie usunięcie jednego znacznika może rozsypać całą stronę www.
Im więcej kodu zawiera projekt, tym bardziej z założenia jest on skomplikowany, a każda jego późniejsza rozbudowa jest bardziej czasochłonna. Wpływa to również na wymagania sprzętowe i liczbę potencjalnych błędów w oprogramowaniu. O ile duża ilość kodu wynikająca z wymaganej funkcjonalności oprogramowania i jego specyfikacji jest zrozumiała, o tyle kod, który został napisany ponad określone potrzeby jest już zbędny i po prostu wręcz szkodliwy dla lekkości i funkcjonalności całego projektu.
Kolejnym grzechem programistów jest powielanie kodu. Oczywiście, jest to wygodne i bezpieczne; właśnie dlatego pojawia się w wielu aplikacjach. No i coś, co raz zostało napisane i działa, musi działać w i innych miejscach – co też nie jest do końca prawdą, doświadczeni web-developerzy doskonale wiedzą o czym piszemy w tym momencie… 🙂 Jest pozornie wygodne, ponieważ kiedy musimy wykorzystać kawałek kodu z jakiejś funkcji w innym miejscu, po prostu go przeklejamy zamiast odseparować do oddzielnej funkcji, która może być wykorzystana w wielu miejscach. Często też nie chce nam się po prostu szukać czy w kodzie istnieje funkcja, która już realizuje to, czego potrzebujemy, a jeżeli takowa istnieje i została napisana przez kogoś innego, to wychodzimy z założenia, że lepiej jej nie modyfikować, bo jeszcze coś może przestać działać. I tutaj pojawia się pojęcie bezpieczeństwa i obawa, żeby czegoś nie zepsuć.
Dlatego też, zazwyczaj dobrą praktyką jest, aby nie ruszać tego, co działa, o ile nie musimy tego zmodyfikować. Jeżeli przystępujemy tylko do rozbudowy oprogramowania, dobrze jest pisać kod optymalnie, tworzyć kod i funkcje, które będzie można później wykorzystać w innych miejscach, ale pod żadnym pozorem nie powinno się ruszać tego, co działa, choćby nie wiadomo jak nas korciło, żeby to poprawić. Jeżeli jednak naszym celem jest optymalizacja lub poprawa jakiegoś błędu w kodzie, który powielono w kilku miejscach, nie powinniśmy korygować tego błędu tyle razy, ile razy został on powielony. Taki kod należy wydzielić do jednej funkcji i dokonać poprawki w jednym miejscu. Na pozór wydaje się to teraz oczywiste, jednak nie wszyscy tak robią – a doskonale wiemy, że zoptymalizowany kod to kod przyjazny i taki, którym można szybko i łatwo się połapać. A jak wiadomo, czas to pieniądz. Dlatego też – szanujmy swój czas. I pieniądze 🙂