Statik analiz, kodunuzu gerçekten çalıştırmadan veya otomatik test yazmak zorunda kalmadan otomatik şekilde kontrol etmenizi sağlayan bir test türüdür. VSCode gibi bir IDE kullanıyorsanız bu tür bir test görmüş olabilirsiniz. TypeScript tarafından gerçekleştirilen tür denetimi bir tür statik analizdir ve hataların ya da uyarıların altında eğik çizgiler olarak gösterilebilir.
ESLint
ESLint, kod tabanınızdaki olası sorunlar hakkında geri bildirim sağlayabilecek bir araçtır. Bu problemler türgüvenli olsa da kendiliğinde hatalar veya standart dışı davranış olabilir. ESLint, "önerilen" kümelerindeki birçok kural da dahil olmak üzere, kod tabanınızda kontrol edilen çeşitli kuralları uygulamanıza olanak tanır.
ESLint kuralına iyi bir örnek olarak no-unsafe-finally kuralı verilebilir. Bu, bir finally
bloğu içinde programınızın kontrol akışını değiştiren ifadeler yazmanızı engeller. Bu harika bir kuraldır, çünkü bunu yapmak
JavaScript yazmak için takip edilmesi zor olabilecek alışılmadık bir yoldur. Ancak bu, sağlıklı bir kod inceleme sürecinin algılayabilmesi gereken bir şeydir.
try {
const result = await complexFetchFromNetwork();
if (!result.ok) {
throw new Error("failed to fetch");
}
} finally {
// warning - this will 'overrule' the previous exception!
return false;
}
Bu nedenle ESLint, sağlıklı bir inceleme sürecinin (ve kod tabanınızın nasıl görünmesi gerektiğini tanımlayan bir stil kılavuzunun) yerine geçmez. Çünkü ESLint, geliştiricinin kod tabanına dahil etmeye çalışabileceği tüm ortodoks yaklaşımları yakalayamaz. Google'ın Mühendislik Uygulamaları kılavuzunda, "işleri basit tutma" ile ilgili kısa bir bölüm bulunmaktadır.
ESLint bir kuralı çiğnemenizi ve koda "izin verildi" olarak ek açıklama eklemenizi sağlar. Örneğin, önceki mantığa izin vermek için mantığa aşağıdaki şekilde not verebilirsiniz:
finally {
// eslint-disable-next-line no-unsafe-finally
return false;
}
Bir kuralı sürekli olarak ihlal ediyorsanız bunu devre dışı bırakmayı düşünün. Bu araçlar sizi bir şekilde kod yazmaya teşvik etse de ekibiniz kod yazmaya farklı bir şekilde alışmış olabilir ve zaten bu yaklaşımın risklerinin farkında olabilir.
Son olarak, büyük bir kod tabanında statik analiz araçlarının etkinleştirilmesi, normalde işe yaramayan kodlar üzerinde çok fazla faydalı olmayan gürültüye (ve yeniden düzenleme yapmak için yoğun çalışmalara) neden olabilir. Dolayısıyla bir projenin yaşam döngüsünün ilk zamanlarında bu özelliği etkinleştirmek daha kolaydır.
Tarayıcı desteği için ESLint eklentileri
ESLint'e, geniş çapta desteklenmeyen veya hedef tarayıcı listeniz tarafından desteklenmeyen API'lerin kullanımını işaretleyen bir eklenti ekleyebilirsiniz. eslint-plugin-compat paketi, bir API'nin kullanıcılarınız için kullanılabilir olmaması durumunda sizi uyarabilir. Böylece, sürekli takip etmeniz gerekmez.
Statik analiz için tür kontrolü
JavaScript'i öğrenirken, yeni geliştiriciler genellikle bunun zayıf yazılmış bir dil olduğu fikriyle tanışırlar. Yani, bir değişkeni tek bir tür olarak tanımlayıp daha sonra aynı konumu tamamen farklı bir şey için kullanmak mümkündür. Bu, Python ve diğer kodlama dillerine benzer ancak C/C++ ve Rust gibi derlenen dillerden farklıdır.
Bu tür bir dil, başlangıç için iyi olabilir ve muhtemelen JavaScript'i bu kadar popüler hale getiren bu basitliktir, ancak bazı kod tabanlarında çoğu zaman hataya neden olur veya en azından kafa karıştırıcı hataların meydana gelmesine neden olur. Örneğin, string
veya nesne türünün beklendiği bir yere number
iletildiğinde, yanlış yazılan bu değer çeşitli kitaplıklar üzerinden yayılarak son olarak kafa karıştırıcı TypeError
sorununa neden olabilir.
TypeScript
TypeScript, JavaScript'in yazma bilgisi eksikliğine karşı en yaygın kullanılan çözümdür. Bu kursta bu bilgi kapsamlı olarak kullanılmaktadır. Bu, TypeScript hakkında bir kurs olmasa da, statik analiz sağladığı için araç kutunuzun önemli bir parçası olabilir.
string
adını ve number
yaşını kabul ederek geri çağırmanın bekleneceği bu koda kısa bir örnek vermek gerekirse:
const callback = (name: string, age: string): void => {
console.info(name, 'is now', age, 'years old!');
};
onBirthday(callback);
TypeScript üzerinden çalıştırıldığında veya bir IDE'de fareyle üzerine gelindiğinde aşağıdaki hatayı oluşturur:
bad.ts:4:12 - error TS2345: Argument of type '(name: string, age: string) => void' is not assignable to parameter of type '(name: string, age: number) => void'.
Types of parameters 'age' and 'age' are incompatible.
Type 'number' is not assignable to type 'string'.
4 onBirthday(callback);
~~~~~~~~
Found 1 error in bad.ts:4
Sonuç olarak TypeScript'i kullanmanın amacı projenize sızan bunun gibi hataları önlemektir (yaş, string
değil number
olmalıdır). Bu tür hataların, diğer test türleri kullanılarak tespit edilmesi zor olabilir.
Buna ek olarak, tür sistemi bir test yazılmadan önce geri bildirimde bulunabilir.
Bu, kodun en sonunda çalıştırılacağı zaman yerine yazılım geliştirirken tür hataları hakkında size erken geri bildirim sağlayarak kod yazma sürecini kolaylaştırabilir.
TypeScript'i kullanmanın en zor yanı, doğru bir şekilde ayarlanmasıdır. Her projenin bir tsconfig.json
dosyasına ihtiyacı vardır. Bu dosya, öncelikli olarak tsc
komut satırı aracının kendisi tarafından kullanılır. Bu dosya, Vitest dahil olmak üzere VSCode gibi IDE'ler ve diğer birçok oluşturma aracı ve aracı tarafından da okunur. Yüzlerce seçenek ve işaret içeren bu dosya, ayarlanmasıyla ilgili bazı iyi kaynakları şurada bulabilirsiniz:
Genel TypeScript ipuçları
TypeScript'i bir tsconfig.json
dosyasıyla ayarlarken ve kullanırken aşağıdakileri unutmayın:
- Kaynak dosyalarınızın gerçekten dahil edildiğinden ve kontrol edildiğinden emin olun. Bir dosya gizemli bir şekilde "hata içermiyorsa", bunun nedeni muhtemelen dosyanın kontrol edilmemiş olmasıdır.
.d.ts
dosyalarındaki türleri ve arayüzleri, işlevleri yazarken örtülü bir şekilde açıklamak yerine açık bir şekilde tanımlamak, kod tabanınızın test edilmesini kolaylaştırabilir. İlgili arayüzler net olduğunda taklit ve "sahte" kod sürümleri yazmak daha kolay olur. .
TypeScript örtülü herhangi
TypeScript'in en güçlü ve faydalı yapılandırma seçeneklerinden biri noImplicitAny
işaretidir. Bununla birlikte, özellikle zaten büyük bir kod tabanınız varsa etkinleştirilmesi genellikle en zor olanıdır. (strict
modundaysanız noImplicitAny
işareti varsayılan olarak etkindir, ancak aksi takdirde etkin olmaz.)
İşaret, bu işlevin bir hata döndürmesine neden olur:
export function fibonacci(n) {
if (n <= 1) {
return 0;
} else if (n === 2) {
return 1;
}
return fibonacci(n - 1) + fibonacci(n - 2);
}
Yine de bir okuyucu olarak n
değerinin bir sayı olması gerektiği çok açık olsa da TypeScript bunu güvenle onaylayamaz. VSCode kullanıyorsanız fareyle işlevin üzerine geldiğinizde özellik şu şekilde tanımlanır:
function fibonacci(n: any): any
Bu işlevin çağrıları, yalnızca number
yerine any
türündeki bir değeri (diğer türlere izin veren bir tür) geçirebilir. noImplicitAny
işaretini etkinleştirerek geliştirme sırasında bu tür kodları koruyabilirsiniz. Böylece kodunuzun belirli yerlerde yanlış veri türlerini geçiren kodu için kapsamlı iş mantığı testleri yazmanız gerekmez.
Buradaki basit düzeltme, hem n
bağımsız değişkenini hem de fibonacci
döndürme türünü number
olarak işaretlemektir.
noImplicitAny
işareti, kod tabanınıza any
kodunu açıkça yazmanızı engellemez. Yine de any
türünü kabul eden veya döndüren bir işlev yazabilirsiniz. Her değişkene bir tür girmenizi sağlar.