Postanowienia projektu WatchmanV2
Czym jest WatchmanV2
Jak nazwa wskazuje, to druga, odświeżona wersja projektu Watchman. W rozwoju projektu była przerwa trwająca ponad rok, w tym czasie zmieniły się częściowo plany dotyczące projektu - zarówno podejście do tworzenia oprogramowania jak i tego, jak powinien działać produkt końcowy.
1. Jasno określone konwencje pisania kodu
- Stosowanie się do powszechnie znanych dobrych praktyk, takich jak SOLID, DRY, KISS, YAGNI, GRASP itd
- Używanie
this
przy odwoływaniu się do elementów (pola, właściwości, metody) z obecnego obiektu - Używanie
this
zamiast_
do prywatnych pól - W przypadku możliwości zaoszczędzenia na wydajności zerowym kosztem, staramy się to robić, jeśli gdzieś możemy stworzyć mniej instancji a czytelność kodu się nie zmieni (lub będzie lepsza), powinniśmy to zrobić
2. Design nastawiony na łatwe pisanie testów i duże pokrycie w testach
- Używanie singletonów zamiast klas statycznych
- Używanie interfejsów do wstrzykiwania zależności, zależnościami nie powinny być klasy, jeśli jest to możliwe do wykonania
- Każdy test jednostkowy powinien testować tylko jedną metodę
- Klasy statyczne powinny służyć jedynie do wykonywania prostych funkcji, głównie extension methods
- Testy integracyjne służą do testowania interakcji między kilkoma klasami, granica "odkąd dokąd" testujemy powinna być zależna od konkretnego przypadku testowego
- Nazwy testów jednostkowych powinny zawierać nazwę metody która jest testowana, według wzoru
{Method}_{TestCase}
, przykładowoRenderProperty_ShouldContainTypeName()
- Pull requesty powinny zawierać testy do kodu, który został poprawiony/dodany
- W przypadku znalezienia błędu, powinny zostać dodane testy, gwarantujące że ten konkretny problem więcej się nie powtórzy
- Nazwy klas zawierających testy jednostkowe, powinny odpowiadać klasom testowanym i powinny mieć suffix "Tests", przykładowo dla
UsersService
powinna być klasaUsersServiceTests
3. Korzystanie z issues na githubie do wystawiania prostych zadań
Teraz osoby z zewnątrz miały trudniejszy proces dołączania do projektu, bo każdy musiał być dodany do trello i discorda, a wszystkiego wymagała prywatna komunikacja - to było dość duże utrudnienie i myśle, że istotny czynnik zniechęcający do pomocy przy projekcie. Dużo prościej by było, gdyby część zadań (te które może robić nawet ktoś, kto nie zna bardzo dobrze projektu), było przeniesionych na issues na githubie.
4. Obsługa klienta
Bot powinien zawierać możliwość obsługi prywatnych wiadomości, w których użytkownicy mogliby (poza używaniem standardowych komend) zgłaszać problemy i propozycje. Bot powinien mieć możliwość odpowiadania użytkownikom (wiadomości pisane przez osoby z zespołu Watchmana).