Otwarta Kultura » Serwis digi_Kultura Cyfrowa

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