On iki yıldır programlama yapıyorum ve birçok dille çalıştım. Bunlar arasında , , , , ve son olarak yer alır. Her dilin veya çerçevenin kendi kuralları vardır. Örneğin , işlev adları için kullanır. C C++ Java Python C# JavaScript Rust yılan durumunu 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. 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ı. Sınıflarla React 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 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. daha fazla Kod Formatlayıcıları Programlamaya ilk başladığımda kod formatlamasına pek dikkat etmedim. Sanırım her şey üniversitede beyaz temalı harika C++ öğrendiğimde başladı. CodeBlocks IDE'mde 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. GitHub'daki 2016'daki eski koduma Ş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 ve kuruyorum. Buna çok fazla zaman harcamak istemiyorsanız gibi önceden hazırlanmış konfigürasyonları kullanabilirsiniz. Prettier ESLint'i Airbnb'deki İ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? ve gibi araçlar bu otomasyonu mümkün kılar. Husky lint-staged Dosya İsimleri için Kebap Davası 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. Angular'ın Bu yüzden tüm ön uç projelerim için kebab-case'i kullanmaya karar verdim. Aşağıdakiler gibi birkaç avantaj sunar: : 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. Basitlik : 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. paketini kullanarak kebab-case'i eslint kuralıyla kullanmaya zorlayabileceğinizi unutmayın: Tutarlılık Unicorn 'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ], : 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. Platformlar arası uyumluluk : 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. Git sorunu 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, , dosyanın özelliği için bir bileşen olduğunu ve bunun bir TypeScript dosyası olduğunu gösterir. yönelik bir hizmettir. heroes.component.ts heroes heroes.service.ts heroes büyük bir hayranı değilim ama React bileşenlerim için benzer bir yapı kullanıyorum. İşte bir örnek: services 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. ve ben de aynısını yapmak için her zaman kullanırım. Plop'un şablon sistemi çok güçlüdür ancak en önemlisi zamandan tasarruf sağlar. Angular CLI, kullanıcıların otomatik olarak kod oluşturmasına olanak tanır plop'u 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 ne olduğunu detaylı olarak açıklamayacağım. Bu konuda daha fazla bilgi edinmek istiyorsanız okumanızı tavsiye ederim. Şu anda tam kapsamlı geliştiricilerden oluşan bir ekiple çalışıyorum ve ön uç projemizde bir katmanına sahip olmanın gerçekten yararlı olduğunu gördük. domain bu makaleyi etki alanı 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 göz atabilirsiniz. Orada bu konuyu anlatmak için çok zaman harcıyorum. bu makaleye Mimarinizi Test Etme 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. Kotlin İşte o zaman mimarimizi birim test etmeye yönelik bir araç olan keşfettik. Temel olarak mimarimize doğru şekilde bağlı kalıp kalmadığımızı kontrol eder. ArchUnit'i Belirli bir mimariyi sürdürüyorsanız, bir noktada bunun bozulup bozulmadığını kontrol edecek bir araca sahip olmak faydalı olabilir. gibi bir araç bu bakımdan çok değerli olabilir. Dependency-cruiser 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!
