Statik analiz

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
Önceki örnekten alınan ve pop-up'ta hata mesajıyla birlikte bir IDE'de gösterilen kod.
Yanlış bir türü ilettiğinizi belirten VSCode.

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.