Dobre praktyki przy wdrażaniu oprogramowania – czym może skutkować ich lekceważenie?

Pewnie czasem zastanawiasz się, dlaczego każda zmiana w sklepie zajmuje programiście tyle czasu. Czemu zamiast wrzucić coś na szybko do sklepu, gada coś o repozytorium, FTP-ie i kopii sklepu i dlaczego Twój software house nie jest zadowolony, gdy Twój kolega-programista wrzuci od czasu do czasu jakąś “drobną zmianę” w sklepie na szybko. Przeczytaj ten artykuł. Zrozumiesz to.

Była sobie pizzeria, która postanowiła się nawrócić i wyrzucić ananasa z pizzy hawajskiej. Koncepcja (przynajmniej według większości Włochów) jak najbardziej słuszna, niesie za sobą jednak konieczność wprowadzenia zmian. W ramach oszczędności postanowiono, że po prostu można w menu wykreślić długopisem ananasa, w ten sam sposób poprawić cenę i gotowe. Zadziała? Niby działa… ale:

1. Wygląda paskudnie.
2. Stara wersja nadal jest w ulotkach.
3. Aktualny kucharz został poinformowany słownie o tym, że ma nie dawać ananasa do hawajskiej, jednak co gdy pojawi się nowy kucharz?
4. Co z klientami, którzy są przyzwyczajeni, że hawajska to jednak z ananasem?
5. Jak dowiemy się, kto jest odpowiedzialny za zmianę, kiedy się okaże, że połowa klientów kocha ananasa, są zbulwersowani i przestają przychodzić?
6. Co w sytuacjach krytycznych typu choroba załogi?

Podobnie jest ze sklepem internetowym. Wprowadzanie zmian w działaniu systemu jest prawie tak samo proste jak wykreślenie czegoś z menu. Wystarczy komputer, notatnik, klient FTP i zmiany w kodzie są gotowe. Jednak mogą pojawić się podobne problemy.

Jakie mogą być skutki wprowadzania zmian w kodzie sklepu “na szybko”?

1. Wygląda paskudnie. -> Każdy system ma swoje zasady wdrażania zmian, specyfikację oraz listę dobrych praktyk. Jeśli osoba wprowadzająca zmiany ich nie zna, to wprowadzi je w sposób błędny lub nieoptymalny i nawet jeśli rozwiązanie będzie działać to:

• • Może zostać usunięte przy aktualizacji systemu.
  • Może powodować problemy np. przy zmianie konfiguracji serwera (np. wersja php).

2. Stara wersja nadal jest w ulotkach. -> Zmiany w taki sposób wprowadzony nie są wprowadzone w innych miejscach, które by tego wymagały. Głównie mamy tu na myśli:

• • Repozytorium – jest to historia zmian kodu systemu. W znacznym stopniu ułatwia nam ona pracę ponieważ programista siadając do pracy może dograć do swojego repozytorium wszystkie zmiany wprowadzane przez inne osoby i nie musi analizować całego katalogu na serwerze.
  • Kopie sklepów – kopie sklepów służą do testowania zmian, które chcemy wprowadzić do sklepu produkcyjnego. Powinna być możliwie identyczna tak, aby nic nas nie zaskoczyło po przeniesieniu zmian na live.

3. Aktualny kucharz został poinformowany słownie o tym, że ma nie dawać ananasa do hawajskiej, jednak co gdy pojawi się nowy? -> Podobnie jest z programistami pracującymi na systemie. Nawet jeśli jeden zostanie poinformowany o wprowadzonych zmianach, to jeśli w jego miejsce pojawi się nowy programista – mogą pojawić się błędy.
4. Co z klientami, którzy są przyzwyczajeni, że hawajska to jednak ananas? -> Systemy sklepowe zbudowane są w dużej mierzy w klocków zwanych pluginami. Brak zmian w kodzie pluginów wbudowanych pozwala programistom i twórcom innych pluginów polegać na nich jak na niezmiennej bazie. Jeśli ta baza zostanie zmodyfikowana to mogą pojawić się nieprzewidziane błędy w działaniu pluginów. 
5. Jak dowiemy się kto jest odpowiedzialny za zmianę, kiedy się okaże, że połowa klientów kocha ananasa i odeszli? -> Wprowadzając zmiany i zapisując je w repozytorium mamy historię tego kto, kiedy i w ramach jakiego zadania wprowadził dane zmiany. Dzięki temu jest dużo łatwiej analizować ewentualne błędy, znaleźć osobę mogącą pomóc w analizie kodu, powiązać zmiany z początkami ewentualnych problemów na sklepie itd.
6. Co w sytuacjach krytycznych typu choroba załogi? -> W sytuacja kryzysowych, zwanych u nas pożarami liczy się szybkość działania. Aktualne repozytorium i jak najpełniejsza wiedza o systemie pozwala na szybsze działanie i szybkie rozwiązanie błędu. Kiedy na sklepie pracują też inny programiści, to w przypadku pożaru, nie wiemy czy skupiać się na szukaniu modyfikacji czy na weryfikacji kodu, o którym wiemy.

Co robimy, aby zminimalizować negatywne skutki zmian wprowadzonych z pominięciem dobrych praktyk

Jeśli przejmujemy sklep po innym programiście lub Klient informuje nas, że w sklepie zostały wprowadzone (np. przez niego samego) jakieś zmiany, o których nie wiedzieliśmy wcześniej, wzbudza to naszą czujność. Mając wieloletnie doświadczenie wiemy o tym, że należy zastosować kroki, które zminimalizują ryzyko przykrych konsekwencji takich prac. Podejmujemy wówczas następujące działania:

1. Wrzucamy napotkane zmiany do repozytorium. Nie mamy wtedy informacji o tym, kto i kiedy dokonał zmian, ale przynajmniej wiemy o samych zmianach. 
2. Przenosimy napotkane zmiany na kopię sklepu.
3. Formatujemy napotkane elementy kodu tak, by spełniały standardy (np. kodowanie plików).
4. Informujemy właścicieli sklepów o tym, że napotkaliśmy zmiany, które są zrobione w niewłaściwy sposób i proponujemy ich przerobienie na prawidłowe. W szczególności są to:

• • zmiany wprowadzane w plikach wynikowych, a nie źródłowych (np css wstawiany w pliku *.css zamiast w pliku *. scss, który jest konwertowany do cssa)
  • zmiany w plikach corowych sklepu – proponujemy ich wdrożenie za pomocą odpowiednich metod zalecanych przez producenta oprogramowania
  • zmiany, które wymagałyby częstych modyfikacji kodu – proponujemy przeniesienie takich zmian do panelu zarządzania systemem, tak by kod pozostawał w dużej mierze niezmienny, a zmieniała się tylko konfiguracja z poziomu panelu
  • zmiany wpływające niekorzystnie na wydajność – zdarzają się np. modyfikacje przeszukujące cały kod strony po to, by podmienić jeden pojedynczy element (np. wartość meta title). Proponujemy ich przerobienie w taki sposób by nie wpływały negatywnie na wydajność

Jak widać, tak naprawdę zmiany wprowadzone na szybko później i tak w dużej części wymagają naszej dodatkowej pracy, a jeszcze po drodze mogą powodować wiele problemów. Dlatego warto przemyśleć czy rzeczywiście opłaca się robić w sklepie cokolwiek “na szybko” ignorując dobre praktyki – czy finalnie będzie to oszczędność, czy wręcz przeciwnie.

Co jeśli mimo powyższego chcesz, aby zmiany były wprowadzane przez innych programistów? Sklep jest Twój i masz do tego pełne prawo.