Enkelt å vedlikeholde
Bygg programvare som fremtidige utviklere enkelt kan forstå, modifisere og utvide
Klar prosjektstruktur og modulær arkitektur
Vi sørger for at mappestrukturen er det første en fremtidig utvikler vil vurdere. Meningsfulle, konsistente mappestrukturer brukes (f.eks. src/components, src/services, src/hooks, src/features).
Lesbare, forutsigbare kode-standarder
Vi skriver kode for mennesker, ikke bare for kompilatoren. Konsistente navnekonvensjoner og mønstre følges gjennom alle prosjekter. ESLint og Prettier er satt opp for å håndheve formatering via pre-commit hooks som Husky, noe som sikrer kodekvalitet fra starten av. Vi prioriterer typede språk, og bruker TypeScript fremfor JavaScript for bedre vedlikeholdbarhet. Vi holder alltid koden lesbar og håndterbar, fokusert og liten.
Delt design-system / komponentbibliotek
Vi unngår designkaos ved å kode designbeslutninger i gjenbrukbare kodekomponenter. Etablerte komponent-systemer som ShadCN, Tailwind UI eller Material UI brukes for å sikre konsistens på tvers av prosjekter. Denne tilnærmingen hjelper til med å unngå å skrive engangs UI-kode med mindre det er absolutt nødvendig, noe som sparer tid og sikrer designkonsistens.
Kapslet forretningslogikk
Vi sørger for at forretningslogikk aldri tilhører UI-laget. Tjenestelag, tilpassede hooks eller kontrollermoduler brukes for å isolere og organisere forretningslogikk på riktig måte. For API-interaksjoner implementeres moderne datainnhentingsmønstre ved hjelp av SWR, React Query eller tilpassede innpakninger som håndterer caching og feilstater effektivt. Alle API-anrop er abstraktert i dedikerte tjenestemapper, som services/api/user.ts, noe som gjør kodebasen mer vedlikeholdbar og testbar.
Dokumentasjon: Hold den lettvektig, men nyttig
Vi skriver ikke romaner—bare nok til å onboarde den neste utvikleren raskt. README.md er alltid skrevet med oppsett, miljøvariabler, distribusjonsinstruksjoner. Korte kommentarer legges til for kompleks logikk (ikke overkommenter). TSDoc / JSDoc brukes for offentlige metoder. En CONTRIBUTING.md legges til for hvordan man kjører tester / konvensjoner.
Testdekning (Kritiske stier kun)
Vi trenger ikke 100% dekning, men vi trenger komplett dekning der feil er kostbare. Enhetstester prioriteres for forretningskritiske funksjoner. Integrasjonstester brukes for API-endepunkter eller arbeidsflyter. Enkle verktøy velges: Jest + Testing Library (React), Playwright for e2e. Så vi kan opprettholde en balanse mellom dekning og tid til markedet.
CI/CD + Kodekvalitetsautomatisering
Hver commit utløser sikkerhetskontroller. En enkel CI/CD-pipeline er satt opp som gjør: Typekontroller (f.eks., tsc --noEmit), Lint/formatkontroller, Enhetstester, Auto-deploy til staging. Vanlige verktøy brukes: GitHub Actions, Docker Compose.
Separasjon av konfigurasjon fra kode
Vi unngår hardkodede elementer = langvarig smerte. Alle hemmeligheter/konfigurasjoner lagres i .env eller fjernkonfigurasjon (f.eks., AWS SSM, Vercel envs). Miljøbasert oppsett brukes (process.env.NODE_ENV). Å commite .env.*, API-nøkler, legitimasjon osv. unngås. Og de er godt dokumentert.