Helppo ylläpitää

Varmistamme, että kansiorakenne on ensimmäinen asia, jota tuleva kehittäjä arvioi. Käytämme mielipiteen mukaan johdonmukaisia kansiorakenteita (esim. src/components, src/services, src/hooks, src/features).

Kirjoitamme koodia ihmisille, emme vain kääntäjälle. Johdonmukaisia nimeämiskäytäntöjä ja malleja noudatetaan kaikissa projekteissa. ESLint ja Prettier on asetettu pakottamaan muotoilua esikommiteeraushakujen, kuten Husky, kautta, varmistaen koodin laadun alusta alkaen. Priorisoimme tyypitettyjä kieliä, käyttäen TypeScriptiä JavaScriptin sijaan paremman ylläpidettävyyden vuoksi. Pidämme aina koodin luettavana ja hallittavana, keskittyneenä ja pienenä.

Vältämme suunnittelukaosta koodipohjaisten päätösten koodaamisella uudelleenkäytettävissä komponentteissa. Vakiintuneita komponenttijärjestelmiä, kuten ShadCN, Tailwind UI tai Material UI, käytetään varmistamaan johdonmukaisuus projektien välillä. Tämä lähestymistapa auttaa välttämään kertakäyttöisen käyttöliittymäkoodin kirjoittamista, ellei se ole ehdottoman välttämätöntä, säästäen aikaa ja varmistaen suunnittelun johdonmukaisuuden.

Varmistamme, että liiketoimintalogiikka ei koskaan kuulu UI-kerrokseen. Palvelukerrokset, mukautetut hookit tai ohjausmoduulit käytetään liiketoimintalogiikan asianmukaiseen eristämiseen ja järjestämiseen. API-vuorovaikutuksille käytetään moderneja tietojen hakumalleja, kuten SWR, React Query tai mukautetut wrapperit, jotka käsittelevät välimuistia ja virhetiloja tehokkaasti. Kaikki API-kutsut on abstrahoitu omiin palvelukansioihinsa, kuten services/api/user.ts, mikä tekee koodipohjasta helpommin ylläpidettävän ja testattavan.

Emme kirjoita romaaneja—vain tarpeeksi, jotta seuraava kehittäjä pääsee nopeasti alkuun. README.md on aina kirjoitettu asennusta, ympäristömuuttujia ja käyttöönotto-ohjeita varten. Lyhyitä kommentteja lisätään monimutkaiselle logiikalle (älä kommentoi liikaa). TSDoc / JSDoc käytetään julkisille metodeille. CONTRIBUTING.md lisätään testien suorittamisesta / käytännöistä.

Emme tarvitse 100% kattavuutta, mutta tarvitsemme täydellistä kattavuutta, missä epäonnistuminen on kallista. Yksikkötestit priorisoidaan liiketoimintakriittisille toiminnoille. Integraatiotestejä käytetään API-pisteille tai työnkuluille. Helppokäyttöisiä työkaluja valitaan: Jest + Testing Library (React), Playwright e2e:lle. Näin voimme pitää tasapainon kattavuuden ja markkinoille pääsyn välillä.

Jokainen commit laukaisee turvallisuustarkastuksia. Yksinkertainen CI/CD-putki on asetettu, joka tekee: tyyppitarkistuksia (esim. tsc --noEmit), lint/format-tarkistuksia, yksikkötestejä, automaattista käyttöönottoa staging-ympäristöön. Yhteisiä työkaluja käytetään: GitHub Actions, Docker Compose.

Vältämme koodattuja arvoja = pitkäaikainen kipu. Kaikki salaisuudet/konfiguraatiot tallennetaan .env-tiedostoon tai etäkonfiguraatioon (esim. AWS SSM, Vercel envs). Ympäristöön perustuva asennus käytetään (process.env.NODE_ENV). .env.*, API-avainten, tunnistetietojen jne. committamista vältetään. Ja ne on hyvin dokumentoitu.