Standard — słowo zazwyczaj odnoszące się do oczekiwań wobec czegoś, w inżynierii oprogramowania nabrało bardzo dosłownego znaczenia. Standaryzować chcemy wszystko – styl pisania kodu, komunikację pomiędzy usługami, bezpieczeństwo, architekturę, a nawet proces Code Review. Co jeśli przyjęta przez nas norma została powszechnie wyparta przez inny standard – wygodniejszy, lepszy, bardziej atrakcyjny. Czy można zmienić standardy?

Po co nam standardy?

Jako programiści stale produkujemy kod. To niestety mit. Trudno jest się z tym pogodzić, ale więcej czasu spędzamy na czytaniu i próbie zrozumienia kodu niż na jego pisaniu. W końcu, aby dokonać zmiany, trzeba dowiedzieć się, gdzie ową zmianę wprowadzić. Kod, który produkujemy, może stać się niezrozumiały nawet dla nas samych i jest to całkowicie naturalne. Każdy z nas ma inny styl pisania, własne przekonania i doświadczenie składające się na rozwiązanie, które ostatecznie trafia do wspólnego repozytorium.

W tym miejscu rozwiązanie zderza się z wizją innych programistów – nieważne czy lepszą, czy gorszą – w każdym razie inną. Które rozwiązanie powinno się przyjąć? Wydajniejsze, najszybsze, najkrótsze?

Odpowiedzią na to pytanie powinno być – zgodną ze standardem. Jeżeli przy okazji dane rozwiązanie spełnia inne kryteria, na których nam zależy, to jest to dodatkowy atut. Standardy pomagają nam trzymać projekt w miarę spójnej formie. Ale czym właściwie jest standard?

Czym jest standard?

Standardem możemy określić zbiór reguł, które muszą zostać spełnione dla rozwiązania, aby można było uznać je za akceptowalne w konkretnej sytuacji. Będąc w temacie programowania, dokonamy dosyć prostej klasyfikacji wraz z przykładami.

Standardy narzucone – dotyczą wszystkiego, na co nie mamy bezpośredniego wpływu, np.:

  • standardy w ramach używanej technologii
  • szeroko pojęte prawo mające wpływ na wytwarzane oprogramowanie

Standardy przyjęte – wszystko, co zostało przyjęte przez zespół dobrowolnie, np.:

  • język używany w projekcie
  • paradygmat programowania
  • styl formatowania kodu
  • architektura
  • sposób dokumentowania oprogramowania
  • sposób testowania oprogramowania

Do powyższej listy możemy dodać jeszcze standardy moralne 😉, jak np. pisanie bezpiecznego oprogramowania czy też unikanie używania zmiennych globalnych.

Jak widać, programiści mają bezpośredni wpływ jedynie na standardy, które sami przyjmują (ew. są im narzucane przez innych programistów). Nawet jeżeli zespół nie ma ustalonych odgórnych norm w swoim projekcie, to sama natura programisty dąży do ciągłego poszukiwania struktur, a co za tym idzie – wytwarzania nowych standardów.

Standardy są sposobem na organizację i ułatwienie pracy. Zapewniają także poczucie bezpieczeństwa, ponieważ dążą do ujednolicania rozwiązań, tworząc znajome i przewidywalne struktury dla każdego, kto owych standardów przestrzega. Zamiast tracić czas na krytykę stylu pisania czy też poznawanie kolejnego sposobu otrzymywania jakiegoś zasobu z bazy danych możemy poświęcić czas na analizę rozwiązań ważnych z punktu widzenia biznesowego.

Czy standardy są nieśmiertelne?

Odpowiadając na pytanie: „Czy standardy są nieśmiertelne?” – istnieją one tak długo, jak długo są ludzie chcący je utrzymywać. Bo to od ludzi wszystko zależy: ich wybór (przynajmniej w kwestii standardów przyjętych), jak i ich egzekwowanie. Należy mieć na uwadze, że nic na świecie nie jest wieczne, nie mówiąc już o świecie IT, gdzie wszystko zmienia się w ekspresowym tempie.

Młodzi programiści, którzy zdobywają wiedzę w Internecie, będą posiłkować się przykładami oraz kursami, które aż kipią od nowych technologii oraz standardów. Wiele z nich branych jest za pewnik bez większej refleksji. Popularność nowych standardów wyznacza pewien trend, za którym podążają Ci wszyscy, który chcą utrzymać się na topie.

Brak aktualizacji standardów i używanych technologii może spowodować, że projekt, pomimo swojej spójności, może szybko stać się mało atrakcyjny dla młodych programistów. Wszystko z racji przywiązania do starych technologii, stylu pisania, podejścia do rozwijania architektury czy też procesu wdrożeń. W oczach młodych programistów, brak rozwoju w tym kierunku oznacza cofanie się.

Jak więc aktualizować standardy? Czy jest to w ogóle możliwe? Jak odróżnić zwykłe przejście z jednego standardu w drugi od chaosu wynikającego z ich braku?

Reforma standardów w istniejącym projekcie

Komunikacja

Najważniejszym z etapów aktualizacji standardów jest rozmowa o nich w gronie ludzi, którzy będą odpowiadali za ich utrzymywanie. Komunikacja ma szczególne znaczenie w tym przypadku, ponieważ istotne jest, aby wszyscy byli dobrze poinformowani i rozumieli, co jest przedmiotem zmiany i co chcemy dzięki niej osiągnąć. W realizację tego celu powinni być zaangażowani wszyscy – ten cel musi być wspólny i jednakowo rozumiany przez cały zespół. Brak porozumienia w tej kwestii może prowadzić do konfliktów, a przez to do pogorszenia jakości pracy.

Wprowadzenie chaosu

Jeżeli cel został odpowiednio zakomunikowany zespołowi, można przystąpić do dzieła. Sposób, w jaki są dokonywane zmiany ściśle zależy od tego, czego właściwie dotyczą. Inaczej będzie się miała kwestia wprowadzenia określonego stylu formatowania kodu, a inaczej zmiana architektury bądź sposobu komunikacji między komponentami.

W każdym razie, tymczasowy chaos jest nieunikniony. Można sobie z nim radzić, stosując różne techniki, jak np. automatyzacja procesu aktualizacji, deprecjonowanie starego kodu na rzecz nowych rozwiązań lub też całkowite porzucenie starego kodu.

Życie z chaosem

Należy mieć na uwadze to, że nie wszystko opłaca się refaktoryzować. W praktycznie każdym większym systemie istnieją miejsca używane tak rzadko lub miejsca tak zawiłe, że nikt nie ma ochoty się w nie zagłębiać.

Decyzja o pozostawieniu takich miejsc w stanie niezmienionym oznacza zgodę na pozostawienie chaosu, czyniąc go integralną częścią projektu. Jak wcześniej jednak zauważyliśmy, w świecie IT nic nie jest wieczne i kiedyś przyjdzie pora na walkę z tak zastanym kodem. Do tego czasu należy się skupić na miejscach, gdzie nowe standardy rzeczywiście mogą pomóc w bieżącym developmencie.

Wstrząśnięte, niezmieszane

Utrzymywanie 2 równoległych standardów wygląda z perspektywy osoby trzeciej jak totalny brak spójności, jednak w tym szaleństwie jest metoda. Członkowie zespołu mający jasno sprecyzowany cel wiedzą, w jaki sposób obchodzić się z potencjalnym chaosem.

Oprócz komunikacji ważną regułą podczas pracy jest dobra imprezowa zasada: Nie mieszaj.

Skoro padła decyzja o porzuceniu starego sposobu pisania, starej architektury czy też innego rozwiązania, to jest jasne, że nie należy używać ich w nowym kodzie. Każdy nowo wyprodukowany kod powinien być zgodny z nowo przyjętymi standardami, które stanowią cel, do którego zespół powinien dążyć. Z drugiej strony, warto poprawiać stary kod, który z łatwością może być dostosowany do nowych standardów. To może wpłynąć pozytywnie na redukcję długu technicznego w dłuższej perspektywie.

Podsumowanie

Standardy są elementem, do którego dążą wszyscy programiści, bez względu na to, czy mają je jasno zdefiniowane, czy nie. Jest to podyktowane ciągłą chęcią strukturyzowania świata, w którym żyjemy. Coś, co jest nam znane, nie jest przez nas odbierane jako zagrożenie.

Z chwilą przyznania się do posiadania ścisłych standardów, bez refleksji i bez chęci poszukiwania nowych rozwiązań, projekt zaczyna tracić na atrakcyjności w oczach developerów. Ogarnianie chaosu to niekończąca się misja, której cel powinien być znany i komunikowany wszystkim członkom zespołu.

W czasach, kiedy na rynku IT dominuje pracownik, firmy muszą uciekać się do różnych sztuczek, chcąc ściągnąć pracowników do swoich projektów. Pieniądze i benefity kuszą, ale to jednak atrakcyjność projektu, mierzona najnowszymi standardami, odkrywa kluczową rolę. Czy to nie jest wystarczający powód, aby wprowadzić trochę chaosu do swoich projektów, jednocześnie dając obecnym programistom lekki powiew świeżości?