Szczegóły współpracy¶

W dniu 3 stycznia 2017 22:57 użytkownik Radek Czajka <rczajka@rczajka.pl> napisał:

W dniu 03.01.2017 o 17:06, Agnieszka Salamonczyk pisze:

> Twoje wsparcie przydałoby się na następujących odcinkach:
    > - weryfikowanie kodu (najlepiej etapami), który dostarczą developerzy
    > (kwestia kontaktu z nimi do dogadania, ale pracujemy na githubie, więc
    > wgląd w kod nie powinien być skomplikowany)

Jasne.
    Czy te etapy są jakoś zdefiniowane?

Jesteśmy w trakcie definiowania

Jeśli nie, to czy macie spisane konkretne wymagania, które można by
    potraktować jako punkt wyjścia do określenia tych etapów?

Wstępne ustalenia były mailowe, teraz powstaje dokładniejsza specyfikacja. Przesyłam w załączniku - możesz spojrzeć i zasugerować, co jeszcze powinnam ustalić?
Nie rozpisywałam scenariuszy na kroki, ale to do nadrobienia. Do ustalenia części funkcjonalności potrzebuję współpracy ze strony MHPu (oni znają zasoby, wiedzą, co jest w nich interesującego i jak można z nich w przyszłości korzystać) - czekam na informacje od nich.

Jeśli nie, to możemy przyjąć dwutygodniowy cykl przeglądów i ew.
    dostosować go do intensywności prac (ale jeśli nie macie wymagań, to
    warto się zastanowić, skąd programista wie, co ma zrobić).

Dwutygodniowy cykle jest dla mnie ok. Ustalam jeszcze z programistami harmonogram prac, żeby zsynchronizować to ze współpracą z MHP.

> - testy

Wyobrażam sobie następujące rodzaje testów i moją w nich rolę, popraw
    mnie jeśli gdzieś rozmijam się z Waszymi wymaganiami:

Testy jednostkowe - testy sprawdzające działanie poszczególnych kawałków
    kodu.  Zasadniczo powinny być napisane przez programistę i funkcjonować
    jako część kodu źródłowego.  Kod aplikacji "starodruki" nie zawiera
    niestety żadnych testów, co jest poważną słabością, bo znacznie lepiej
    dodaje się takie testy na etapie pisania danego fragmentu kodu, kiedy
    programista potrafi najlepiej określić, do czego dokładnie dany fragment
    służy, niż post factum.  Należałoby więc oczekiwać, że testy jednostkowe
    pojawią się przynajmniej dla tych fragmentów (klas, funkcji), które
    programista będzie teraz zmieniał.

Rozumiem, że potrzeba stworzyć dodatkowy kod, zgadza się? Czy powinnam to uwzględnić w specyfikacji?

Moja rola może polegać na weryfikacji prawidłowego działania testów i
    pokrycia nimi relewantnego kodu, ew. propozycji uzupełnienia testów o
    zapomniane przypadki brzegowe.

To będzie ok.

Testy funkcjonalne - testy badające zgodność aplikacji ze specyfikacją.
    Żeby móc je sformułować, trzeba więc najpierw mieć tę specyfikację.

Brzmi to jak formalistyczna upierdliwość, ale w rzeczywistości jasne
    określenie planowanego działania aplikacji jest ułatwieniem dla
    wszystkich.  Jeśli więc specyfikacji nie ma, to należy ją napisać, np. w
    postaci zestawu opisanych krok po kroku przypadków użycia (co kolejno
    należy zrobić, żeby wstawić nowy obiekt, sposób nawigacji między
    obiektami, itp.).  W ten sposób określone wymagania można potem
    sformalizować jako automatycznie wykonywane testy.
    Moja rola zależy tutaj od tego, jak dużo już wiecie o swoim projekcie i
    swoich wymaganiach wobec niego.

Specyfikacja powstaje. Wiemy już coraz więcej, ale kilka szczegółów wymaga jeszcze doprecyzowania.
Bardzo mi pomożesz, jeśli spojrzysz na specyfikację i zasugerujesz, co jeszcze powinnam uzgodnić, także pod katem przyszłych testów. Potem jak rozumiem możemy wrócić do doprecyzowania Twojej roli.

Testy użyteczności - to są testy, które trzeba przeprowadzać ręcznie, i
    najbardziej przydatne są do tego jakieś osoby, które nie są bezpośrednio
    zaangażowane w projekt (mogą to być np. inni pracownicy organizacji),
    którym daje się zadanie wykonania pewnych czynności w serwisie.  Moja
    rola mogłaby tu polegać na pomocy w przygotowaniu scenariusza takich testów.

Jasne, będziemy testować w naszym gronie, chciałabym tez zaangażować pracowników MHP.
Scenariusz będzie pomocny.

Testy wydajnościowe – warto je przeprowadzić w bardzo podstawowym
    zakresie – tj. zaprojektować prosty test polegający na załadowaniu
    aplikacji planowaną na dziś docelową ilością danych i zmierzeniu czasu
    generowania poszczególnych widoków dla sprawdzenia, czy nie pojawiają
    się wtedy problematyczne wąskie gardła.  Mogę pomóc w przygotowaniu
    takiego testu.

Zgadzam się.

Tu pojawia się temat migracji danych do serwisu, która jeszcze nie jest zaplanowana. Będę ustalać, kto się tym zajmie.

Testy dokumentacji, w szczególności dokumentacji wdrożeniowej – czyli
    ręczne sprawdzenie, czy procedury opisane w dokumentacji rzeczywiście
    działają.
    To jest coś, co po prostu trzeba ręcznie zrobić, i mogę to wziąć na siebie.

Dzięki, to będzie ok.

Przy okazji chciałabym z Tobą skonsultować wytyczne do dokumentacji. Na ten moment chcemy, żeby znalazły się w niej:
- API - kwestie synchronizacji

Rozumiem, że chodzi o synchronizację jako klient jakiegoś zewnętrznego
API. Zakładam, że to zewnętrzne API powinno mieć swoją dokumentację i
wytyczne na temat synchronizacji. Dokumentacja po Waszej stronie
powinna zawierać tylko informację, w jakim trybie się synchronizujecie
(np. proponowany wpis do crontabu). W gruncie rzeczy jest to część
dokumentacji wdrożeniowej (niżej).

- zarządzanie hasłami

Zakładam, że używamy systemu użytkowników wbudowanego w Django, w tej
sytuacji zarządzanie hasłami to kwestia konfiguracji opisanej tutaj:
https://docs.djangoproject.com/en/1.10/topics/auth/passwords/

Nie jestem pewny, czy wymaga to dodatkowej dokumentacji. Możecie ew.
chcieć stworzyć procedurę rotacji haseł (np. że każdy ma obowiązek
zmiany swoich haseł co najmniej raz na rok), ale ja bym to widział
badziej na poziomie organizacji, a nie dokumentacji tego konkretnego
projektu.

- parametry serwera, żeby wytrzymać bazę danych

Dokumentacja powinna przede wszystkim (i to jest najważniejsza sprawa)
zawierać opis procedury wdrożenia („czystego” wdrożenia i aktualizacji)
ze wszystkimi potrzebnymi zależnościami (przy czym Pythonowe zależności
mogą być np. w formie pliku requirements.txt). To jest coś, czego
zdecydowanie brakuje. Dokumentacja powinna odpowiadać na pytania:

• jak to uruchomić? (coś w rodzaju: „na serwerze zainstaluj X, Y, Z w
  wersjach x, y, z, uruchom komendy A, B, C, skonfiguruj P, Q, R, a potem
  uruchom zgodnie z dokumentacją Django”);
• jak to zaktualizować? (idealnie do kodu powinien być dołączony skrypt
  wdrożeniowy, korzystający np. z Fabric, robiący wszystko co trzeba po
  wywołaniu jednej komendy);

Jeśli są jakieś szczególne wymagania wobec serwera, to powinny też się
tu znaleźć, ale nie spodziewałbym się tu niczego szczególnego – serwis
jest na tyle prosty, że ruszy „na wszystkim”, a wąskim gardłem będzie
rozmiar samych skanów.

Czego jeszcze powinnam oczekiwać?

Nie jest dla mnie jasne, czym w specyfikacji jest „administrowanie
serwisem”. Strzelam, że chodzi o możliwość edycji stron statycznych i
listy sponsorów – jeśli tak, wszystkie te rzeczy powinny być wypisane
wprost. Generalnie, każdy element serwisu, w którym chcecie mieć
możliwość coś zmieniać, dodawać albo usuwać z poziomu panelu
administracyjnego, powinien być wskazany wprost.

Osobnym tematem będzie dokumentacja skryptu migracji.