Javscript

Takım Arkadaşlarınızın Gece Uyumasına Yardımcı Olacak 5 JavaScript Uygulaması – JSManifest

1. Aynı ada sahip birden fazla dosyadan kaçının (özellikle benzer davranışlara sahip)

Dosyalarımızı adlandırmak görünüşte basit bir iştir. Ama sadece basit olduğu için yapmak pek sorun olmayacağı anlamına gelmez. Değişkenlerimizi kodda adlandırmak gibi, bu, bir proje için kod yazan tek kişi olmadığınızda büyük bir anlaşma haline gelebilecek bir uygulamadır.

Geçenlerde, artık muhafaza etmediği için devralmak zorunda olduğum bir paketin bakımını yapan bir meslektaşım vardı.

Mükemmel bir dünyada, tüm kodların bakımı ve Boy ile çalışması kolay olmalıdır, hayattaki her şey bizim lehimize gitmez. Bir süre kafamı karıştıran bir şey, birden fazla dosyaya rastlamaktı. aynı isim. Daha da kötüsü, her ikisinin de uygulama detaylarının benzer olmasıydı.

Bu yüzden soruları sordum,

  1. Hangisi ihtiyacım olan fonksiyona sahip?
  2. Bu dosyalardan birini değiştirmek, diğerinde de değişiklik yapmam gerektiği anlamına mı geliyor?
  3. Benzer davranışları paylaşıyorlarsa onları tek bir yerde nasıl birleştirebilirim?

İki dosya şu şekilde adlandırılır:

  • src/services/document.js
  • src/utils/builtIn/document.js

Buradaki en iyi uygulama, onları tam olarak tek bir dosyaya koymak değildir. Buradaki büyük resim, kodumuzun bakımının kolay olması gerektiği ilkesini takip etmektir. İki benzer şey arasında riskli bir karar vermekle karşı karşıya kalırsak, kod basitliğini kaybeder. Daha da kötüsü şu ki, Hizmetler yakından ilgilidir araçlar tanımlarına göre.

Bu çözülmezse, gelecekteki takım arkadaşları aynı durumdan geçecek ve aynı yazara aynı soruları soracak. Bu çok iyi bir uygulama değil ve herkesin zamanını boşa harcıyor!

2. Ölü şeyleri temizleyin

Burada “malzeme”nin pek çok anlama gelebileceğini belirtmekte fayda var. Amaç, projede artık kullanılmayan ölü/etkin olmayan kodlardan (dosyalar dahil) kurtulmaktır.

bizde varsa constants.js tüm sabitleri tutan dosya ve sonra bir tane daha var constants.js yeni konum olarak başka bir dizinde bir yere yerleştirilmişse, sabit değişkenleri eski dosyadan hemen kaldırmak iyi bir uygulamadır. en kısa sürede aksi takdirde kodunuzun okuyucuları yine yukarıda bahsedilen durumdan muzdarip olacaktır.

Kodun çeşitli bölümlerinde yanlış yerden içe aktarma yaparlarsa, üretim ortamında hata üretmeden önce birinin gidip her içe aktarmayı düzeltmesi gerekir.

3. Açık parametre adlandırma

Argüman bekleyen bir işlevde hata ayıklarken, bunları uygulama ayrıntılarıyla yakından ilgili olacak şekilde uygun şekilde adlandırmak iyi bir uygulamadır.

İşlev çağrılarında argümanları şöyle yazılan kodlara sık rastlanır:

function createSignature(obj) {
  if (typeof obj === 'string') {
    
  } else if (Array.isArray(obj)) {
    
  } else {
    
  }
}

Herkesin kafasını karıştırması dışında kodda yanlış bir şey yok. Bunun gibi kod okuyan insanlar doğal olarak parametrenin obj bir nesne olacak. Ancak uygulama detayları bununla çelişiyor.

Parametrelerin uygulanmasına mı yoksa adlandırılmasına mı daha çok güvenmeliyiz?

Tüm fonksiyona da güvenmeyebiliriz! Gibi daha genel bir adlandırma value daha da iyi bir seçimdir çünkü bir değer, uygulamanın gösterdiği gibi herhangi bir veri türü olabilir.

Bu yüzden imzasında farklı varyasyonları olan fonksiyonlar yazmaya çalıştığımızda, fonksiyonun gövdesiyle yakın bir ilişki sürdürürken parametreleri mümkün olduğunca genel isimlendirmeye başlamak en iyisidir ve sonra farklı veri türlerini doğrularken daha spesifik adlandırma için yolumuza devam edin:

function validateURL(value) {
  if (typeof value === 'string') {
    
  } else if (value && typeof value === 'object') {
    
  }
}

4. Birim testleri

Bu konuda hata yapmayın. Ünite testleri, uzun vadede zamandan ve terden tasarruf sağlar. Şimdi bunu söylemiyorum çünkü genellikle oradaki her makalede önerilen bir uygulama. Tecrübe konuşuyorum.

Bir projede geliştirme deneyimim olmadan ile karşılaştırıldığında birim testleri ile birlikte Kod geliştirme ve hata ayıklamanın, neredeyse hiç birim testi olmayan bir projede daha fazla ter üretmesiydi. Birim testleri, ilerlemeye kendinden emin hissetmenin güzel faydasını sağlar.

Birim testleri oluşturduğunuzda şunlar olur:

  1. Kalıcı koruma elde edersiniz kodunuzun bölümleri boyunca. Birim testlerinde çok gerilere düşerken kod geliştirmeye devam ettiğinizde ve gelecekte değişiklik yaptığınızda, size söyleyeyim, bu mutlak bir şeydir. kâbus. Kodunuzun başka bir bölümünü güncellemek zorunda kalmanıza neden olacak değişiklikler yaptığınızda, hataların art arda yayılmasının yıkıcı bir domino etkisi olabilir. Bu genellikle sonucu olabilir örtük fonksiyonlarımızdaki bağımlılıklar. Buradaki anahtar kelime örtük. eğer almazsan kontrol Şimdi kodunuzun bir kısmı, çok önemli kodu kaçırıyor olacaksınız ve can sıkıcı hataları gerçekten almaya başlayana kadar bunu fark etmeyeceksiniz. Şimdi, birkaç ay sonra kodunuzda değişiklik yaptığınızda, kodunuz üzerinde kontrol ve güvene sahip olmanız için birim testleri oluşturabilirsiniz. Bir hata yaptığınızda, birim testleriniz, onları çalıştırdığınızda hemen sizi uyaracaktır. Bahsettiğim kalıcı koruma bu.

  2. Sağlam bir mimari anlayış elde edersiniz kod yapınız üzerinde. Çalışma zamanı sırasındaki karmaşık senaryolarda (kullanıcılar uygulamanızı kullanırken), kullanıcı düğmelere birden çok kez tıklamak, ileri, geri tıklamak, profillerine gitmek, alışveriş sepetlerini ziyaret etmek gibi kullanıcı eylemlerini spam yaptığında tam olarak ne olduğunu gözden kaçırmak kolaydır. vb. saniyeler içinde. Gözlerimiz, gerçek zamanlı olarak gördüklerimizle ilgili sınırlamalara sahiptir (bu yüzden zamanda geriye yolculuk yapmak için hata ayıklama araçlarına ihtiyacımız vardır) ve bu milisaniyelik işlemler sırasında zihinsel olarak işlediğimiz şeylerde. Birim testleri, işlevlerinizin tam zamanlamasını ayırmaya yardımcı olur ve işlev çağrıları arasında beklendiği gibi davranıp davranmadıklarını test edebilirsiniz.

  3. takım oyuncusu olursun mevcut ve gelen ekip üyelerinize. Kodlamak için birim testleri oluşturmak, diğer ekip arkadaşlarının mevcut mevcut davranışla çelişen kodları zorlamaktan kaçınmasına yardımcı olur. Ayrıca kodunuzu anlamalarına yardımcı olur.

5. Açık TypeScript yazımları

Bu, kulağa bariz gelen ancak tekrar tekrar söylenmesi gereken ipuçlarından biridir. Şuna benzeyen türler yazmak için nadiren TypeScript kullananlar için bir uyandırma çağrısıdır:

type ReferenceString = string

type Obj = Record<string, any>

interface TransformFunc {
  (
    transformer: <V>(value: ReferenceString | Obj | any[]) => V,
    ...args: any
  ): any[]
}

const transform: TransformFunc = (transformer, ...args) => {
  return args.reduce(
    (arr, arg) =>
      Array.isArray(arg)
        ? arr.concat(...arg.map((val) => transformer(val)))
        : transformer(arg),
    [],
  )
}

Ortalama olarak tüm projeleriniz için bu şekilde kodlama yaparak elde edebilirsiniz. Ama sadece bununla yapabilirsin:

const transform = (transformer, ...args) => {
  return args.reduce(
    (arr, arg) =>
      Array.isArray(arg)
        ? arr.concat(...arg.map((val) => transformer(val)))
        : transformer(arg),
    [],
  )
}

Buradaki nokta, TypeScript’in tam potansiyeline itilmemesi ve onu bu şekilde kullanmak, “TypeScript’in amacı nedir?” sorusunu akla getiriyor. TypeScript, daha spesifik türler kullanılarak ve sunduğu özelliklerden yararlanıldığında, geliştirme akışında gerçekten büyük bir fark yaratır.

TypeScript ile kodumuzdan daha fazlasını elde etmenin bir örneği, tür takma adımızla daha açık ve bildirimsel olmaktır. ReferenceString. Referans dizeleri (veri değerleri için yer tutucular olduklarını söyleyelim), bildirim yerine bir sembolle ön eklenmiş dizelerse string TypeScript’i, bu tür olarak uygulanan tüm dizelerin ön eki olmasını zorunlu kılabiliriz:

type ReferenceString<V extends string = string> = `.${V}`

TypeScript sizi bununla uyardığında geliştirme iş akışınız çok daha sorunsuz ilerliyor:

type ReferenceString<V extends string = string> = `.${V}`

function validateRefStr<S extends ReferenceString>(value: S): value is S {
  return typeof value === 'string' && value.startsWith('.')
}

const ref1 = validateRefStr('.abcdef') 
const ref2 = validateRefStr('abcdef.') 
const ref3 = validateRefStr('=.abcdef.') 

6. Tek bir yazı stiline bağlı kalın

Sanırım hepimiz bir noktada ok işlevleri ve işlev bildirimleri arasında geçiş yapmaktan suçluyduk:

function getDogs() {
  return new Promise((resolve, reject) => ['dog1', 'dog2'])
}

const getDogs = () => new Promise((resolve, reject) => ['dog1', 'dog2'])

Her şey yolunda, ama inanın bana, elinizden geldiğince tek bir yazı stiline bağlı kaldığınızda, olumlu yönde gözle görülür şekilde farklı oluyor. Dile daha çok alıştıkça, tek bir stilin olduğu durumlarla karşılaşacaksınız. olmalıdır işlevin istediğiniz gibi davranması için kullanılır. Bunun gibi zamanlar, alternatif bir şekilde yazmak için bu şansı kullandığınız zamandır.

Geliştiriciler, farklılıkları hızlı bir şekilde yakalarken kodu okuyabildikleri ve bir şeyin normalden farklı yazıldığını gördüklerinde arkasındaki nedenleri görebildiği zaman, geliştirme ve hata ayıklama süreci çok daha sorunsuzdur.

Örnek olarak, iframe’leri eşzamansız olarak yüklediğimizde ve belirli bir değere geri ihtiyacımız olduğunda sonrasında eleman yüklendi:

async function initContainer({ children, tagName = 'div' } = {}) {
  const container = document.createElement(tagName)
  if (children) {
    container.appendChild(await children(container))
  }
  return container
}

async function startApp() {
  await initContainer({
    children: (container) => {
      return new Promise((resolve, reject) => {
        const attributes = { src: 'http://www.google.com/abc.png' }
        const elem = document.createElement('iframe')

        Object.entries(attributes).forEach(([attr, value]) => {
          elem.setAttribute(attr, value)
        })

        elem.addEventListener('load', function (evt) {
          resolve(elem)
        })

        elem.addEventListener('error', reject)
      })
    },
  })
}

Burada iki zaman uyumsuz işlevimiz ve kullanarak bir söz veren bir işlevimiz var. new Promise() sözdizimi.

Bu şimdiye kadar çok iyi görünüyor. Peki ya kodun okunabilirliğini biraz daha geliştirip biraz daha temiz görünmesini isteseydik?

Tutarlı olmak için, içindeki çirkin uygulama ayrıntılarını gizleyebiliriz. new Promise öğelerin eşzamansız olarak oluşturulduğu bir dosyaya, böylece önden çalışmak için güzel bir temiz kodumuz olur:


function getIframe(container = document.body) {
  return new Promise((resolve, reject) => {
    const attributes = { src: 'http://www.google.com/abc.png' }
    const elem = document.createElement('iframe')

    
    Object.entries(attributes).forEach(([attr, value]) => {
      elem.setAttribute(attr, value)
    })

    elem.addEventListener('load', function (evt) {
      resolve(elem)
    })

    elem.addEventListener('error', reject)
  })
}


import { getIframe } from '../elements'

async function initContainer({ children, tagName = 'div' } = {}) {
  const container = document.createElement(tagName)
  if (children) {
    container.appendChild(await children(container))
  }
  return container
}

async function startApp() {
  await initContainer({ children: getIframe })
}

Açıkçası bu isteğe bağlıdır. Ama herkesin gününü onlar için daha basit hale getirebilecek bunun gibi küçük şeyler 🙂

Çözüm

Ve bu yazının sonu burada bitiyor! Bunu değerli buldunuz ve gelecekte daha fazlasına dikkat edin!

İlgili Makaleler

Bir cevap yazın

E-posta hesabınız yayımlanmayacak.

Başa dön tuşu