Materiały do pobrania: http://goo.gl/Moln9o

Piotr Karwatka, Grupa Divante

Jak przejąć i dalej rozwijać projekt?

Przejęcie dalszego rozwoju projektu IT zawsze budzi emocje.Pierwsza myśl to zazwyczaj „przepiszmy to od nowa”.

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

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.

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.

Materiały do pobrania: http://goo.gl/Moln9o

Wywiad i poznanie systemuPrzejmują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ściPodstawowe 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łowegoNiezależ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ę.

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).

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 jednostkoweKorzystają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.

Materiały do pobrania: http://goo.gl/Moln9o

System kontroli wersji i śledzenie zmianZmiany, 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 dokumentacjaLog 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.

Materiały do pobrania: http://goo.gl/Moln9o

Dziękuję za uwagę!

W razie pytań?Piotr Karwatka – pkarwatka@divante.pl