„Jeśli powiemy zespołowi, że chcemy poprawić dokładność oszacowania, metryka ta zostanie poprawiona bez względu na skróty, którymi pójdzie zespół.”
Ken Schwaber
„Sprawne zarządzanie projektami metodą Scrum”
przekład : Daniel Czerewacki, Adam Kasprzyk
W firmach zajmujących się tworzeniem oprogramowania z użyciem agilowych metodyk prowadzenia projektu, bardzo czesto dochodzi do sytuacji, w której zarząd wyraża swoje zaniepokojenie faktem, że szacowania (estymacje) dokonywane przez zespół są – delikatnie mówiąć – nieprecyzyjne. Napięcie z każdym sprintem jest coraz większe, aż w końcu zostaje podjęta decyzja – trzeba coś z tym zrobić. Przecież w takich wrunkach nie można prowadzić biznesu! Zarząd próbuje zaradzić tej niekomfortowej dla siebie sytuacji wprowadzając różnego rodzaju praktyki, które mają pomóc w tym, aby estymacje stały się bardziej precyzyjne. Najczęściej pojawia się pomysł, aby notować rzeczywistą liczbę godzin spędzonych na realizacji każdego zadania i porównywać ją z tą szacowaną. I tu dopiero zaczynają się prawdziwe problemy.
Estymacja (szacowanie) z definicji nie jest precyzyjną miarą pewnej wielkości a jedynie miarą przybliżoną. Nieprzypadkowo twórcy Agile na określenie procesu przewidywania nakładu pracy użyli właśnie słowa estimation. Ma to swoje głębokie uzasadnienie w podstawach metodyki Agile, która opiera się na empirycznej kontroli procesu, którego istotą nie jest idealna przewidywalność ale częsta inspekcja i adaptacja. Przeprowadzamy je właśnie po to, aby na bieżąco lokalizować i poprawiać wszelkie błędne decyzje, przeszkody i nieścisłości wynikające z faktu, że przy tworzeniu oprogramowania mamy do czynienia ze skomplikowanym i złożonym procesem przebiegającym w warunkach zmiennej i nieprzewidywalnej rzeczywistości. Dlatego wszakże zdecydowaliśmy się wprowadzić Agile!
Jeśli zaczniemy wywierać presję na zespół, aby poprawił dokładność estymacji – zrobi to. Jeśli od dokładności szacowania zależeć będą premie, bonusy czy awanse – dokładność estymacji z pewnością ulegnie poprawie… tyle tylko, że poprawa ta pojawi się kosztem innego elementu procesu! W przypadku tworzenia oprogramowania, najprawdopodobniej ucierpi na tym jakość. Jakość implementowanej funkcjonalności lub po prostu jakość kodu. Coś, czego zarząd nie zauważy „gołym okiem” i wszyscy będą szczęśliwi, ale tylko do czasu…
Nie próbujmy działań wymierzonych przeciwko zasadzie samozarządzania i samoorganizacji zespołu chcąc w ten sposób wpływać na dotrzymywanie ustalonych estymacji. Efekty takich działań mogą być katastrofalne.
Każda klasa, funkcja czy zmienna w naszym kodzie źródłowym ma swoją nazwę. Dobór odpowiednich nazw dla wszystkich tych elementów ma fundamentalne znaczenie dla jakości powstającego kodu. Bardzo często w pośpiechu nadajemy nazwy przypadkowe, które nic nie znaczą. Posługujemy się skrótami myślowymi lub akronimami. Dwa miesiące później, z trudem analizujemy swój własny kod próbując odgadnąć co robi ta funkcja i do czego służy tamta zmienna. Nazwy mają ogromne znaczenie więc czas poświęcony na ich odpowiednie dobranie to bardzo dobra inwestycja.
Na co więc zwrócić szczególną uwagę? Jak konstrułować poprawne nazwy róznych elementów naszego kodu żródłowego? Istnieje kilka prostych zasad, które nam w tym pomogą.
Używaj nazw, które coś znaczą – nazw opisowych
Pamiętaj o tym, że nasz kod nie jest przeznaczony tylko dla kompilatora czy interpretera. Bardzo często, czytają go także ludzie więc nazwy użyte w kodzie, powinny jasno informować jaki jest cel, co robi oraz jak jest używany utworzony przez nas element kodu źródłowego. Nazwa powinna być na tyle opisowa, aby nie wymagała żadnego, dodatkowego komentarza. Jeśli utworzymy zmienną :
int s; //pozostały czas w sekundach
jesteśmy zmuszeni dodać komentarz do kodu. Najlepiej jeszcze, powtórzyć ten komentarz w każdym miejscu, w którym użyjemy zmiennej s. Zamiast tego, możemy zadeklarować zmienną o innej nazwie, np :
int remainingTimeInSeconds;
czyli użyć nazwy, która coś znaczy, nazwy opisowej, co w sposób szczególny przyczyni się do poprawy czytelności tworzonego przez nas kodu.
Powinniśmy oczywiście dążyć do tego, aby nazwy były możliwie jak najkrótsze, ale (poza uzasadnionymi przypadkami) nie róby tego kosztem czytelności.
Nie używaj nazw, które mogą wprowadzić w błąd
Od braku informacji gorsze jest tylko jedno, dezinformacja. Jeśli użyjemy nazwy, która nic nie znaczy, osoba analizująca nasz kod straci mnóswto czasu ustalając co przechowuje zmienna lub co robi funkcja. Jeśli natomiast nazwa będzie coś znaczyć i to znaczenie okaże się fałszywą wskazówką, straci tego czasu dwa razy więcej. Fałszywe wskazówki pojawiają się w naszym kodzie przede wszystkim z dwóch powodów :
- nazwa coś znaczy, ale jest źle dobrana przez autora kodu,
- nazwa coś znaczy, była prawidłowo dobrana przez autora kodu, jednak po niedbałej modyfikacji przez innego programistę, nazwa pozostała a cel, funkcjonalność lub sposób użycia się zmienił.
Dla przykładu, uznano, że nie podajemy już pozostałego czasu w sekundach (nasza zmienna int remainingTimeInSeconds) tylko w minutach więc zmieniono wartość przechowywaną w tej zmiennej ale nazwę pozostawiono.
Używaj nazw odległych znaczeniowio
Czasem w naszym kodzie źródłowym pojawiają się nazwy elemetów tego samego typu, bardzo zbliżone znaczeniowo. Powiedzmy, że mamy klasę Student. Wszystko jest w należytym porządku, dopóki w kodzie nie pojawi się druga klasa, tym razem o nazwie StudentInfo, StudentData czy StudentObject. Której klasy należy teraz użyć, aby dotrzeć do historii wpłat czesnego dla danego studenta?
Starajmy się dbać o to, aby nie tworzyć takich dylematów. Aby nasze nazewnictwo nie tylko coś znaczyło, ale było również jednoznaczne. Inne przykłady, tym razem z nazwami funkcji (metod) :
Takie historie pojawiają się w kodzie dość często i są rozumiane wyłączenie przez swoich autorów – z tym, że przez pierwsze dwa miesiące po ich stworzeniu.
Używaj rzeczowników jako nazw klas
Nazwa klasy powinna być rzeczownikiem lub wyrażeniem rzeczownikowym. Poprawne nazwy klas to np. :
Student Address LogParser
Używaj czasowników jako nazw funkcji
Nazwy funkcji (metod), powinny być czasownikami lub wyrażeniami czasownikowymi. Dla przykładu możemy podać :
delete
getName
setName deleteLogs
Używaj jednego określenia dla podobnych operacji
Należy używać tego samego określenia dla wszystkich podobnych operacji. Np. nazwy metod do pobierania różnych wartości z obiektu powinny być skonstrułowane z użyciem tego samego przedrostka. Jeśli się zdecydujemy na get, czyli np. getName, to do konstrułowania nazw dla innych metod pobierających wartości z obiektu powinniśmy konsekwentnie używać przedrostka get a nie np. fetch, retrive czy list.
Wprowadź normy i używaj metryk jakościowych
Dobrą praktyką jest wprowadzenie do firmy norm odnośnie tworzenia nazw elementów kodu źródłowego. Takie rozwiązanie funkcjonuje w wielu firmach tworzących oprogramowanie i efekty tego są bardzo widoczne.
Dodatkowym orężem w walce ze złym nazewnictwem są metryki jakościowe kodu. Wdrożenie w firmie narzędzia do generowania takich metryk, np. CheckStyle oraz uzbrojenie go w zestaw odpowienich wyrażeń regularnych pomoże nam na bieżąco kontrolować zgodność tworzonego kodu z większością wprowadzonych w firmie norm dot. nazw elementów kodu źródłowego.
Dzisiejsze środowiska programistyczne np. Eclipse czy NetBeans dają nam narzędzia, dzięki którym operacje takie jak zmiana nazwy, są bardzo proste i bezpieczne. Korzystajmy więc z ich dobrodziejstw. Przyglądajmy się krytycznie nazwom w naszym kodzie źródłowym i zmieniajmy je jeśli trzeba. Stosujmy się przy tym do zbioru powyższych zasad a jakość naszego kodu z pewnością znacznie się poprawi.
Firmy zajmujące się tworzeniem oprogramowania, poza potrzebą optymalizowania kosztów produkcji, prowadzenia zakrojonych na szeroką skalę kampanii marketingowych i nieustannego dopasowywania profilu działalności do oczekiwań klientów szczególną wagę przywiązują do jakości oferowanych produktów. Nikt chyba nie ma dziś wątpliwości, że w warunkach gospodarki rynkowej to właśnie jakość oferowanego produktu ma kluczowe znaczenie w procesie zdobywania przewagi konkurencyjnej.
W różnych firmach owe „zorientowanie na jakość” rozumiane i realizowane jest w różny sposób. W jednym przedsiębiorstwie hołduje się doktrynie „GoodEnough Quality”, nie do końca rozumiejąc jej zasady, używając jej raczej jako zwrotu-wytrycha umożliwiającego releasowanie kolejnych wersji. W innym znowu, co prawda do jakości przykłada się odpowiednią miarę, ale zamiast poprawiać procesy od najwcześniejszego etapu budowy systemu począwszy, w nieskończoność testuje się i poprawia, testuje i poprawia i znowu testuje… a klienci w tym czasie – kupują produkt firmy konkurencyjnej.
Są również firmy, które terminu „jakość” używają – owszem, ale w kontekście „jakoś to będzie…” :).
Zarządzanie jakością w procesie budowy systemu informatycznego nie jest sprawą ani prostą, ani intuicyjną. Software Quality Assurance, to w dużym uproszczeniu szereg rozłożonych w czasie i skoordynowanych działań, polegających na ciągłym lokalizowaniu i ulepszeniu niedoskonałych procesów oraz kontroli ich realizowania w celu osiągnięcia poprawy jakości produktu. Są to praktyki i metody zorientowane bardziej na likwidację przyczyn niż na naprawę szkód.
No tak. Mamy już ciągłe zmiany w szeroko rozumianym otoczeniu firmy, teraz doszły ciągłe zmiany procesów w samym przedsiębiorstwie a do tego jeszcze ta permanentna kontrola ! Jak zapanować nad tym chaosem? Odpowiedź jest prosta i krótka : Agile. Zwinne metodyki prowadzenia projektów informatycznych nieprzypadkowo wdarły się przebojem do większości światowych koncernów produkujących oprogramowanie i rynek polski nie jest tutaj wyjątkiem. Dopiero połączenie sił umiejętnie stosowanych praktyk związanych z „Software Quality Assurance” oraz zwinnych, agilowych metod prowadzenia projektów, np. Scrum‘a, daje firmie optymalne warunki do zdobywania przewagi konkurencyjnej na niełatwym rynku oprogramowania komputerowego.
Do takiego właśnie rozwiązania, chciałbym Państwa gorąco na tym blogu namawiać, opisując poszczególne praktyki, metody i narzędzia z obszaru Zarządzania Jakością Oprogramowania oraz metodyk Agile.
Scrum jest metodyką prowadzenia projektów. Metodyką zgodną z Agile Manifesto i dlatego zaliczającą się do tzw. zwinnych metodyk prowadzenia projektów. Scrum można również rozumieć jako framework, w ramach którego stosujemy różne procesy oraz techniki, które mają usprawnić i zoptymalizować proces budowy naszego produktu. Nazwa „Scrum”, po polsku „młyn” wywodzi się z terminu występującego w grze rugby. Metodyka Scrum zdecydowanie najczęściej wykorzystywana jest w projektach informatycznych, czyli w projektach o dużym stopniu skomplikowania i innowacyjności, gdzie bardzo ważna jest możliwość szybkiej reakcji na zmiany. Scrum wykorzystuje iteracyjne podejście do budowy produktu.
Trzy główne filary, na których opiera się metodyka Scrum, to : przejrzystość (trasparency), przegląd (inspection) oraz adaptacja (adaptation).
Przejrzystość (Transparency) : Każdy aspekt procesu wytwórczego, wszystkie zasady współpracy, szczegóły każdego zadania muszą być dostępne, doprecyzowane i zrozumiałe dla wszystkich.
Przegląd (Inspection) : Wszystkie aspekty procesów muszą być cyklicznie poddawane przeglądom w celu zlokalizawania przeszkód, które powodują że proces budowy produktu staje się mniej optymalny.
Adaptacja (Adaptation) : Po zlokazliwowaniu przeszkody w procesie wytwórczym, należy tak szybko jak to możliwe wyeliminować ją w celu usprawnienia procesu budowy produktu.
Proces przeglądu (Inspection) oraz adaptacji (Adaptation) w Scrumie, przeprowadzany jest na czterech różnych spotkaniach scrumowych, z których każde ma specyficzny dla siebie zakres oraz cel :
Na dziennym spotkaniu scrumowym (Daily Scrum) dokonujemy przeglądu postępu oraz zagrożeń w stosunku do celu danego sprintu (Sprint Goal). Wprowadzamy niezbędne zmiany, aby zmaksymalizować wartość pracy danego lub następnego dnia roboczego.
Na przeglądzie sprintu (Sprint Review, Demo) lub planowaniu sprintu (Sprint Planning) dokonujemy przeglądu postępu i zagrożeń w odniesieniu do celu releasu (Release Goal). Wyciągamy wnioski i jeśli to konieczne wprowadzamy zmiany do następnego sprintu. Zmiany, które mają zminimalizować ryzyko, że Release Goal nie zostanie osiągnięty.
Na spotkaniu restrospekcyjnym (Sprint Retrospective), na którym dokonujemy przeglądu przeszkód i problemów napotkanych w trakcie trwania zakończonego właśnie sprintu i wprowadzamy do procesów wytwórczych niezbędne zmiany, które naszym zdaniem są potrzene, aby następny sprint był jeszcze bardziej produktywny, niż poprzedni.
Spotkania Daily Scrum, Sprint Review, Sprint Planning oraz Sprint Retrospective zostaną dokładniej omówione w dalszych częściach serii.
Co nowego wnosi Scrum? W czym jest lepszy od stosowanych dotychczas metod iteracyjnych tworzenia oprogramowania? Jaka jest tajemnica wydajności tej metodyki ? Aby wyjaśnić tajemnicę sukcesu Scrum, posłużmy się analogią.
Powiedzmy, że jesteś doświadczonym kierowcą TIR-a, który ma dostarczyć węgiel z Katowic do Szczecina. Masz do przejechania około 700 kilometrów. Twój pracowawca, aby zoptymalizować koszt oraz czas dostawy dokładnie planuje Twoją trasę. Przy tym planowaniu bierze pod uwagę komfort jazdy, poziom spalania dla poszczególnych dróg, remonty, stałe miejsca patroli policyjnych oraz fotoradary, korki, jakość oraz bezpieczeństwo dróg, obecność dobrych punktów gastronomicznych na trasie oraz wiele, wiele innych czynników. Proces takiego planowania jest bardzo skomlikowany. Wymaga zebrania olbrzymiej ilości informacji (w końcu to prawie 700 kilometrów!). Kiedy projekt trasy jest już gotowy, przekazuje Ci go wraz z poleceniem bezwzględnego trzymania się zawartych w nim zapisów. W końcu przygotowywany był z taką starannością i tak olbrzymim nakładem pracy. Nie ma mowy o żandym odstępstwie. Zresztą w tym kształcie został zatwierdzony przez inwestora, więc nie ma o czym mówić…
Startujesz, masz GPSa, CB Radio, komórkę oraz własny bagaż doświadczeń w głowe, ale nic z tych rzeczy w drodze Ci się nie przyda. Trasa została dokładnie zaplanowana. Jednak.. na setnym kilometrze okazało się, że jesteś już zmęczony jazdą, ponieważ Twój przełożony przy wyborze komfortowej trasy kierował się własną subiektywną oceną. Dla niego podróż bocznymi drogami była wygodniejsza, ponieważ nie lubi szybkiej jazdy a wyprzedzjące go ciągle na drodze szybkiego ruchu samochody przyprawiały go o zawrót głowy. Twoja nawykowa dynamiczna jazda, na bocznych uliczkach pociągała za sobą konieczność ciągłego hamowania a następnie przyspieszania co spowodowało iż spalanie było jednak wyższe od założonego. Okazało sie również, że od czasu zbierania informacji o remontach, sytuacja uległa niewielkiej zmianie :). Stoisz więc posłusznie w korkach i masz czas na informowanie przez CB Radio innych uczestników ruchu, aby wybrali alternatywną trasę. Ty nie miałeś takiej mozliwości, mimo iż również dostałeś tą informację. Od czasu projektowania trasy, przybyło również fotoradarów, w jezdni na zaplanowanej drodze porobiły się koleiny a w okolicy otwarto nowe objazdówki. Tobie jednak nie wolno z nich korzystać. Musisz trzymać sie planu. To wszystko spopwowało że masz już spore opóźnienie. Gnasz więc przed siebie jak szalony, łamiąc wszystkie możliwe przepisy ruchu drogowego narażjąc siebie oraz innych podróżnych, choć i tak już nie ma nadziei że zdążysz na czas..
W końcu przybywasz na miejsce… Jesteś spóźniony, zmęczony, sfrustrowany i zdemotywowany. I tak miałeś ogromne szczęście, że klient w czasie jazdy nie zmienił adresu dostawy, bo musiałbyś wtedy wrócić do bazy, po nowy plan :).
A teraz wyobraź sobie, że dostajesz TIR-a załadowanego węglem, oraz :
- adres dostawy (cel sprintu),
- termin dostawy (termin zakończenia sprintu)
- narzędzia potrzebne do pracy oraz pozyskiwania informacji o zmianach, takie jak GPS, CB Radio, telefon komórkowy itp. (codzienne spotkanie scrumowe)
- przepisy ruchu drogowego – (zasady scrumowe)
… i poza tym pełną swobodę działania !
Stajesz się samodzielnym agentem, który sam decyduje o tym którędy pojedzie, z jaką szybkością, gdzie się zatrzyma i na jak długo. Na bieżąco pozyskujesz informacje i podejmujesz decyzje, wprowadzasz niezbędne zmiany, które ułatwiają Ci osiągnięcie celu sprintu – dotarcie pod wskazany adres w określonym terminie. Wykorzystujesz więc dwie najważniejsze właściwości, które leżą u podstaw metodyki Scrum : możliwośc szybkiego reagowania na zmiany oraz samoorganizację.
Szybkie reagowanie na zmiany
Dzięki licznym praktykom przeglądowym oraz adaptacyjnym wbudowanym w Scrum (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrostective), na bieżąco analizujemy sytuację i wprowadzamy niezbędne zmiany, w celu zmaksymalizowania wartości pracy kolejnego dnia roboczego, usunięcia przeszkód w osiągnięciu celu sprintu (Sprint Goal) czy większego uprowadopodobnienia osiągnięcia celu releasu (Release Goal).
Samoorganizacja
Dzięki temu, że ogólne zasady scrumowe są proste w użyciu a definicje zadań jasne i klarowne (istnieją odpowiednie techniki ich opisu) , zespół ma pełną swobodę działania i sam wybiera najlepszą drogę do osiągnięcia celu sprintu (Sprint Goal). Wraz ze swobodą działania, przychodzi kreatywność oraz zaangażowanie. Te z kolei implikują odpowiednią motywację oraz poczucie odpowiedzialności.
Jak wynika z powyższego, tajemnica wydajności metodyki Scrum opiera się głównie o skuteczne mechanizmy szybkiego reagowania na zmiany oraz głęboko zakorzenioną zasadę samoorganizacji pracy zespłów scrumowych.
W warunkach gospodarki rynkowej, elastyczność oraz wsparta odpowiednią motywacją kreatywność, to wartości, które trudo przecenić !
Jaka jest różnica między czystym kodem (ang. clean code) a brudnym (ang. dirty code)? Dlaczego piszemy brudny kod? Czy czysty kod ma w ogóle jakiekolwiek znaczenie?
Niektórzy twierdzą, że jakość kodu nie ma znaczenia, ważne by działał. Nieopatrzenie rozumiejąc metodyki Agile – w pogoni za zwinnością i szybkością – zapominają o dobrych praktykach i standardach. Jest jednak wiele przykładów na to, że budowanie kolosów na glinianych nogach bardzo źle się kończy. Wiele dobrze zapowiadających się firm wypadło z rynku, ponieważ nagle zaczęły mieć kłopoty z jakością. Jak się później okazywało, problemy spowodowane brudnym kodem.
Schemat w każdym przypadku był bardzo podobny. Firma wchodziła na rynek i rozwijała się w piorunującym tempie. Zdobywała klientów, wyprzedzała konkurencję. Jednak po kilku, kilkunastu miesiącach nie była już w stanie z taką dynamiką dokładać kolejnych funkcjonalności. Po następnych kilku miesiącach, wydajność zespołów pracujących w projekcie malała już w zastraszjącym tempie a firma traciła swoich kluczowych klientów, ze względu na pogarszającą się jakość. Kiedy orientowano się w czym rzecz, system trzeba było napisać praktycznie od nowa – kolos stał na glinianych nogach. W tym czasie konkurencja, która dobrze rozłożyła siły w tym biegu z łatwością wygrywała cały wyścig. Okazywało się, że biznes to nie sprint ale bieg długodystansowy.
Każdy z nas zapewne spotkał się z problemem kodu złej jakości. Kiedy trzeba zmodyfikować nieznany nam brudny kod, nasza praca zmienia się w koszmar. Zanim uda nam się ustalić znaczenie zmiennych z1, z2 czy Ol (duże „O” oraz małe „el”) oraz przejrzeć deklaracje i definicje metod o dezinformujących nazwach, to nie mamy już siły na przebrnięcie przez wielokrotnie zagnieżdżone instrukcje if, for a to wszystko jeszcze w pętli while o niespotykanej liczbie warunków. Wypijamy wtedy morze kawy, siedzimy po godzinach i w końcu dajemy radę… Ale jakim kosztem?
Dlaczego tak się dzieje, dlaczego piszemy kod złej jakości?
Moim zdaniem, powody są co najmniej trzy :
brak świadomości, że może być inaczej,
brak czasu lub doświadczenia potrzebnego na stworzenie czystego kodu,
brak wiedzy potrzebnej do tworzenia kodu dobrej jakości .
Fakt, że znalazłeś się na tej stronie drogi Czytelniku, świadczy o tym, że problem pierwszy, czyli brak świadomości, że może być inaczej, już Cię nie dotyczy ;).
Zajmijmy się więc problemem drugim, czyli brakiem czasu lub doświadczenia potrzebnego na stworzenie czystego kodu. Programista, który zna dobre praktyki oraz standardy dot. tworzenia kodu dobrej jakości ale nie ma doświadczenia w ich stosowaniu, potrzebuje więcej czasu, na stworzenie czystego kodu niż na stworzenie kodu działającego, ale niekoniecznie dobrej jakości. Podczas estymacji czasu potrzebnego na wykonanie danego zadania nie odważy się dołożyć 30% tylko po to, aby napisać kod dobrej jakości. Nie zrobi tego z obawy przed niezrozumieniem ze strony innych programistów nie wspominając o przełożonym. Jeśli jednak nie zacznie programować zgodnie ze standardami, nigdy nie nabierze doświadczenia, które pozwoli mu to robić w krótszym czasie. Koło się zamyka. Jedynym rozwiązaniem w takiej sytuacji jest rozmowa z zespołem oraz przełożonym, w której należy uświadomić wszystkich o tym, że problem istnieje i do czego może doprowadzić.
Problem trzeci, czyli brak wiedzy potrzebnej do tworzenia kodu dobrej jakości. Jak wygląda ten czysty kod i czym się charakteryzuje? Jakich technik należy używać, na co zwracać szczególną uwagę aby tworzyć kod dobrej jakości?. Nie uczą tego w szkołach a podręczniki programisty ograniczają się zazwyczaj do podania semantyki i syntaktyki danego języka, spychając zagadnienia związane z jakością kodu na odległy plan.
Każdy kod w zależności od swojego przeznaczenia, będzie optymalizowany pod różnym kątem. Trochę inaczej będzie wyglądał dobrej jakości kod firmware’u do kontrolera RAID a inaczej kod testów jednostkowych. Instnieje jednak zbiór cech, charakterystycznych dla czystego kodu, niezależnie od jego przeznaczenia :
Czysty kod powinien zachowywać się przewidywalnie. Kiedy prześledzimy oczami fragment kodu, nie powiniśmy mieć żadnych wątpliwości do czego służy a po jego uruchomieniu powinien zrobić dokładnie to, czego się spodziewaliśmy.
Czysty kod powinien być prosty i przyjemny w czytaniu. Jego analiza nie powinna być skomplikowana. Czytając go, powinieneś mieć wrażenie, że opowiada zaimplamantowaną historię.
Czysty kod powinien mieć objętość oraz wydajność zbliżoną do optymalnej. Zamniejszamy objętość oraz poprawiamy wydajnośc do momentu, kiedy nie robimy tego kosztem czytelności.
Czysty kod powinien być pokryty testami jednostkowymi i akceptacyjnymi, które przechodzą z wynikiem pozytywnym. Praca z kodem pokrytym testami jest o wiele bardziej komfortowa. Każdą zmianę w kodzie możemy od razu przetestować na okoliczność złego oddziaływania na resztę kodu i to zarówno na poziomie jednostkowym jak i akceptacyjnym.
Aby sprostać powyższym założeniom, musimy zwrócić uwagę na każdy element składowy kodu, czyli zadbać o :
Każde z tych zagadnień postaram się opisać w osobnym artykule.
Nie będzie w tym żadnej przesady, jeśli na pytanie zawarte we wstępie, „jaka jest różnica między czystym kodem a brudnym?” odpowiemy, że dokładnie taka sama jak między „być albo nie być”. Firmy, które poważnie traktują swoją przyszłość – dbają o jakość kodu. Robią to poprzez wprowadzanie odpowiednich standardów kodowania, programy szkoleniowe oraz stosowanie metryk jakościowych kodu. Jeśli w Twojej firmie z jakiegoś powodu o tym wszystkim zapomniano, to może jest to ostatni moment, na wprowadzenie zmian.
