Ön Uç Projelerinizi Geliştirmek için Diğer Dillerden ve Çerçevelerden Desenler

On iki yıldır programlama yapıyorum ve birçok dille çalıştım. Bunlar arasında C , C++ , Java , Python , C# ve son olarak JavaScript yer alır. Her dilin veya çerçevenin kendi kuralları vardır. Örneğin Rust , işlev adları için yılan durumunu kullanır.

Ancak takdir etmeye başladığım bazı kurallar, araçlar ve kalıplar var. Bunları ön uç uygulamalarıma dahil ediyorum. Bu kurallar bende daha fazla yankı uyandırıyor ve kodlamayı daha sorunsuz bir süreç haline getiriyor. İşte özellikle tercih ettiğim birkaç tanesi:

Fonksiyonel Programlama

İlk ipucum öğrendiğim ilk dil olan C'den geliyor. Sınıflarla React yazdığımızı hatırlıyor musunuz? Bunu düşünmek bile tüylerimi diken diken ediyor. React'ın işlevsel bileşenlere geçmesi, kodun okunmasını kolaylaştırmakla kalmayıp test edilmesini de kolaylaştırdı.

Ayrıca İşlevsel Programlamanın ilkeleriyle daha iyi uyum sağlar.

Bu yaklaşım ön uç çerçevelerle harika çalışır çünkü genellikle yeniden kullanılabilir kod parçaları oluşturmaya odaklanırlar. Ön uç geliştirmede İşlevsel Programlamayı kullanmak benim için bu kavramı anlama ve ayrıca yeni ön uç özellikleri oluşturma konusunda her zaman yararlı bir strateji olmuştur.

Fonksiyonel Programlama ilkelerini takip etmek her ön uç uygulamamda olmazsa olmazdır.

İşlevsel Programlamaya aşina değilseniz, onu daha fazla araştırmanızı şiddetle tavsiye ederim. Bu nokta sebepsiz yere bu listenin başında yer almıyor. Geliştirme sürecinize getirebileceği faydalar oldukça büyüktür.

Kod Formatlayıcıları

Programlamaya ilk başladığımda kod formatlamasına pek dikkat etmedim. Sanırım her şey üniversitede beyaz temalı harika CodeBlocks IDE'mde C++ öğrendiğimde başladı.

GitHub'daki 2016'daki eski koduma baktığımda, biçimlendirme için yalnızca boşluk kullandığımı görebiliyorum. Bununla otomatik olarak ilgilenmek için herhangi bir araç kullanmadım.

Şimdi bunun bir hata olduğunu anlıyorum. Projenizdeki bir şeyi otomatikleştirebiliyorsanız kesinlikle yapmalısınız. Artık her projenin başında Prettier ve ESLint'i kuruyorum. Buna çok fazla zaman harcamak istemiyorsanız Airbnb'deki gibi önceden hazırlanmış konfigürasyonları kullanabilirsiniz.

İnan bana, pişman olmayacaksın!

Ayrıca IDE'nizde dosya kaydetme işleminde otomatik biçimlendirme ayarlamayı unutmayın!

Ön Taahhüt Eylemleri

Artık harika formatlayıcılarınız olduğuna göre bunları otomatikleştirelim! Ön işleme kancalarını ne zaman kullanmaya başladığımı tam olarak hatırlamıyorum, ancak projelerimde çok yardımcı oldular. Her işlemden önce otomatikleştirilebilecekken neden manuel olarak biçimlendiresiniz? Husky ve lint-staged gibi araçlar bu otomasyonu mümkün kılar.

Dosya İsimleri için Kebap Davası

Angular'ın pek çok hayranı ve eleştirmeni olsa da ben olumluya odaklanmayı seviyorum. Angular genellikle büyük şirketler ve büyük uygulamalar için ilk tercihtir. Angular'da alınan kararların çoğunun, işleri kolaylaştırmayı amaçladığını düşünüyorum.

Bu yüzden tüm ön uç projelerim için kebab-case'i kullanmaya karar verdim. Aşağıdakiler gibi birkaç avantaj sunar:

• Basitlik : Pascal-case, deve-case veya (tercih ederseniz) yılan-case'i kullanıp kullanmayacağım konusunda endişelenmeme gerek yok. Kebap durumunda sadece bir seçenek var.

• Tutarlılık : Bir ekip üzerinde çalışıyorsanız, kebap vakası gibi tek bir adlandırma kuralını benimsemek, herkesin aynı fikirde olmasını ve projenin düzenli kalmasını sağlamaya yardımcı olabilir. Unicorn paketini kullanarak kebab-case'i eslint kuralıyla kullanmaya zorlayabileceğinizi unutmayın:

 'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ],

• Platformlar arası uyumluluk : Farklı işletim sistemleri dosya adlarını farklı şekilde işler. Örneğin Windows büyük harf kullanımını önemsemez ama Linux önemser. Küçük harf ve tire kullanan kebab-case kullanarak herhangi bir sorundan kaçınıyorum.

• Git sorunu yok : Git'te bir dosyayı küçük harften büyük harfe yeniden adlandırmayla ilgili bir sorun var. Kebap kutusunu kullandığım için endişelenmeme gerek yok.

Ben işleri basit tutmayı severim. Eğer hayatımı kolaylaştırabilir ve bundan bazı faydalar elde edebilirsem, buna tamamen varım.

Dosya Türleri için Etiketleri Kullanma

Angular'dan ödünç aldığım bir diğer şey de dosyaları nasıl adlandırdıklarıdır. Angular, dosyaların işlevlerini ve türlerini yansıtacak şekilde adlandırılmasını önerir. Bir projenin yapısında gezinmeyi ve anlamamı kolaylaştırdığını düşünüyorum. Angular'da dosya adı genellikle üç bölümden oluşur: özellik alanı, dosyanın rolü ve dosya türü.

Örneğin, heroes.component.ts , dosyanın heroes özelliği için bir bileşen olduğunu ve bunun bir TypeScript dosyası olduğunu gösterir. heroes.service.ts heroes yönelik bir hizmettir.

services büyük bir hayranı değilim ama React bileşenlerim için benzer bir yapı kullanıyorum. İşte bir örnek:

 my-component ├── my-component.component.tsx ├── my-component.type.ts ├── my-component.style.css ├── my-component.spec.tsx └── my-component.story.mdx

Bu modeli kancalarım ve işlevlerim için de kullanıyorum. Bu kalıp aynı zamanda bana testlerimi onlarla ilgili dosyaların yanına koymayı da öğretiyor.

Kod Oluşturmayı Otomatikleştirin

Daha önce bahsettiğim model çok faydalı ama otomasyonla bunu daha da iyi hale getirebiliriz. Angular CLI, kullanıcıların otomatik olarak kod oluşturmasına olanak tanır ve ben de aynısını yapmak için her zaman plop'u kullanırım. Plop'un şablon sistemi çok güçlüdür ancak en önemlisi zamandan tasarruf sağlar.

Otomasyon sayesinde bir bileşenin temel yapısı hakkında düşünmek için fazla zaman harcamam gerekmiyor. Bu görev otomatikleştirilebilir, bu da gerçekten yapmak istediğim şeye odaklanmamı sağlar.

Bir 'Etki Alanı' Kullanmak

Burada domain ne olduğunu detaylı olarak açıklamayacağım. Bu konuda daha fazla bilgi edinmek istiyorsanız bu makaleyi okumanızı tavsiye ederim. Şu anda tam kapsamlı geliştiricilerden oluşan bir ekiple çalışıyorum ve ön uç projemizde bir etki alanı katmanına sahip olmanın gerçekten yararlı olduğunu gördük.

Tüm ana türlerimizi ve operasyonlarımızı koyduğumuz yer burasıdır. Uygulamamızda 'gerçeğin kaynağı' olarak hizmet vermektedir.

Uygulamalarımda 'alan adlarını' nasıl işlediğimi görmek istiyorsanız bu makaleye göz atabilirsiniz. Orada bu konuyu anlatmak için çok zaman harcıyorum.

Mimarinizi Test Etme

Kotlin ile yaptığımız çalışmada, etki alanımızdaki depoda tanımlanan bir türün kullanılması gibi mantığın birden fazla katmanda karıştığı bir sorunla karşılaştık. Temiz Mimari açısından bu mümkün değildir ancak herkes hata yapar.

İşte o zaman mimarimizi birim test etmeye yönelik bir araç olan ArchUnit'i keşfettik. Temel olarak mimarimize doğru şekilde bağlı kalıp kalmadığımızı kontrol eder.

Belirli bir mimariyi sürdürüyorsanız, bir noktada bunun bozulup bozulmadığını kontrol edecek bir araca sahip olmak faydalı olabilir. Dependency-cruiser gibi bir araç bu bakımdan çok değerli olabilir.

Böylece, ön uç projelerinizi geliştirmek için diğer dillerden ve çerçevelerden alınan temel kalıp listem sona eriyor. Umarım bu bilgiyi faydalı bulmuşsunuzdur ve bu stratejilerden en az biri, bunu kendi işinizde uygulamanız için size ilham vermiştir!