Divante: 6 rzeczy, o których musisz pamiętać przejmując projekt

Przejmowanie utrzymania strony internetowej po innej firmie jest zawsze kłopotliwe. Przede wszystkim chodzi o jakość kodu i zastosowane rozwiązania, które nie było przez nas wykonywane. Specjalnie dla Evigo.pl Piotr Karwatka z agencji Divante przedstawia 6 kroków do skutecznego przejęcia serwisu.

Zawsze gdy staje się przed trudnym zadaniem włącza się automatycznie „tryb ucieczki” oraz wyszukiwanie sposobu na jego ominięcie. Przejmowanie serwisu ma właśnie takie cechy. Pierwszą myślą po otrzymaniu takiego zadania jest „ Przepiszmy to od nowa!”.

Jakie są przyczyny przejęcia projektu od innej firmy?

Mogą być bardzo różne. Rozwój serwisu możemy chcieć zacząć prowadzić sami poprzez nasz dział IT lub zlecić innemu podwykonawcy. W pierwszym przypadku czynnikiem decydującym o przejęciu opieki może byś strategiczne znaczenie, chęć zapewnienia większego bezpieczeństwa technologii czy planowanie zmian na szeroką skalę. Jeśli projekt jest filarem naszego biznesu z pewnością lepiej jest zadbać o jego rozwój. Zmiana jednego wykonawcy na drugiego może być spowodowana zmianą profilu jego działalności (koniec współpracy z daną technologią), nieterminowością lub podejrzeniem o wykonywaniu prac niezgodnie ze sztuką (złej jakości kod).

6 kroków do przejęcia serwisu

1.       Prośba o dokumentację

Najlepiej rozpocząć działania od poproszenia o dokumentację, jeśli serwis takową posiada. Najlepiej poprosić o taką dotyczącą kodu, instalacji oraz projekt funkcjonalny.

Przy dalszym rozwoju serwisu dokumentacja może zostać stworzona. Idealna posiada poniżej wymienione cechy. Taki schemat warto również przyjąć, gdy tworzymy serwis od podstaw (np. wymagać jej stworzenia przed wykonawcę). Co ważne – dokumentacja nie musi być długa. Jeśli na etapie analitycznym (przedwdrożeniowym) była tworzona dokumentacja funkcjonalna, to jest już ona zalążkiem, wokół którego można zbudować dokumentację techniczną. Powinna w sobie zawierać:

  • opis architektury aplikacji — opis podziału na moduły, przeznaczenie modułów, ew. zależności,
  • opis działania algorytmów, które nie są trywialne — np. mechanizmy wyliczania cen (powinny być one dokładnie opisane),
  • opis procedury instalacji i uruchomienia systemu — także opis, co i kiedy powinno być „czyszczone” w bazie danych,
  • opis najważniejszych klas i warstw aplikacji — typowo programistyczny opis pozwalający szybciej znaleźć miejsce w kodzie,
  • opis struktury bazy danych — przy skomplikowanych relacyjnych bazach oprócz opisu tabel konieczne jest opisanie zależności (relacji),
  • opis radzenia sobie w sytuacjach problematycznych (Troubleshooting) — jeśli istnieją typowe sytuacje awaryjne i istnieją procedury na ich okoliczność, to dokumentacja powinna koniecznie zawierać ich szczegółowy opis,
  • opis innych czynności, które muszą być wykonywane, aby aplikacja działała.

2.       Audyt przed przejęciem aplikacji

Co sprawdzić w ramach audytu? Minimalny rozsądny zakres prac może obejmować:

  • Analizę logów serwera i logów systemu pod kątem występowania błędów. Jest to pobieżna diagnoza czym aktualnie występujące błędy w serwisie są spowodowane.
  • Przegląd kodów źródłowych i ocena ich czytelności, komentarzy, dokumentacji i dobrych praktyk.
  • Testy wydajnościowe, w tym te wykonywane przy pomocy narzędzia Siege oraz testy A/B.
  • Testy bezpieczeństwa narzędziami automatycznymi. Są zazwyczaj sprawdzane następujące podatności: XSS, SQL Injection, CSRF

Analiza powinna się zakończyć sporządzeniem krótkiego raportu, który zazwyczaj zawiera cenę, wnioski oraz sugerowane rozwiązania. Doświadczony programista powinien wyrobić się z tym zadaniem w ciągu 8 godzin.

3.       Pierwsze podejście do nowego projektu

Ważnym czynnikiem jest tutaj komunikacja. Przejmując rozwiązanie informatyczne, warto porozmawiać z użytkownikami/właścicielami o tym, co sprawia w systemie największe problemy. Musimy wiedzieć, czy nie ryzykujemy zbyt wiele, podejmując się samodzielnego rozwoju lub przejęcia serwisu od innego wykonawcy.

Podstawowe czynności związane z utrzymaniem aplikacji muszą zostać opanowane natychmiast. Uruchomienie, tworzenie kopii zapasowych, tworzenie kopii bazy danych oraz czynności związane z usuwaniem logów — to podstawa. Bez umiejętności realizacji tych zadań aplikacja może ulec awarii lub po prostu przestać działać

4.       Ocena jakości kodu, na jakim mamy pracować

Niezależnie od tego, czy posiadamy dokumentację, czy też nie, analiza kodu źródłowego będzie musiała zostać przez nas wykonana. Jeśli jest on napisany zgodnie ze standardami i używa wzorców projektowych to możemy uciszyć swoje obawy. Jeśli jednak kod, który otrzymaliśmy, to spaghetti kodu aplikacji, kodu widoków (znaczniki HTML i skrypty), a może nawet danych konfiguracyjnych to możliwe, że będzie sprawiał problemy. Taką metodą można rozpoznać każdą aplikację. Czasami jest to jednak dość czasochłonne. Ważne jednak, aby spisywać wnioski z analizy kodu, tworząc dokumentację.

Jak ocenić czy kod jest dobry? Można odpowiedzieć sobie na poniższe pytania:

  • Czy jest używana spójna konwencja kodowania? Czy nazwy klas, funkcji, metod i zmiennych są nazywane wg tego samego wzoru? W tym samym języku? Czy nazwy tłumaczą się same, czy może używane są jakieś magiczne stałe i dziwne skróty?
  • Czy używane są wzorce projektowe? Czy przyspieszają komunikację (tzn. czy występowanie danego wzorca samo tłumaczy działanie i strukturę fragmentu aplikacji)? Czy aplikacja korzysta ze sprawdzonych frameworków i bibliotek? Ich występowanie znacząco ułatwia rozwój. Znane frameworki nie tylko zwiększają stabilne działanie systemu, ale sprawiają, że nowi programiści będą mogli łatwiej wdrożyć się do pracy.
  • Czy w kodzie są komentarze do metod i klas opisujące ich przeznaczenie, działanie algorytmu oraz typy parametrów? Ma to szczególne znaczenie przy językach skryptowych (bez ścisłej typizacji). W takich językach bez odpowiedniego komentarza funkcje mogą być używane nieprawidłowo.
  • Czy istnieje pokrycie kodem testów jednostkowych? Takie testy świadczą o dużej staranności wykonania i są podstawą do wprowadzania dalszych zmian (dzięki nim błyskawicznie wykryjemy problemy).

5.       Wybór zespołu projektowego

Rozwojem nieznanego systemu powinien zajmować się zespół do zadań specjalnych. Działa on jak jednostka antyterrorystyczna. Szybko wkracza do akcji i opanowuje sytuację. Musimy mieć na uwadze, że pierwsze zadania związane z nowym projektem z dużym prawdopodobieństwem będą dotyczyły zgłoszeń błędów i konieczności wprowadzania poprawek. Najbardziej doświadczeni programiści szybko odnajdą się w nowej sytuacji, najszybciej z całego zespołu znajdą przyczyny i mogą zaproponować rozwiązanie błędów. To z nich powinna się składać nasza jednostka szybkiego reagowania.

6.       Dalsze działania

  • Testy jednostkowe

Korzystając z testów jednostkowych, możemy pracować w trybie: działa – nie działa –> poprawiam –> działa, ale tylko wtedy, jeśli wiemy, jakie dokładnie są skutki wprowadzonych zmian. Jeśli jednak nie znamy dokładnie systemu, wprowadzane przez nas modyfikacje mogą powodować reperkusje w częściach aplikacji, które nie są z nimi logicznie powiązane.

  • System kontroli wersji i śledzenie zmian

Zmiany, które będziemy wprowadzać, siłą rzeczy są obarczone sporym ryzykiem. Powinny być wersjonowane w osobnych branchach, co pozwoli na ich szybkie wycofywanie i publikowanie transakcyjne. Zmiany powinny być wprowadzane możliwie w małych ilościach, związanych z pojedynczymi zadaniami i fragmentami kodu. Dzięki takiemu podziałowi znacząco ułatwimy testy oraz zmniejszymy ilość zależnych modułów, które mogłyby ulec awarii w przypadku wystąpienia błędów.

  • Dziennik (log) projektu i dokumentacja

Log projektu to ważne narzędzie i warto je stosować wszędzie tam, gdzie rozwijamy oprogramowanie. Log jest wygodną formą dokumentowania prac. Zapisujemy w nim ważne obserwacje dotyczące kodu i przede wszystkim sposoby obejścia problemów, jakie pojawiły się w czasie prac. Nowe osoby nie będą musiały odkrywać koła na nowo, mogąc po prostu spojrzeć do loga. Ciężko przecenić wkład w rozwój wiedzy o projekcie, jaki niesie za sobą nawyk bieżącego dokumentowania najważniejszych zmian.

Piotr Karwatka jest wiceprezesem zarządu Divante. Dba o jakość rozwiązań oraz ich dopasowanie do potrzeb klientów. W branży internetowej od 2002 roku, pracował nad projektami dla firm takich jak Agora, TVN, Energa. Współtwórca pierwszego polskiego agregatora blogów Blogfrog.pl, a także ok. 30 komercyjnych aplikacji desktopowych. Absolwent informatyki na Politechnice Wrocławskiej.

Tagi:

Reklama

SCF 2017 Spring