Łatwe w utrzymaniu
Twórz oprogramowanie, które przyszli deweloperzy mogą łatwo zrozumieć, modyfikować i rozszerzać
Przejrzysta struktura projektu i modularna architektura
Zapewniamy, że struktura folderów jest pierwszą rzeczą, którą oceni przyszły deweloper. Używane są opiniotwórcze, spójne struktury folderów (np. src/components, src/services, src/hooks, src/features).
Czytelne, przewidywalne standardy kodu
Pisujemy kod dla ludzi, a nie tylko dla kompilatora. Spójne konwencje nazewnictwa i wzorce są stosowane we wszystkich projektach. ESLint i Prettier są skonfigurowane, aby wymuszać formatowanie za pomocą hooków pre-commit, takich jak Husky, zapewniając jakość kodu od samego początku. Priorytetowo traktujemy języki typowane, używając TypeScript zamiast JavaScript dla lepszej utrzymywalności. Zawsze utrzymujemy kod czytelny i zarządzalny, skupiony i mały.
Wspólny system projektowania / biblioteka komponentów
Unikamy chaosu projektowego, kodując decyzje projektowe w wielokrotnego użytku komponentach kodu. Używane są ustalone systemy komponentów, takie jak ShadCN, Tailwind UI lub Material UI, aby zapewnić spójność w projektach. Takie podejście pomaga uniknąć pisania jednorazowego kodu UI, chyba że jest to absolutnie konieczne, oszczędzając czas i zapewniając spójność projektu.
Zamknięta logika biznesowa
Zapewniamy, że logika biznesowa nigdy nie należy do warstwy UI. Warstwy serwisowe, niestandardowe hooki lub moduły kontrolerów są używane do odpowiedniego izolowania i organizowania logiki biznesowej. Do interakcji z API wdrażane są nowoczesne wzorce pobierania danych przy użyciu SWR, React Query lub niestandardowych wrapperów, które efektywnie obsługują pamięć podręczną i stany błędów. Wszystkie wywołania API są abstrakcyjne w dedykowanych folderach serwisowych, takich jak services/api/user.ts, co sprawia, że baza kodu jest bardziej zdatna do utrzymania i testowania.
Dokumentacja: Utrzymuj ją lekką, ale użyteczną
Nie piszemy powieści—tylko tyle, aby szybko wprowadzić następnego dewelopera. README.md zawsze zawiera informacje o konfiguracji, zmiennych środowiskowych, instrukcjach wdrożenia. Krótkie komentarze są dodawane do złożonej logiki (nie przesadzaj z komentarzami). TSDoc / JSDoc są używane dla publicznych metod. Dodawany jest plik CONTRIBUTING.md z instrukcjami, jak uruchomić testy / konwencje.
Pokrycie testami (tylko krytyczne ścieżki)
Nie potrzebujemy 100% pokrycia, ale potrzebujemy pełnego pokrycia tam, gdzie awaria jest kosztowna. Testy jednostkowe są priorytetowe dla funkcji krytycznych dla biznesu. Testy integracyjne są używane dla punktów końcowych API lub przepływów pracy. Wybierane są łatwe w użyciu narzędzia: Jest + Testing Library (React), Playwright do testów e2e. Dzięki temu możemy utrzymać równowagę między pokryciem a czasem wprowadzenia na rynek.
CI/CD + Automatyzacja jakości kodu
Każde zatwierdzenie wyzwala kontrole bezpieczeństwa. Ustawiony jest prosty pipeline CI/CD, który wykonuje: kontrole typów (np. tsc --noEmit), kontrole lint/format, testy jednostkowe, automatyczne wdrożenie na staging. Używane są powszechne narzędzia: GitHub Actions, Docker Compose.
Separacja konfiguracji od kodu
Unikamy hardcodowania czegokolwiek = długoterminowy ból. Wszystkie sekrety/konfiguracje są przechowywane w .env lub zdalnej konfiguracji (np. AWS SSM, zmienne Vercel). Używane jest ustawienie oparte na środowisku (process.env.NODE_ENV). Unika się zatwierdzania .env.*, kluczy API, poświadczeń itp. I są one dobrze udokumentowane.