4. Runtime validatsioon peab käima käsikäes tüüpidega
5. Genereeri tüübid, kui leping elab mujal
6. Väldi „type assertion" kultuuri
7. Tööriistad, mis hoiavad kvaliteedi püsivalt kõrgel
8. Jõudlus ja arendaja kogemus: TypeScripti suurim valupunkt
9. Kuidas TypeScriptiga turvaliselt skaleerida tiime
10. Praktiline „stardipakett“ uuele suurele projektile
Kokkuvõte
Kas teil on suur TypeScripti koodibaas või plaan seda ehitada?
Aitame seada paika TypeScripti arhitektuuri, boundary reegleid ja buildi-jõudluse mustreid nii uutes kui olemasolevates projektides. Kui soovite, et koodibaas kestaks aastaid ja tiimid saaksid turvaliselt skaleeruda, arutame läbi.
TypeScript on 2025. aastaks de facto standard enamikes uutes JavaScripti projektides. Aga TypeScript ei päästa koodibaasi iseenesest. Suures mastaabis on vahe selles, kuidas sa seda kasutad.
Kui koodiridu on kümneid või sadu tuhandeid, hakkavad väikesed otsused võimenduma:
„any“ või nõrk tsconfig muutub aastaga tehniliseks võlaks.
nõrgad piirid frontendi ja backendi vahel tekitavad vaikseid murdumisi.
aeglane build ja aeglane editor tapavad arendajate produktiivsuse.
Accelis hooldame projekte, kus TypeScripti maht on 100k+ rida ja arendus käib mitme tiimiga. Allpool on põhimõtted, mis on sellises keskkonnas end tõestanud - nii uue projekti alustamisel kui ka olemasoleva koodibaasi TypeScriptile üleminekul.
Kõige tavalisem viga suurtes projektides on alustada lõdvalt ja „keerata hiljem peale“. See peaaegu kunagi ei juhtu või muutub valulikuks refaktoreerimisprojektiks, sest vead on juba laiali.
Soovituslik tsconfig baas uuele koodibaasile:
"strict": true - kogu väärtus algab siit.
"noImplicitAny": true - „ajutine any“ muutub püsivaks.
"noUncheckedIndexedAccess": true - vähendab runtime null/undefined vigu.
"exactOptionalPropertyTypes": true - optional ei tähenda automaatselt undefined’i.
