Jak pisać kod łatwy w utrzymaniu? [FRAGMENT]

dowolny programista   Praca programisty komputerowego to wspaniałe zajęcie. Gdy stajesz przed jakimś problemem i otrzymujesz odpowiednie wymagania, możesz opracować rozwiązanie i przełożyć je na język zrozumiały dla komputera. Jest to zadanie bardzo trudne, lecz dające wiele satysfakcji. Kariera programisty komputerowego bywa również jednak rzeczą wymagającą dużej pracowitości i poświęcenia. Jeśli często musisz wprowadzać zmiany w kodzie napisanym przez inne osoby (lub nawet przez samego siebie), wiesz doskonale, że może to być zajęcie naprawdę proste albo naprawdę trudne. Czasami jesteś w stanie szybko zidentyfikować linie kodu, które należy zmienić. Zmiana jest wyraźnie wyizolowana, a testy potwierdzają, że nowy kod działa dokładnie tak, jak chciałeś. Innym razem jedynym rozwiązaniem okazuje się zastosowanie hacka, który więcej problemów powoduje, niż rozwiązuje. Prostota lub złożoność, jaka wiąże się z wprowadzaniem zmian w oprogramowaniu, jest określana jako jego pielęgnowalność lub utrzymywalność (ang. maintainability)^[1]. Pielęgnowalność systemu oprogramowania jest determinowana przez właściwości jego kodu źródłowego. W niniejszej książce omówimy te właściwości oraz zaprezentujemy 10 wytycznych pomocnych w pisaniu kodu źródłowego, który będzie łatwo modyfikować. W tym rozdziale wyjaśnimy, co rozumiemy pod pojęciem pielęgnowalności. Następnie omówimy powody, dla których jest ona tak ważną kwestią. To umożliwi nam wprowadzenie do głównego tematu tej książki, czyli tego, jak budować oprogramowanie, które jest łatwe w pielęgnacji od samego początku. Na koniec tego wprowadzenia omówimy powszechne zarzuty dotyczące pielęgnowalności oraz przedstawimy podstawowe zasady stojące za wspomnianymi 10 wytycznymi, które zostały zaprezentowane w niniejszej publikacji.  

1.1. Czym jest pielęgnowalność?

  Wyobraź sobie dwa różne systemy informatyczne, które oferują dokładnie tę samą funkcjonalność. Przy tych samych danych wejściowych wytwarzają ten sam efekt końcowy. Jeden z tych dwóch systemów działa szybko i jest prosty w obsłudze, a jego kod źródłowy łatwo jest zmodyfikować. Drugi jest powolny i trudno się go używa, a jego kodu źródłowego niemal nie da się zrozumieć, nie mówiąc już nawet o wprowadzeniu w nim jakichkolwiek zmian. Mimo że obydwa te systemy oferują te same możliwości funkcjonalne, ich jakość różni się w oczywisty sposób. Pielęgnowalność (czyli to, jak łatwo można zmodyfikować system) jest jedną z cech jakości oprogramowania. Inną jest wydajność działania (czyli to, jak szybko system wytwarza efekt końcowy). Międzynarodowy standard ISO/IEC 25010:2011 (który w tej książce nazywać będziemy po prostu ISO 25010^[2]) wyróżnia osiem cech składających się na jakość oprogramowania: pielęgnowalność, stabilność funkcjonalna, wydajność działania, kompatybilność, użyteczność, niezawodność, bezpieczeństwo i przenośność (ang. odpowiednio: maintainability, functional suitability, performance efficiency, compatibility, usability, reliability, security, portability). W tej książce skupimy się wyłącznie na pielęgnowalności. Choć standard ISO 25010 nie określa sposobu mierzenia jakości oprogramowania, nie znaczy to jeszcze, że pomiar taki jest niemożliwy. W dodatku A przedstawiliśmy, jak mierzymy jakość oprogramowania w ramach Software Improvement Group (SIG) w zgodzie z wytycznymi standardu ISO 25010.   Cztery rodzaje działań związanych z pielęgnowaniem oprogramowania   Pielęgnacja oprogramowania nie polega na naprawianiu zużywających się elementów. Oprogramowanie nie ma charakteru fizycznego, a co za tym idzie, nie niszczy się samo z siebie, jak mają w zwyczaju przedmioty fizyczne. Mimo to większość systemów informatycznych jest nieustannie modyfikowana już po dostarczeniu ich klientom. Właśnie o to chodzi w pielęgnowaniu oprogramowania. Można tu wyróżnić cztery podstawowe rodzaje zadań:

• W oprogramowaniu wykrywane są błędy, które muszą być naprawiane. Tego typu działania nazywane są pielęgnacją korekcyjną (ang. corrective maintenance).
• System musi być dostosowywany do zmian występujących w środowisku, w którym działa. Przykładem mogą tu być aktualizacje systemu operacyjnego lub wykorzystywanej technologii. Nosi to nazwę pielęgnacji adaptacyjnej (ang. adaptive maintenance).
• Użytkownicy systemu (albo inni interesariusze) zmieniają wymagania lub zgłaszają nowe. Działania związane z ich wdrażaniem określane są mianem pielęgnacji doskonalącej (ang. perfective maintenance) lub po prostu udoskonalania.
• Znaleziono sposoby, aby poprawić jakość systemu lub zapobiec wystąpieniu przyszłych błędów w działaniu oprogramowania. Działania mające wprowadzić w życie tego rodzaju zmiany noszą nazwę konserwacji profilaktycznej (ang. preventive maintenance).

1.2. Dlaczego pielęgnowalność jest ważna?

  Jak zdążyłeś się już dowiedzieć, pielęgnowalność jest zaledwie jedną z ośmiu charakterystyk jakości produktu programistycznego określonych w normie ISO 25010. Dlaczego zatem jest tak istotna, aby miała zasługiwać na napisanie całej książki poświęconej wyłącznie jej samej? Istnieją dwie odpowiedzi na to pytanie:

• Pielęgnowalność — albo też jej brak — ma znaczący wpływ na biznes.
• Pielęgnowalność ma decydujące znaczenie dla innych charakterystyk jakości.

  Obydwie te odpowiedzi zostaną szerzej omówione w dwóch kolejnych punktach.   Pielęgnowalność ma znaczący wpływ na biznes   W procesie rozwoju oprogramowania etap pielęgnacji systemu trwa często 10 lat lub nawet dłużej. Przez większą część tego czasu mamy do czynienia z ciągłym strumieniem problemów, które należy rozwiązać (to pielęgnacja korekcyjna i adaptacyjna), a także propozycji udoskonaleń, które muszą być wdrożone (to pielęgnacja udoskonalająca). Wydajność i efektywność, z jakimi problemy mogą być rozwiązywane, a ulepszenia wprowadzane w życie, mają zatem duże znaczenie dla interesariuszy. Wysiłki związane z pielęgnacją są mniejsze, gdy rozwiązania problemów i udoskonalenia mogą być wdrażane szybko i łatwo. Jeśli wydajna pielęgnacja pozwala ograniczyć liczbę odpowiedzialnych za nią osób (programistów), obniża również koszty operacyjne. Gdy liczba programistów nie ulega zmianie, dzięki wydajnej pielęgnacji mają oni więcej czasu na inne zadania, takie jak tworzenie nowej funkcjonalności. Szybkie wdrażanie ulepszeń oznacza skrócenie czasu wprowadzania na rynek nowych produktów oraz usług obsługiwanych przez system. Zarówno w przypadku rozwiązywania problemów, jak i wdrażania ulepszeń sprawdza się twierdzenie, że jeśli działania te są powolne i kłopotliwe, może to doprowadzić do sytuacji, w której nie uda się dotrzymać terminów lub system stanie się bezużyteczny. Firma SIG zgromadziła empiryczne dowody, że rozwiązywanie problemów i wdrażanie udoskonaleń są działaniami dwukrotnie szybszymi w systemach o pielęgnowalności przewyższającej średnią niż w systemach z pielęgnowalnością niższą niż średnia. Dwukrotność to znacząca wartość w przypadku systemów biznesowych. Czas niezbędny do rozwiązania problemu i wdrożenia ulepszenia liczy się w dniach lub tygodniach. Nie mamy tu do czynienia z różnicą pomiędzy poprawieniem 5 a 10 błędów w ciągu godziny, lecz z różnicą pomiędzy byciem pierwszym, który dostarczy nowy produkt na rynek, a oglądaniem pleców konkurencji, która wyprzedza nas o całe miesiące. A to tylko różnica pomiędzy pielęgnowalnością powyżej i poniżej średniej. W firmie SIG mieliśmy do czynienia z zupełnie nowymi systemami, których pielęgnowalność była tak niska, że właściwie nie dało się ich modyfikować — działo się tak nawet jeszcze przed wejściem tych systemów do produkcji. Zmiany wprowadzały więcej błędów, niż udawało się dzięki nim naprawić. Proces programowania trwał tak długo, że dawno już zdążyło się zmienić środowisko biznesowe (a więc i wymagania użytkownika). Konieczne były kolejne modyfikacje, które wprowadzały jeszcze więcej błędów. Najczęściej okazywało się, że systemy takie musiały być spisane na straty, jeszcze zanim miały okazję doczekać się swojego pierwszego wydania.   Pielęgnowalność ma decydujące znaczenie dla innych charakterystyk jakości   Innym powodem, dla którego pielęgnowalność to szczególny aspekt jakości oprogramowania, jest to, że ma ona wpływ na inne charakterystyki jakości. Gdy system jest wysoce pielęgnowalny, łatwiej dokonywać ulepszeń w innych obszarach jakości, takich jak naprawianie błędów zabezpieczeń. Bardziej ogólnie rzecz ujmując, można stwierdzić, że optymalizacja systemu informatycznego wymaga modyfikacji jego kodu źródłowego, niezależnie od tego, czy chodzi o kwestie wydajności, przydatności funkcjonalnej, bezpieczeństwa czy też którąkolwiek inną z siedmiu pozostałych niepielęgnowalnościowych charakterystyk zdefiniowanych przez standard ISO 25010. Zdarza się, że są to niewielkie, lokalne modyfikacje. Czasami wiążą się one z bardziej inwazyjną restrukturyzacją. Wszystkie zmiany wymagają odszukania określonego fragmentu kodu źródłowego, przeanalizowania go, zrozumienia jego wewnętrznej logiki oraz miejsca w procesie biznesowym, który oprogramowanie ma upraszczać, przeanalizowania zależności występujących pomiędzy różnymi częściami kodu, przetestowania ich oraz przepchnięcia przez cały proces programistyczny. W każdym przypadku modyfikacje te łatwiej wykonać w systemie pielęgnowalnym, dzięki czemu implementacja optymalizacji jakościowych może odbyć się szybciej i efektywniej. Na przykład, wysoce pielęgnowalny kod jest stabilniejszy niż kod niepielęgnowalny, ponieważ zmiany w systemie pielęgnowalnym mają mniej efektów ubocznych niż zmiany w systemie powikłanym, który trudno się analizuje i testuje.  

1.3. Trzy podstawowe zasady, na których oparto wytyczne umieszczone w tej książce

  Skoro pielęgnowalność jest tak istotna, jak możesz poprawić ją w przypadku kodu, który piszesz? W książce tej przedstawiono 10 wytycznych, które — gdy będzie się ich przestrzegać — umożliwiają tworzenie wysoce pielęgnowalnego kodu. W kolejnych rozdziałach każda z tych wytycznych jest prezentowana i omawiana szczegółowo. W niniejszym rozdziale przedstawimy zasady stojące za tymi wytycznymi. Oto one:

1. Pielęgnowalność wzrasta, gdy trzymamy się prostych wytycznych.
2. Pielęgnowalność nie wynika z refleksji, lecz powinna być brana pod uwagę od samego początku projektu programistycznego. Liczy się tu dosłownie każdy składnik.
3. Niektóre naruszenia są gorsze od innych. Im bardziej przy tworzeniu systemu informatycznego trzymamy się wytycznych, tym bardziej jest on pielęgnowalny.

  Zasady te zostały szczegółowo wyjaśnione poniżej.   Zasada 1. Pielęgnowalność zyskuje najbardziej dzięki prostym wytycznym Niektórym może się wydawać, że pielęgnowalność wymaga użycia jakiejś „srebrnej kuli”, czyli jednej technologii lub zasady, która załatwia temat raz na zawsze, automagicznie. Kierujemy się tu zupełnie inną zasadą, wierząc, że pielęgnowalność wymaga postępowania według prostych, naprawdę niewyszukanych wytycznych. Zapewniają one wystarczający, nie zaś doskonały poziom pielęgnowalności (czymkolwiek ten ostatni by nie był). Kod źródłowy powstały według tych wytycznych można nadal poprawić, aby stał się on jeszcze bardziej pielęgnowalny. Jednak w pewnym momencie dodatkowe zyski płynące ze wzrostu pielęgnowalności stają się coraz mniejsze, podczas gdy koszt jej zwiększania szybko rośnie.   Zasada 2. Pielęgnowalność nie wynika z refleksji i liczy się każdy składnik Pielęgnowalność powinna być uwzględniana w projekcie informatycznym od samego początku. Rozumiemy, że trudno stwierdzić, czy pojedyncze „naruszenie” wytycznych przedstawionych w tej książce ma wpływ ma całkowitą pielęgnowalność systemu. To właśnie dlatego wszyscy programiści muszą zachować dyscyplinę i podążać za wytycznymi, aby móc opracować system, który jest ogólnie pielęgnowalny. Z tego powodu Twój indywidualny wkład ma zasadnicze znaczenie dla całości. Przestrzeganie wytycznych przedstawionych w tej książce nie tylko skutkuje otrzymaniem bardziej pielęgnowalnego kodu, lecz również daje właściwy przykład Twoim kolegom programistom. Pozwala to uniknąć „efektu wybitych okien”, powstającego, gdy inni programiści chwilowo poluzowują swoją dyscyplinę i idą na skróty. W świeceniu dobrym przykładem nie chodzi koniecznie o to, aby być najbardziej wykwalifikowanym inżynierem, lecz raczej o to, aby zachować właściwą dyscyplinę w czasie programowania.  

Pamiętaj, że nie piszesz kodu wyłącznie dla siebie, lecz również dla mniej doświadczonych programistów, którzy przyjdą po Tobie. Ta myśl powinna pomóc Ci upraszczać rozwiązanie, które tworzysz.

  Zasada 3. Niektóre naruszenia są gorsze od innych Wytyczne przedstawione w tej książce traktują progi metryczne jako regułę bezwzględną. W rozdziale 2. mówimy na przykład, abyś nigdy nie pisał metod, które zawierają więcej niż 15 linii kodu. Jesteśmy w pełni świadomi, że w praktyce niemal zawsze będą się zdarzały wyjątki w stosowaniu tej wytycznej. Co zaś, gdy w jakimś fragmencie kodu uda Ci się naruszyć jakąś wytyczną lub nawet kilka z nich? Wiele narzędzi programistycznych pomagających w zachowaniu właściwej jakości oprogramowania działa zgodnie z założeniem, że każde, dosłownie każde naruszenie zasad jest złe. Ukrytym założeniem jest tu to, że wszystkie tego rodzaju naruszenia powinny być usunięte. W praktyce usuwanie wszystkich naruszeń nie jest ani konieczne, ani opłacalne. Takie bezkompromisowe podejście do naruszeń wytycznych może doprowadzić do sytuacji, w której programiści będą zupełnie ignorować naruszenia. Nasze podejście jest inne. Aby metryki były proste, a jednocześnie praktyczne, określamy jakość pełnej bazy kodu nie na podstawie liczby naruszeń, z którymi mamy w niej do czynienia, lecz według jej profili jakości (ang. quality profiles). Profil jakości dzieli metryki na odrębne kategorie, obejmujące przypadki od kodu całkowicie zgodnego z wytycznymi aż do takiego, który silnie je narusza. Korzystając z profili jakości, możemy odróżnić umiarkowane naruszenia (takie jak metoda zawierająca 20 linii kodu) od poważnych (przykładem może tu być metoda z 200 liniami kodu). W kolejnych podrozdziałach (tuż po podrozdziale następnym, w którym omówione zostały powszechne nieporozumienia związane z pielęgnowalnością) wyjaśnimy, w jaki sposób profile jakości są wykorzystywane do mierzenia pielęgnowalności systemu. --- ^[1] W literaturze można się również spotkać z terminami naprawialność, serwisowalność, łatwość konserwacji, łatwość pielęgnacji lub łatwość utrzymania — przyp. tłum. ^[2] Jego pełna nazwa to: International Standard ISO/IEC 25010. Systems and Software Engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and Software Quality Models, wydanie pierwsze, 2011-03-01.

  Fragment pochodzi z książki Oprogramowanie  łatwe w utrzymaniu Joosta Vissera. Strona książki >>