Czas nakreślić nieco bardziej szczegółowe ramy projektu AUDITOR – w formie specyfikacji lub też definicji wymagań. Jeżeli jeszcze nie wiesz czym jest projekt oraz jaki problem ma potencjalnie rozwiązać, to zapraszam Cię do pierwszego postu z serii: Daj się poznać 2017 [Adrian].
Jest specyfikacja?
Nie ma specyfikacji, a przynajmniej w takiej formie jakiej zazwyczaj wymagają programiści. Będą jedynie z grubsza zdefiniowane wymagania funkcjonalne oraz trochę naciągnięte niefunkcjonalne. Nie chcę zamykać się w raz przyjętych założeniach – one nakreślą początkową wizję. Reszta (bardziej doprecyzowana) mam nadziej wyklaruje się w sposób naturalny. Niech się dzieje – Agile … 🙂
Wymagania funkcjonalne
„Wymagania funkcjonalne opisują funkcjonalność, którą system ma realizować”
via wikipedia.org
- Zarządzanie audytowanymi projektami
- Lista projektów składająca się z: nazwy projektu, postępu (np: zaudytowano 87% kodu, poświęcono 14h 39m)
- Użytkownik posiada możliwość dodawania nowego projektu
- Po utworzeniu projektu, można wgrać paczkę zip wraz z kodem źródłowym, który zostanie przypisany do projektu
- Podgląd kodu źródłowego dla wybranego projektu
- Wyświetlenie struktury katalogowej w sposób ułatwiający poruszanie się pomiędzy poszczególnymi plikami z kodem źródłowym
- Szybkie wyszukiwanie konkretnego katalogu oraz pliku
- Kolorowanie składni kodu źródłowego podczas przeglądania zawartości pliku
- Możliwość komentowania jednej lub kilku zaznaczonych linii w kodzie źródłowym (od – do)
- Informacja o ilości zgłoszonych uwag w danym pliku oraz sumarycznie dla każdego węzła katalogów
- Logowanie czasu spędzonego na przeglądaniu kodu źródłowego, liczone dla każdego pliku z osobna
- Generowanie raportu na podstawie zgłoszonych komentarzy
- Raport zostanie wygenerowany w postaci pliku PDF
- Zawierać będzie informacje na temat: nazwy projektu, czasu poświęconego na audyt, procent zaudytowanego kodu
- Każdy fragment kodu źródłowego który został opatrzony komentarzem zostanie zaprezentowany w raporcie wraz z komentarzem
Wymagania niefunkcjonalne
O tym czym są wymagania niefunkcjonalne możesz przeczytać w artykule na stronie Analiza Wymagań.
- Wsparcie dla najnowszych wersji przeglądarek Chrome, Firefox.
- Testy automatyczne (na zróżnicowanym poziomie, uwzględniając piramidę testów) dla najważniejszych elementów aplikacji.
- Wykorzystanie Travis CI do uruchomienia testów automatycznych po każdym dostarczeniu kodu do repozytorium.
- Proste do uruchomienia środowisko developerskie.
- Zastosowanie PHP w wersji 7.1 oraz HTML5 i standardu ECMAScript 6 po stronie interfejsu użytkownika.
Milestones
- Konfiguracja projektu oraz CI, struktura kodu.
- Zarządzanie i wyświetlanie listy audytowanych projektów.
- Prezentowanie struktury projektu, wraz z podglądem kodu źródłowego.
- Możliwość przeprowadzenia audytu kodu wraz z zliczaniem czasu poświęconego na jego wykonanie.
- Generowanie raportu z przeprowadzonego audytu.
Stack technologiczny
W tej kwestii będę nieco monotonny, nudny i przygnębiający. Nie będzie Reacta. Nie i chuj. Po prostu, przy tym projekcie pominę hype na niego. Chcę dostarczyć działający, w miarę ustrukturyzowany i ogarnięty kawałek oprogramowania. Reacta najzwyczajniej nie znam, a jego nieznajomość mogłaby spowolnić tempo prac.
Backend zostanie zasilany przez PHP + Symfony3, przewinie się też kilka popularnych bibliotek. Dane wylądują prawdopodobnie w MongoDB. UI napędzi stary, poczciwy AngularJS. To w sumie tyle z podstawowego stacka. Po drodze na pewno zahaczę o parę popularnych słów kluczowych – jednak o tym później.
Dlaczego? Primo – dawno nic nie pisałem w języku PHP. Aktualnie realizuję projekty wykorzystując inne technologie. Secundo – w tym PHPie też się da zakodzić coś z głową! Postaram się to chociaż po części udowodnić 🙂