Poniżej przedstawiam luźny spis najlepszych praktyk które możesz wykorzystać podczas tworzenia oprogramowania wysokiej jakości.

Standardy

Jeśli chodzi o samo tworzenie kodu, warto stosować się do standardów typu PEP8 (link1, link2).

Nieocenionym do tego pomocnikiem, są narzędzia typu black, isort oraz flake8. Poniżej przedstawię krótki spis ich przykładowego użycia. Dla zainteresowanych polecam skorzystać z dokumentacji i pokopać głebiej.

1. Narzędzie black, umożliwia nam na bezkompromisowe sformatowanie pliku, z zachowaniem najlepszych praktyk.

black --line-length 72 --target-version py310 main.py

2. Narzędzie isort, służy do sortowania wszelkich importów innych modułów w naszym projekcie. 

isort --multi-line 3 --profile black --python-version 310 main.py

3. Narzędzie flake8, daje nam możliwość sprawdzenia naszego kodu, pod względem zgodniości z PEP8

flake8 --ignore=F841 --max-doc-length=72 main.py

Dokumentacja

Również polecam korzystać z standardów tworzenia dokumentacji typu np. Sphinx . Pomogą one wszystkim odnaleźć się w najbardziej zawiłym kodzie, oszczędzając dużo czasu potrzebnego np na poszukiwanie źródła rzucenia wyjątku przez aplikację.

Git

Tworzenie samych commit-ów, polecam opierać na Git Flow. Umożliwia nam to tworzenie hotfixów jak i feature, a sam git zajmuje się już odpowiednim ich przydzielaniem do gałęzi develop/master. Poniżej przedstawiam przykład tworzenia hotfixa:

git flow init
   • Dla tag polecam dodać przedrostek v
git flow hotfix start 2.2.1
git commit -a -m "fix(cli): allow argv to be overridden in bootstrap (#621)"                                     
git flow hotfix finish '2.2.1'
git push --tags
git push

Z kolei tworzenie samych opisów, bardzo ciekawie opisuje artykuł na highlab.pl/conventional-commits (poniżej mała ściągawka)

docs: add short circuit to hook example (#665)
fix(cli): allow argv to be overridden in bootstrap (#621)
tests(ED-439): add tests for Modal component
styles: format code with new prettier config

Jak i samą konwencję:

feat – nowa funkcjonalność
fix – poprawka do istniejącej funkcjonalności
docs – zmiany tylko w dokumentacji
chore – zmiany które nie mają wpływu z zawartość kodu źródłowego czy testów (np. aktualizacja paczek)
refactor – zmiany, które nie są zarówno poprawkami jak i nowymi funkcjonalnościami
tests – wszystko co związane z testami (dodawanie, edycja)
perf – zmiany w kodzie usprawniające wydajność,
styles – wszelkiego rodzaju formatorania kodu, białe znaki, przecinki czy brakujące średniki
ci – zmiany na potrzeby CI (konfigi, skrypty),
build – zmiany wpływające na proces builda,
revert – revert ostanich zmian

Na sam koniec mały bonus, jeśli nie wiesz na jakim branchu znajduje się dany commit wystarczy że wpiszesz: 

git branch --contains 020g9e1859752c0077a6dfca4e56732039d8eb010

Debugowanie

Odnośnie debugowania polecam zanajomić się z narzędziem PDB, które umożliwi nam uruchomienie interaktywnej konsoli w której możemy przedebugować aktualny kod. Wystarczy użyć:

import pdb; pdb.set_trace()

oraz po zakończeniu wpisać c aby ruszyć dalej. Dodatkowo można skorzystać z sewera wdb który umożliwi nam w przeglądarce www, skorzystanie z bardziej graficznej reprezentacji naszego debugowania.

import wdb; wdb.set_trace()

Wdrażanie

Dobre praktyki wskazują by samo wdrożenie na serwerze, czy też praca z na lokalnym środowisku, była przeprowadzana z użyciem virtualenv. Umożliwia nam to wygodne tworzenie środowisk per projekt, nie martwiąc się, że zależności i wersje danych pakietów, będą na siebie wzajemnie wpływać.

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

W przypadku wdrażania samego środowiska na serwer produkcyjny, dodatkowo zalecam by wszelkie zmiany wdrażać dedykowanego użytkownika. W studium przypadku użytkownik developer, który miałby możliwość zapisu do kodów samej aplikacji, a sama usługa apache używała już swojego dedykowanego użytkownika np www-data do uruchamiania web aplikacji. Pozwoli nam to znacząco zwiększyć bezpieczeństwo naszej aplikacji. Poniżej ściągawka dla aplikacji opartej na Django.

chown developer:www-data * -R
chmod 755 * -R
chmod 775 db.sqlite3
chmod 755 project/media/* -R
setfacl -d -m u::rwX,g::rwX,o::- project/media

Tryb developerski i bezpieczeństwo

Przed publikacją warto ustawić środowisko w trybie produkcyjnym, wyłączyć tryb debugowania oraz podpiąć pod nie usługę raportowania błędów na maila (polecam skorzystać z tego linku).

Samo bezpieczeństwo jest tak rozbudowanym tematem, że wymaga zupełnie oddzielnego omówienia. Choć na sam początek polecam zapoznać się z tym linkiem.

Baza danych

Oczywiście przed wdrożeniem produkcyjnie polecam zamienić sqlite3 na docelowy, dedykowany serwer mysql.

Pamiętajcie też Backupy, Backupy i jeszcze raz Backupy! Obowiązkowo codziennie oraz przed każdą aktualizacją/zmianą w kodach.

Podsumowanie

Sam temat jest bardzo szeroki, a artykuł miał za zadanie jedynie być mapą skarbów, a od Ciebie drogi czytelniku już zależy czy zaczniesz kopać głębiej, odkrywając fascynujące zakamarki tworzenia oprogramowania wysokiej jakości :)