Repozytorium projektu:
Kod źródłowy i TDD
W ramach projektu staramy się tworzyć czysty i przejrzysty kod – chociaż nie zawsze jest to takie proste i oczywiście rzeczywistość bywa różna 😉
Wskazówki dotyczące kodu aplikacji:
– Nazwy klas, metod, zmiennych powinny być przejrzyste i możliwie jednoznacznie określać czym dana metoda, zmienna jest, jaką ma odpowiedzialność
– Staramy się unikać komentarzy w kodzie – jeżeli komentarz lepiej wyjaśnia co robi metoda niż jej nazwa to najpewniej coś jest nie tak z nazwą metody
– Wyjątkiem od powyższego jest komentarz nagłówkowy – zawierający informacje licencyjne – stosujemy go w każdym pliku
– Stosujemy konwencje pochodzącą z języka, w którym piszemy
– Staramy się zaprojektować rozwiązanie zgodnie z dobrymi praktykami obiektowymi (np. SOLID) ograniczając niepotrzebne zależności oraz jawnie i dokładnie specyfikując odpowiedzialność
– Kod najczęściej jest czytany, więc powinien być łatwy do przeczytania i zrozumienia
– Staramy stosować się spójne konwencje i nazewnictwo
– Kod powinien być możliwy do przetestowania za pomocą testów automatycznych (testowalny)
– Należy unikać zaszywania konfiguracji, stałych znakowych w kodzie
– Stosujemy wyłącznie anglojęzyczne nazwy
– Jeżeli czegoś nie da się zrobić „ładnie”, najpewniej jest jakiś problem z architekturą
Powyższe wskazówki, to tylko wstępne, ogólne sugestie. Jeżeli macie jakieś pomysły, własne doświadczenia – zachęcamy do przedstawienia ich na forum projektu 🙂
Więcej informacji o czystym i przejrzystym kodzie można znaleźć np. w książce: Clean Code, Robert C. Martin (Uncle Bob)
W pracach implementacyjnych staramy się również kierować metodologią TDD, która proponuje implementacje testu jednostkowego, przed implementacją testowanej funkcjonalności. Testy automatyczne pozwalają podnieść jakość aplikacji i zmniejszyć poziom stresu związany z modyfikacjami dokonywanymi na istniejącym już kodzie (potwierdzenie, że wszystko nadal działa). Implementacja testów przed kodem funkcjonalności gwarantuje, że testy automatyczne będą istnieć oraz pomaga przyjąć lepsze podejście przy projektowaniu pisanego rozwiązania. Więcej informacji o TDD można znaleźć np. w książce: TDD. Sztuka tworzenia dobrego kodu, Kent Beck
Git-flow
W projekcie realizujemy podejście git-flow, które zakłada pracę z wykorzystaniem branchy: master, develop, release, feature i hotfix. Po implementacji issue należy zgłosić pull requesta, na podstawie którego inna osoba dokona przeglądu i przyłączy zmiany do głównej gałęzi. Więcej informacji o podejściu git-flow można znaleźć np. na stronie: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
Jeżeli masz doświadczenia lub przemyślenia związane z innymi podejściami (np. github-flow, gitlab-flow) – zachęcamy do podzielenia się nimi na forum projektu.
Issue tracker
Jako issue tracker obecnie wykorzystujemy zakładkę Issues na githubie. Do opisu zadań stosujemy wzorzec:
# **ENG**:
### **Actual**:
TODO
### **Expected**:
TODO
# **PL:**
### **Stan obecny:**
TODO
### **Stan oczekiwany:**.
TODO
Nazwy issue nadajemy w języku angielskim.
Standard dokumentów
Dokumenty, modele umieszczamy w otwartych formatach (np. odt, xcf) i staramy się zawsze dostarczyć wersję źródłową.
Podsumowanie
Wszystkie opisane pomysły i konwencje są pewnego rodzaju punktem wyjścia i propozycją. Jeżeli masz jakieś pomysły, uwagi – napisz o nich na forum. Chcemy by nasz projekt dojrzewał zarówno od strony funkcjonalnej jak i technologiczno-organizacyjnej 🙂