Let at Vedligeholde

Vi sikrer, at mappestrukturen er det første, en fremtidig udvikler vil bedømme. Meningsfulde, konsistente mappestrukturer anvendes (f.eks. src/components, src/services, src/hooks, src/features).

Vi skriver kode til mennesker, ikke kun til compileren. Konsistente navngivningskonventioner og mønstre følges i alle projekter. ESLint og Prettier er sat op til at håndhæve formatering via pre-commit hooks som Husky, hvilket sikrer kodekvalitet fra starten. Vi prioriterer typede sprog, og bruger TypeScript frem for JavaScript for bedre vedligeholdelse. Vi holder altid koden læsbar og håndterbar, fokuseret og lille.

Vi undgår designkaos ved at kode designbeslutninger i genanvendelige kodekomponenter. Etablerede komponent systemer som ShadCN, Tailwind UI eller Material UI anvendes for at sikre konsistens på tværs af projekter. Denne tilgang hjælper med at undgå at skrive engangs UI-kode, medmindre det er absolut nødvendigt, hvilket sparer tid og sikrer designkonsistens.

Vi sikrer, at forretningslogik aldrig tilhører UI-laget. Servicelag, brugerdefinerede hooks eller controller-moduler bruges til korrekt at isolere og organisere forretningslogik. Til API-interaktioner implementeres moderne datahentningsmønstre ved hjælp af SWR, React Query eller brugerdefinerede wrappers, der effektivt håndterer caching og fejltillstande. Alle API-opkald er abstraheret i dedikerede service-mapper, såsom services/api/user.ts, hvilket gør kodebasen mere vedligeholdelsesvenlig og testbar.

Vi skriver ikke romaner—bare nok til hurtigt at onboarde den næste udvikler. README.md skrives altid med opsætning, miljøvariabler, deploymentsinstruktioner. Korte kommentarer tilføjes for kompleks logik (overkommenter ikke). TSDoc / JSDoc bruges til offentlige metoder. En CONTRIBUTING.md tilføjes for, hvordan man kører tests / konventioner.

Vi har ikke brug for 100% dækning, men vi har brug for fuld dækning, hvor fejl er dyre. Enhedstests prioriteres for forretningskritiske funktioner. Integrationstests bruges til API-endepunkter eller arbejdsgange. Let-at-bruge værktøjer vælges: Jest + Testing Library (React), Playwright til e2e. Så vi kan holde en balance mellem dækning og tid til markedet.

Hver commit udløser sikkerhedstjek. En simpel CI/CD-pipeline er oprettet, der gør: Type-tjek (f.eks. tsc --noEmit), Lint/format-tjek, Enhedstests, Auto-deploy til staging. Almindelige værktøjer bruges: GitHub Actions, Docker Compose.

Vi undgår hardcoded alt = langsigtet smerte. Alle hemmeligheder/konfigurationer opbevares i .env eller fjernkonfiguration (f.eks. AWS SSM, Vercel envs). Miljøbaseret opsætning anvendes (process.env.NODE_ENV). At commite .env.*, API-nøgler, legitimationsoplysninger osv. undgås. Og de er godt dokumenteret.