Przejęcie, migracja, aktualizacja projektu IT

1. Materiały do pobrania: http://goo.gl/Moln9o
Jak przejąć i dalej rozwijać projekt?
Przejęcie dalszego rozwoju projektu IT zawsze budzi emocje.
Pierwsza myśl to zazwyczaj „przepiszmy to od nowa”.
Piotr Karwatka, Grupa Divante

2. Materiały do pobrania: http://goo.gl/Moln9o
Kiedy przejmujemy projekt?
Przejęcie rozwoju projektu może następować z różnych przyczyn –
wcale nie negatywnych.
Najczęściej:
-w projekcie jest tyle zmian i potrzeby rozwoju są tak duże, że zewn.
firma nie jest opłacalna,
-projekt jest dla nas strategicznie kluczowy i zależy nam na
bezpieczeństwie technologii,
-wykonawca upada / kończy z daną technologią,
-problemy wydajnościowe, bezpieczeństwa,
-podejrzenie niezgodności ze sztuką (kiepski kod)
-wykonawca nie może zakończyć wdrożenia.
Najlepiej:
-zacząć od poproszenia o dokumentację
-następnie wykonać krótki

3. Materiały do pobrania: http://goo.gl/Moln9o
Co sprawdzić w ramach audytu?
Minimalny rozsądny zakres prac:
-Analiza logów serwera i logów systemu pod kątem występowania błędów.
Pobieżna diagnoza czym błędy są spowodowane
-Przegląd kodów źródłowych i ocena ich czytelności, komentarzy,
dokumentacji i dobrych praktyk
-Testy wydajnościowe narzędziem Siege, AB
-Testy bezpieczeństwa narzędziami automatycznymi. Następujące podatności
będą sprawdzone: XSS, SQL Injection, CSRF
-Sporządzenie krótkiego opisu/raportu. Ocena, wnioski, sugerowane
rozwiązania – 8 godzin roboczych
Jaka dokumentacja?
-dokumentacja kodu,
-dokumentacja instalacji,
-projekt funkcjonalny.

4. Materiały do pobrania: http://goo.gl/Moln9o
Dokumentacja i szkolenia
•
Dokumentacja nie musi być szczególnie 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ą.
•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.

5. Materiały do pobrania: http://goo.gl/Moln9o
Wywiad i poznanie systemu
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.
Uruchomienie i podstawowe czynności
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ć.
Analiza kodu źródłowego
Niezależnie od tego, czy posiadamy dokumentację, czy nie, analiza kodu źródłowego
pewnie prędzej czy później będzie konieczna. Jeśli kod jest napisany zgodnie ze
standardami i używa wzorców projektowych, to pół biedy. Gorzej, jeśli kod, który
otrzymaliśmy, to spaghetti kodu aplikacji, kodu widoków (znaczniki HTML i skrypty), a
może nawet danych konfiguracyjnych.
Taką metodą można rozpoznać każdą aplikację. Czasami jest to jednak dość
czasochłonne. Ważne, aby spisywać wnioski z analizy kodu, tworząc dokumentację.

6. Materiały do pobrania: http://goo.gl/Moln9o
Czy kod jest dobry?
•
•
•
•
•
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).

7. Materiały do pobrania: http://goo.gl/Moln9o
Zespół do zadań specjalnych
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.
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.

8. Materiały do pobrania: http://goo.gl/Moln9o
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.

9. Materiały do pobrania: http://goo.gl/Moln9o
Dziękuję za uwagę!
W razie pytań?
Piotr Karwatka – pkarwatka@divante.pl

10. Materiały do pobrania: http://goo.gl/Moln9o
Dziękuję za uwagę!
W razie pytań?
Piotr Karwatka – pkarwatka@divante.pl