41 lines
1.5 KiB
Markdown
41 lines
1.5 KiB
Markdown
# Workflow
|
||
|
||
## Sposób pracy
|
||
- Pisz do mnie po polsku, zwięźle i krótko, ale merytorycznie
|
||
|
||
## Zasady pisania kodu
|
||
- Kod ma być czytelny „dla obcego”: jasne nazwy, mało magii
|
||
- Brak „skrótów na szybko” typu logika w widokach, copy-paste, losowe helpery bez spójności
|
||
- Każda funkcja/klasa ma mieć jedną odpowiedzialność, zwykle do 30–50 linii (jeśli dłuższe – dzielić)
|
||
- max 3 poziomy zagnieżdżeń (if/foreach), reszta do osobnych metod
|
||
- Nazewnictwo:
|
||
- klasy: PascalCase
|
||
- metody/zmienne: camelCase
|
||
- stałe: UPPER_SNAKE_CASE
|
||
- Zero „skrótologii” w nazwach (np. $d, $tmp, $x1) poza pętlami 2–3 linijki
|
||
- medoo + prepared statements bez wyjątków (żadnego sklejania SQL stringiem)
|
||
- XSS: escape w widokach (np. helper e())
|
||
- CSRF dla formularzy, sensowna obsługa sesji
|
||
- Kod ma mieć komentarze tylko tam, gdzie wyjaśniają „dlaczego”, nie „co”
|
||
|
||
|
||
## Wprowadzanie zmian
|
||
- Przeanalizuj wprowadzone zadanie
|
||
- Jeżeli masz jakieś wątpliwości pytaj
|
||
- Przedstaw plan
|
||
- Po akceptacji wdróź plan
|
||
|
||
## KONIEC PRACY
|
||
|
||
Gdy użytkownik napisze `KONIEC PRACY`, wykonaj kolejno:
|
||
|
||
1. Przeprowadzenie testów.
|
||
2. Aktualizacja dokumentacji technicznej, jeśli zmiany tego wymagają:
|
||
- `docs/PROJECT_STRUCTURE.md`
|
||
- `docs/FORM_EDIT_SYSTEM.md`
|
||
3. Migracje SQL (jeśli były zmiany w bazie danych):
|
||
- Plik: `migrations/{version}.sql` (np. `migrations/0.304.sql`)
|
||
- **NIE** w `updates/` — build script sam wczyta z `migrations/`
|
||
- Sprawdź czy plik istnieje i jest poprawnie nazwany przed commitem
|
||
4. Commit.
|
||
5. Push. |