Projelerinize Değer Katan 8 JavaScript Alışkanlığı – JSManifest

Projelerinize Değer Katan 8 JavaScript Alışkanlığı – JSManifest

Geliştiriciler olarak kod yazarken, çoğu zaman işleri halletmek için fazla düşünmeden kod yazmaya kendimizi kaptırabiliriz. Birisi kodunuzu okuyup ne olduğunu anlayana kadar çoğu zaman bu bir sorun olmayacaktır. Bu olduğunda, kodunuzu okuduklarında onlara zor anlar yaşattığınız için sizi kırmaya çalışan zehirli nefret edenlerin takipçisi olabilirsiniz. Neden sadece kendin ve diğer herkes için kolaylaştırmıyorsun? Çevrendeki herkes gibi sen de daha iyi uyuyacaksın.

Bunu söyledikten sonra, bu yazıdan hemen başlayabilirsiniz!

Bu gönderide Projelerinize Değer Katan 8 JavaScript Alışkanlığı anlatılacak, böylece sizden başka kodunuzu okuyan insanlar size daha fazla değer verecek. Neredeyse iki yıldır liderim ve bunlar Takım Lideri olarak takım arkadaşlarımdan benimsediğim en sevdiğim alışkanlıklar.

Yazarken Belgeleyici Olun

Bu onu listenin en başında yapıyor çünkü bana göre bu, kafa karıştırıcı kodlar yazan “iyi” kodlayıcıların aksine takım arkadaşlarımı daha değerli kılıyor! Takım oyuncusu olmadığınız zaman işbirliği yapmanın veya birlikte çalışmanın anlamı nedir?

Kodunuzu belgelediğinizde, insanlara güvenlik duygusu veren çekici karizma havasını yayarak bir dizi fayda sağlarsınız çünkü koda güven ve itimat kurarsınız. Karmaşık bir kodun ne kadar çok yorumu olursa, o kadar çok insan sizi bir ekip ortamında ortak çalışan olarak görmek ister.

Aşağıdaki örneğe bir göz atın:



export default function isAwaitReference(
  v = '',
): v is ReferenceString<string, '@'> {
  if (v.endsWith('@') && v.substring(v.lengt  - 1) === 'e') return true
  return false
}

Yorumlar olmadan bu fonksiyonun ne yaptığını anlayabilecek misiniz? Muhtemelen değil. Sadece yorumları okuyarak ne tür dizelerin geri döneceğini neredeyse anında tahmin edebiliriz. true. Yorumların üst kısmındaki iki örneğin ortak bir noktası var: @ sembol ve biten harflerle biten kelimeler 'e'. İle biten nokta ile ayrılmış sözcükler içeren herhangi bir dize diyebiliriz. 'e' bunu takiben @ “bekleyen referans” olarak adlandırılır.

Kodunuzu belgelemenin iyi faydaları vardır:

  1. Herkesi kurtarmaya yardımcı olur zaman. Etrafında bir şey kodlamanın ortasında bir açıklama için sizi avlamak için kendi yollarından çıkmak zorunda değiller.
  2. Ayrıştırıcılar onları yakalayabilir. Bu güzel bir avantaj çünkü bir taşla iki kuş vurmuşsunuz. TypeScript gibi ayrıştırıcılar yorumları ayrıştırabilir ve bunun gibi jeneratörler vardır. TipBelge kullanılarak yazılan kod da dahil olmak üzere dokümantasyon kodunuzu kullanabilen JSDoc sözdizimi. Onların örnek sayfa TypeDoc kullanılarak otomatik olarak oluşturuldu.

İşte pratikte bir örnek:

Bu:

Dönüşür:

typescript-typedoc-documentation-comments-jsdoc-parsing-view2

  1. Junior Developers’a yardımcı olur. Kodunuzu yorumlarla açıkladığınızda, gelen genç geliştiricilerin doğrudan kod tabanına atlama konusunda kendilerini daha güvende hissetmelerine yardımcı oluyorsunuz. Küçük geliştiriciler genellikle başlangıç ​​​​şirketlerinde hayal kırıklığına uğrarlar çünkü başlangıç ​​​​kodu için belge bulmakta zorluk çekerler.
  2. Uygulamada karmaşıklığı tanıtmayı daha hoş hale getirir. Her şey okunabilirlik ve sürdürülebilirlikle ilgili. Karmaşık bir işlev yazarsanız, ancak hepsini çalışmanın kolay olduğu yerde yedeklemek için belge koduna sahipseniz, o zaman bunu telafi eder.

Kodlarında Tarzlarına Uyum Sağlayın

Bu, birlikte çalıştığım takım arkadaşlarımda değerli bulduğum kişisel bir favori alışkanlıktır. Çoğunlukla şirketlerde geliştiricilerle çalışma deneyimimden bahsediyorum.

Bu alışkanlığın her iki tarafını da yaşadım ve herkesin takip ettiği kodlama stiline göre yazılmayan kodları aynı repoda okumak en büyük sinir bozucu hayvan çilelerinden biri.

Örneğin, üzerinde çalıştığım depolardan birinde kullandığımız let ve const kodumuz boyunca değişkenleri bildirmek için. Bir takım arkadaşı daha sonra şunu yazdı:

javascript-temiz-kod-kötü uygulama-var

Evet, bu kodda yanlış bir şey olmadığı doğru ve sadece “değişkenleri bildirmenin başka bir yolu” ancak var cesareti kırılıyor çünkü daha az hata eğilimli doğası gereği işlev kapsamı beklenmedik davranışlara ve kafa karışıklıklarına yol açabilecek gölgeleme.

Karıştırma ile ilgili gerçek sorun var ile birlikte let veya const zaten yazılmış bir işlevde hata ayıklama yapıyorsanız let (blok kapsamlı) ve kapsam içindeki ve bilmeden yeniden bildirilen bir hatayı “sabitledi” var bir hata tanıtıyor olabilirsiniz orijinal geliştirici zaten var ile aklındaydı ve bundan kaçındı let.

benzer kod uygulama ile birlikte Aynı Giriş/ÇıkışFarklı Dosyalar

Aynı şeyi yapan ancak her ikisi de farklı konumlarda içe aktarılan iki işleviniz varsa, bunları birleştirmenin veya tek bir konumdan içe aktarmanın zamanı gelmiştir.

Bunun kötü bir uygulama olmasının nedeni, yalnızca kafa karıştırıcı olması değil, aynı zamanda uygulama güncellendiyse, tüm bu işlevlerin güncellenmesi gerekir..

İkincisinin ilk sdk’den dallandığı, ancak bazı ana işlevlere sahip olduğu iki şirket içi sdk üzerinde çalıştım. kopyalayıp yapıştırdım, parametrelerde küçük güncellemelerin yanı sıra onu fonksiyon bloğu içindeki bir nesneye anahtar olarak eklediği tek bir uygulama güncellemesi olması dışında. Her iki SDK da uygulamalarda birlikte kullanılıyordu.

Kodlara sorun getirir. Ayrıca ekip arkadaşlarınızı ortak projelerdeki ilginizi, motivasyonunuzu ve alışkanlıklarınızı sorgulamaya zorlar.

Her Karar İçin Bir Sebep veya Açıklama

Tecrübelerime göre, kodumda verdiğim her karar için bir açıklamam olduğunda takım arkadaşlarının daha fazla saygı duyduğunu fark ettim. kötü olsa bile (onlardan öğreniyorum). Kendilerine sorduğum her soruya bir cevabı olan takım arkadaşlarım hakkında böyle hissediyorum. Bana yaptıklarına güvendiklerini söylüyor ve Araştırma.

TypeScript gibi bir araç kullanırsanız ve biri size işlevi neden bir sınıfa yeniden yazdığınızı sorarsa ve “Modern yol bu” gibi cevaplar verirseniz, yazdıklarınıza olan güveninizi sorgulamaya başlayacaklar. “TypeScript, sınıf sözdiziminden çok daha fazla tür çıkarabiliyor” gibi, bundan ne gibi gerçek fayda elde ettiğinizi açıklarsanız, pozitiflikte büyük bir fark vardır. kimse söylemeyecek hayır Buna.

Temiz Kod ve En İyi Uygulamalar

Kodunuzda ne kadar temiz kod uygulamaları uygularsanız, geliştiriciler o kadar çok onlardan alır ve takip eder. Daha temiz kodda sürekli olarak en iyi uygulamaları uygulayarak daha az hata ayıklama için zaman harcarsınız ve kodunuz stajyerlerin uyum sağlaması için ön saflarda olur, böylece aslında başkalarına da yardımcı olursunuz.

Kullanımdan Kaldırıldıklarında Eski/Kullanımdan Kaldırılan Sözdizimi bir neden için

Eski/kullanımdan kaldırılmış söz diziminden uzaklaşmak, JavaScript topluluğundaki en son haberleri takip ettiğinizi gösterir. Bu, sizi bir takım arkadaşı olarak daha değerli kılar, çünkü en son teknolojiyi takip etmek, sektörde rekabetçi kalmanın iyi bir yoludur (her şeyi kendinize saklamadığınız sürece).

Hata yönetimi

Hiç kimse, üretime gönderilen ve çökmeyle sonuçlanan kod yazmak için kredi almayı sevmez. Daha önce hata bulan kullanıcılar sen en kötü durum senaryosu ve her gün oluyor. Üretimde ne kadar az hata üretirseniz, geliştirici olarak size o kadar çok insan güvenir.

Veri Türü Girişinin Varyasyonlarını İşleyin

Eskiden çalıştığım çok eski bir şirkette (ön mühendis olmadan önce) orada yıllardır çalışan bir iş arkadaşım vardı. Hiç kimseyle konuşmaz ama her zaman işi halleder. Ne zaman hasta olsa, işini bitiren ben olurdum. Sürekli kağıt yığınlarıyla çalışarak ağır el emeğini içeren idari görevlerde bir sürü görevi yerine getirmenin günün sadece yarısında beni ne kadar çabuk strese soktuğunu hatırlıyorum. Denetçinin çalışanın burada olmasını sevdiğini içten içe biliyordum çünkü o her zaman işi halletti ve süpervizörün işinin bu kısmı hakkında endişelenmesine gerek yoktu.

Aynı kavram kod içinde de geçerlidir. Veri türü girdilerinizi işlevlerinizde ele alın ve herkese zaman kazandırın. İnsanlar, veri girişlerini doğruladığınız için size saygı duyacaktır.

javascript-temiz-kod-tutucu-veri-tipi-giriş-fonksiyonu-hata işleme

Çözüm

Ve bu yazının sonu burada bitiyor! Umarım bunu faydalı bulmuşsunuzdur ve gelecekte daha fazlasını bekleyin!

Bir cevap yazın

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