Kolejna autorka na ImagineBlog – programistka Oktawia Malec o zasadach dobrego programowania.

Wiele mówi się o zasadach tworzenia jasnego,  łatwego w utrzymaniu i rozwoju kodu. W przypadku aplikacji internetowych ich stosowanie jest równie ważne, jak w implementacjach „desktopowych”.

Bardzo często jednak to, że stosunkowo łatwo nauczyć się podstaw tworzenia oprogramowania webowego powoduje, że początkujący programiści nie stosują się do żadnych zasad, wychodząc z założenia, że „przecież działa, więc nie ma się czym przejmować”. Z czasem takie podejście mści się na pierwotnym twórcy lub (gorzej) jego następcy, np. przy próbie modyfikacji działania czy rozwoju aplikacji. Ze względów biznesowych podczas prac nad projektem ważną rzeczą jest zwrócenie uwagi na stosowanie się do co najmniej kilku podstawowych zasad.

Każdy szanujący się programista zna przynajmniej 2 reguły poprawnego tworzenia kodu. Są nimi KISS – akronim, który w podstawowej wersji można rozwinąć w Keep It Simple, Stupid oraz DRY czyli Don’t Repeat Yourself.

–

KISS wymaga od programisty tego, żeby kodu nadmiernie nie komplikować. Jeśli zadaniem aplikacji jest tylko i wyłącznie wypisanie na ekran jakiegoś zdefiniowanego na stałe ciągu znaków, nie jest do tego zadania potrzebne tworzenie całego zestawu modułów, klas dziedziczących, interfejsów i metod, które tak naprawdę mogłyby sprowadzić się do napisania jednej linii kodu.

DRY mówi o tym, że poszczególne części kodu powinny być unikalne w obrębie aplikacji. Dzięki temu, na wypadek potrzeby zmiany fragmentu kodu wystarczy zmienić go w jednym miejscu. Niestosowanie się do tej zasady może nastręczyć wiele błędów w kodzie i utrudnić życie nie tylko programistom, ale też testerom podczas sprawdzania poprawności działania oprogramowania.

–

Stosowanie obu tych zasad jest tak naprawdę ze sobą powiązane. Czasem prościej, bardziej intuicyjnie byłoby skopiować kod kilka razy w systemie niż stosować się do reguły DRY, ale też nie należy przesadzać w żadną stronę. Istnieje również zasada ROT (Rule of three), którą można nazwać kompromisem pomiędzy KISS i DRY. Pozwala ona na jednorazowe skopiowanie kodu. Jeśli jednak istnieją w systemie 3 kopie tego samego fragmentu – należy poważnie zainteresować się refaktoryzacją, by uchronić się przed przyszłymi problemami związanymi ze zmianami kodu w 3 różnych miejscach.

–

Dokumentacja. Niezbędną, niestety często niedocenianą zasadą jest dokumentacja kodu. Nie muszę wspominać o jej zaletach, a wszystkim wiadomo jak uciążliwy jest jej brak. Jeśli więc nie stosujesz się do niej – zacznij od teraz mimo, że brakuje na to czasu i nie zawsze wystarczy chęci. Dokumentacja to podstawa.

–

Powyższe metody odnoszą się praktycznie wyłącznie do tworzenia kodu na podstawie już znanej specyfikacji działania aplikacji.

W cyklu życia każdego projektu istnieje moment, którym należy wstrzymać się z kodowaniem i zacząć analizować jego ewentualną przyszłość. Zastanowić się, które funkcjonalności, moduły czy rozwiązania musimy stworzyć już teraz, czy też poczekać z tym do kolejnej wersji lub zupełnie pominąć te, a wdrożyć całkowicie nowe. W tym momencie znika rola typowego programisty – na pierwszy plan wysuwa się zarządzanie rozwojem oprogramowania. Przydatne mogą być wtedy dwie kolejne zasady: YAGNI i MoSCoW.

–

YAGNI (You Ain’t Gonna Need It) zaleca, aby nie planować funkcjonalności, o których uważamy, że „kiedyś mogą się przydać”.

–

Zwolennicy YAGNI odradzają  patrzenie zbyt daleko w przyszłość “życia aplikacji”. Radzą być minimalistą i tworzyć jedynie funkcjonalności, które są określone w aktualnych wymaganiach. W innym wypadku po jakimś czasie może się okazać, że traciliśmy czas na coś, co tak naprawdę nigdy się nie przyda, lub co gorsze, nasze rozwiązanie nie jest odpowiednie do tego, jak została zaimplementowana reszta systemu i w związku z tym i tak musimy zacząć od początku.

–

MoSCoW (M – Must have it, S – Should have it, C – Could have if not affecting other things, W – Won’t have this time). Jest to metoda z zarządzania i rozwijania oprogramowania. Zaleca ona podział wymagań klienta na kilka podgrup: te które musi mieć (M), te które powinien mieć (S), które może mieć (C) jeżeli nie zaszkodzą tworzeniu gotowych funkcjonalności, oraz te, których w danym terminie nie uda się zaimplementować (W).

–

Zasada MoSCoW przydatna może być w przypadku bardzo krótkiego terminu wykonania projektu, kiedy konieczna jest priorytetyzacja zadań, aby uniknąć przekroczenia deadline’u. Oczywiście każdy zdaje sobie sprawę, że wszystkie wymagania zawarte w zleceniu są ważne i zależy nam na jak najszybszym dostarczeniu w pełni działającego produktu. Chodzi tylko o to, aby wskazać, które z nich będą wykonywane w pierwszej kolejności oraz implementacja których z nich w razie zagrożenia terminu może zostać przeniesiona do kolejnego etapu.

Decyzja o kolejnych krokach rozwoju oprogramowania należy do osoby za to odpowiedzialnej w danym projekcie i powinna zostać dopasowana do konkretnego klienta. Stosowanie zasady YAGNI może w przypadku jednego projektu być całkowicie zasadne, natomiast przy kontakcie z bardziej wymagającym, oczekującym szybkiej reakcji i elastyczności kontrahentem, jej łamanie może okazać się zbawieniem.

Z kolei z mojego doświadczenia wynika, że terminy większości projektów są bardzo napięte, więc prawidłowe zastosowanie MoSCoW może ułatwić tworzenie oprogramowania tak na poziomie samego kodowania, jak i kontaktów z klientem.

Podobnych zasad tworzenia i rozwoju aplikacji istnieje mnóstwo. Każdy twórca oprogramowania przestrzega tych reguł, które uważa za słuszne i przydatne. Nie jest możliwe w praktyce stosowanie ich wszystkich. Restrykcyjne trzymanie się tylko jednej z nich może spowodować łamanie drugiej. Należy wypracować pewien kompromis i umiejętnie dobrać rozwiązanie do określonych wymagań.   Wtedy możemy być pewni, że nasi współpracownicy, ewentualni następcy lub my sami nie będziemy narzekać na kod, który modyfikujemy.

Oktawia Kyc

Tagi: Aplikacje internetowe, DRY, KISS, MoSCoW, Oktawia Malec, YAGNI, zasady kodowania, zasady tworzenia oprogramowania

Ten wpis został opublikowany Sobota, luty 20th, 2010 o 18:47 i jest zaszufladkowany do kategorii Aplikacje internetowe, Kodowanie, Tworzenie oprogramowania. Możesz śledzić wszystkie odpowiedzi do tego wpisu poprzezkanał RSS 2.0. Możesz dodać odpowiedź lub trackback ze swojej strony.