Viegls uzturēšanai
Izveidojiet programmatūru, ko nākotnes izstrādātāji var viegli saprast, modificēt un paplašināt
Skaidra projekta struktūra un modulāra arhitektūra
Mēs nodrošinām, ka mapju struktūra ir pirmais, ko nākotnes izstrādātājs novērtēs. Tiek izmantotas viedas, konsekventas mapju struktūras (piemēram, src/components, src/services, src/hooks, src/features).
Lasāmi, paredzami koda standarti
Mēs rakstām kodu cilvēkiem, ne tikai kompilatoram. Visos projektos tiek ievērotas konsekventas nosaukumu konvencijas un paraugi. ESLint un Prettier ir iestatīti, lai nodrošinātu formatēšanu, izmantojot pirmskomitēšanas skriptus, piemēram, Husky, nodrošinot koda kvalitāti no paša sākuma. Mēs dodam priekšroku tipizētām valodām, izmantojot TypeScript pār JavaScript labākai uzturēšanai. Mēs vienmēr saglabājam kodu lasāmu un pārvaldāmu, koncentrētu un mazu.
Kopīga dizaina sistēma / komponentu bibliotēka
Mēs izvairāmies no dizaina haosa, kodējot dizaina lēmumus atkārtoti izmantojamos koda komponentos. Tiek izmantoti izveidoti komponentu sistēmas, piemēram, ShadCN, Tailwind UI vai Material UI, lai nodrošinātu konsekvenci starp projektiem. Šī pieeja palīdz izvairīties no vienreizējas UI koda rakstīšanas, ja tas nav absolūti nepieciešams, ietaupot laiku un nodrošinot dizaina konsekvenci.
Iepakota biznesa loģika
Mēs nodrošinām, ka biznesa loģika nekad nepieder UI slānim. Pakalpojumu slāņi, pielāgotie hooks vai kontrolieru moduļi tiek izmantoti, lai pareizi izolētu un organizētu biznesa loģiku. API mijiedarbībai tiek ieviesti moderni datu iegūšanas modeļi, izmantojot SWR, React Query vai pielāgotus apvalkus, kas efektīvi apstrādā kešatmiņu un kļūdu stāvokļus. Visas API izsaukumi tiek abstrakti ievietoti veltītās pakalpojumu mapēs, piemēram, services/api/user.ts, padarot koda bāzi vieglāk uzturamu un testējamu.
Dokumentācija: Saglabājiet to vieglu, bet noderīgu
Mēs nerakstām romānus—tikai tik daudz, lai ātri iepazīstinātu nākamo izstrādātāju. README.md vienmēr ir rakstīts ar iestatījumu, vides mainīgajiem, izvietošanas instrukcijām. Īsi komentāri tiek pievienoti sarežģītai loģikai (nepārslogojiet ar komentāriem). TSDoc / JSDoc tiek izmantoti publiskām metodēm. Tiek pievienots CONTRIBUTING.md par to, kā veikt testus / konvencijas.
Testu pārklājums (kritiskie ceļi tikai)
Mums nav nepieciešams 100% pārklājums, bet mums ir nepieciešams pilnīgs pārklājums tur, kur neveiksme ir dārga. Vienību testi tiek prioritizēti biznesa kritiskām funkcijām. Integrācijas testi tiek izmantoti API galapunktiem vai darba plūsmām. Tiek izvēlēti viegli lietojami rīki: Jest + Testing Library (React), Playwright e2e testiem. Tādējādi mēs varam saglabāt līdzsvaru starp pārklājumu un laiku līdz tirgum.
CI/CD + Koda kvalitātes automatizācija
Katrs komits aktivizē drošības pārbaudes. Ir izveidota vienkārša CI/CD caurule, kas veic: tipa pārbaudes (piemēram, tsc --noEmit), Lint/formatēšanas pārbaudes, vienību testus, automātisku izvietošanu uz staging. Tiek izmantoti kopīgi rīki: GitHub Actions, Docker Compose.
Konfigurācijas atdalīšana no koda
Mēs izvairāmies no cieti kodēta jebko = ilgtermiņa sāpes. Visas slepenās informācijas/konfigurācijas tiek glabātas .env vai attālinātajā konfigurācijā (piemēram, AWS SSM, Vercel vides). Tiek izmantota vides balstīta iestatīšana (process.env.NODE_ENV). Tiek izvairīts no .env.*, API atslēgām, akreditācijas datiem utt. apņemšanās. Un tās ir labi dokumentētas.