Bu noktaların tümü mobil geliştirmeye, web ön ucuna ve arka uca uygulanabilir. Bu uygulamaları farklı ekiplerden ve son 6 yılda karşılaştığım sorunlar üzerinden topladım. Bu uygulamalar özellikle sıfırdan bir proje oluşturduğunuzda yararlı olabilir. Bazıları size çok yakışabilir, bazıları ise uymayabilir. Sizin de kendinize özgü yaklaşımlarınız, farklı deneyimleriniz varsa burada paylaşırsanız mutlu olurum. Bu arada, eğer terfi almak isteyen orta veya genç bir geliştiriciyseniz, bu uygulamaları ekibinizde uygulamak gerçekten yardımcı olabilir. Hadi gidelim!

1.Hazır olana kadar arka uç yanıtlarını taklit etmek

Standart bir yazılım geliştirme sürecinde, işletmeden yeni bir özellik isteği geldiğinde bu istek birkaç ekip arasında dağıtılır: ön uç, arka uç ve mobil uygulama geliştirme.

Daha sonra her takım planlama ve görev dağılımına devam eder. Peki ya arka uç ekibin kendi rolünü geliştirmek için önemli ölçüde daha fazla zamana ihtiyacı varsa? Peki ya haftada yalnızca bir kez uç noktalar teslim edebilirlerse?

Arka uç bir darboğaz haline gelir.

Mobil ve ön uç geliştirme ekipleri sonunda şu şekilde çalışırlar: "Ah, arka uç bunu zaten uyguladı. İzin verin bu görevi ben üstleneyim." Daha sonra ara verirler, bağlamlarını başka bir özelliğe geçirirler ve döngü devam eder. Bu durum yorgunluğa, hızın azalmasına ve kalitenin düşmesine neden olur.

Çözüm: Arka uç ekibiyle bir sözleşme üzerinde anlaşın ve tüm taleplerle dalga geçin.

1. Uç noktalar ve varlıklar konusunda arka uç ekibiyle koordinasyon sağlayın.

2A. Saplama yanıtlarıyla arka uç API'sini uygulayın. Faker kütüphanesi örnek veri oluşturmaya yardımcı olabilir.

2B. Veya ön uçta taslaklar uygulayın. Bu, doğrudan kodda veri bulunan bir nesne olabilir. Örneğin, Node.js'de dinamik içe aktarmaları kullanarak bunu verimli bir şekilde uygulayabilir ve paket boyutunu artırmaktan kaçınabilirsiniz:

 getUser() { return import('../../assets/mocks/users') .then(data => data.userById) .then(deserializeUser); };

Bu aynı zamanda gerçek isteklerde bulunmak yerine JSON dosyalarını varlıklardan getiren sahte bir HTTP hizmeti de olabilir.

3. Özelliği bir özellik bayrağının arkasına gizleyin.

   
   

4. Arka uç hazır olduğunda, ön uç taslakları yaklaşımını kullandıysanız gerçek API'ye geçin ve her şeyin beklendiği gibi çalıştığını doğrulayın. Ve bu özelliği açın.

2.Özellik bayrağı

Şimdi, muhtemelen fark ettiğiniz gibi, önceki bölümde özellik bayraklarından bahsetmiştim. Özetle, özellik bayrakları, diğer bir deyişle özellik geçişleri, geliştiricilerin özellikleri canlı bir ortamda açmasına veya kapatmasına olanak tanır. Ayrıca yararlı oldukları birkaç durum da vardır: yeni özelliklerin kademeli olarak kullanıma sunulması, A/B testinin yapılması, beta özelliklerin etkinleştirilmesi ve düzeltmelerin uygulanması.

Özellik bayraklarını depolamak için Gitlab'ı kullanıyoruz. Hem arka uç hem de ön uç projeleri tarafından kullanılan özel bir depodur. Harika haber, kullanıcı dostu bir kullanıcı arayüzüne sahip olması, dolayısıyla ürün yöneticilerinin özellikleri kendileri yönetebilmesi. Daha önce her proje deposu için özellik bayraklarını ayrı ayrı kullanıyorduk. Ancak bu yaklaşım, tüm ürüne ilişkin özelliklerin aynı anda devre dışı bırakılması olanağını sağlamıyordu. Böylece her şeyi tek bir depoya taşıyoruz.

Kodda oldukça basit görünüyor:

1. Projede tüm aktif özellik bayraklarını getiriyoruz. Aslında Gitlab, Unleash'i (özellik değiştirme hizmeti) temel alıyor, biz onun resmi istemcisini kullanıyoruz.
2. Ve sonra, gizlenmesi gereken koda if features.YOUR_FEATURE yazın.
3. Özellik bayrağına farklı değerler ekleyerek kullanım örneklerini genişletebilirsiniz. Örneğin renk değerini veya indirim değerini ekleyerek.

3. Üretim ortamındaki sorunları izlemek için hataları izleme

Ürünümüz MVP aşamasından üretim uygulamasına geçtiğinde, kullanıcıların bizim yeniden oluşturamayacağımız ve hatta farkında bile olamayacağımız hatalar alacağından endişeleniyorduk. Hata izleme araçlarını araştırdıktan sonra Sentry'de karar kıldık. Deneyim olumluydu. Şimdi bazı önemli nüansları gözden geçirelim.

Yararsız Hatalar

Kaputun altında, yakalanmamış herhangi bir istisna izlenecektir. Uygulama ve kullanıcı sayısı arttıkça hataların sayısı o kadar fazla olabiliyor ki, gerçekten önemli olan herhangi bir şeyi fark etmek neredeyse imkansız hale geliyor. Gereksiz şeyleri filtrelemezseniz Sentry çöp kutusuna dönüşebilir. Örneğin, iptal edilen istekler, bağlantı hataları ve bağlı komut dosyalarındaki hatalar gibi olaylar tamamen işe yaramaz ve iş e-postanıza yalnızca bildirimlerle spam gönderir. Çözüm olarak konfigürasyona filtreler ekleyebilirsiniz. Bunu yapmak için, beforeSend geri aramasını tanımlayın ve onu sentryPackage.init dosyanıza koyun. Bu geri çağırmada, yakalanan her hatayı analiz edebilir ve işe yaramazsa onu (boş döndürerek) atabilirsiniz. Gereksiz hataları hariç tutan bir filtre örneğini burada bulabilirsiniz:

 function beforeSend(event, hint) { const error = hint.originalException; const externalScripts = [ 'gtm.js', // Google Tag Manager 'watch.js', // X Analytics ].join('|'); const errorsToIgnore = [ AxiosError.ERR_NETWORK, AxiosError.ECONNABORTED, AxiosError.ETIMEDOUT ]; if (axios.isCancel(error) || errorsToIgnore.includes(error.code) || error.stack?.match(externalScripts)) { return null; } return event; }

Daha iyi hata ayıklama için daha fazla veri ekleyin

Varsayılan olarak Sentry, istek ve yanıtın içeriğini hata raporuna dahil etmeyebilir. Bu bilgi olmadan doğru hata ayıklama mümkün değildir. Neyse ki beforeSend işleyicisine bu bilgiyi dahil edebiliriz.

 function beforeSend(event, hint) { const error = hint.originalException; if (error.isAxiosError) { const url = error.request?.responseURL; const response = error.response?.data; const request = error.config?.data; event.extra = { ...(event.extra || {}), url, response, request }; } return event; }

Hassas Bilgileri Filtrele

Hata içeriğine şifreler, e-posta adresleri ve anahtarlar gibi veriler dahil edilmemelidir. Sentry'nin bu tür bilgileri gizlemek için yerleşik bir mekanizması vardır. Bunu güvenlik ayarlarından yapılandırabilirsiniz. Ayrıca, beforeSend olay nesnesindeki bir şeyi de kaldırabilirsiniz.

Bağımsız Çözüm

İşinizin doğası bu tür verileri başka bir sunucuda saklamayı yasaklıyorsa, Sentry bu verileri kendi sunucularınızda kullanma olanağı sunar.

4.İzleme

Sentry'de bir hatayı başarıyla yakaladığınız ancak açıklamadaki bilgilerin yetersiz olduğu bir durum düşünün. Günlüklere bakıyorsunuz, ancak binlerce istek ve hatta saniyede daha fazla günlük satırı arasındaki belirli hatayı nasıl tanımlayabilirsiniz? Özellikle işletmenizde birden fazla ekip varsa ve diğer hizmetlerle entegre oluyorsa, doğru olanları nasıl ayırt edebilir, istek zincirini oluşturabilir ve tam hatayı nasıl tespit edebilirsiniz? İşte bu noktada takip devreye giriyor.

1. İzleme, çağrıların tam bir diyagramını sağlar ve bir mesaj aracısı tarafından eş zamanlı olmayan iletişim gerçekleştirdiğinizde bile başarısız olan kesin yöntemi tanımlar.
2. Farklı ekiplerle entegrasyon yaparken hatanın hangi tarafta oluştuğunu kolayca tespit etmenizi sağlar.
3. İzleme aynı zamanda performans hata ayıklaması için de kullanışlıdır. Örneğin, oluşturmanın daha mı uzun sürdüğünü veya mikro hizmetteki bir yöntemin yeterince optimize edilmediğini açıklığa kavuşturmaya yardımcı olabilir.

Özel uygulamamızda OpenTracing API'sini temel alan Jaeger'i kullandık.

Özetle, her istek ve onun tüm yöntem çağrıları benzersiz bir etiketle etiketlenir. Her etiketin üst öğesine ve bazı meta verilere bir referansı vardır. Bu sayının yapısı uygulamaya bağlıdır ancak OpenTracing'e gelince, nasıl çalıştığını okuyabilir ve yayılma, referans, alt, üst ve benzeri terimleri resmi depo sayfasından öğrenebilirsiniz. Gerçek hayatta, şans eseri izleme nadiren kullanılacaktır. Ancak nadir görülen bu kazalarda size zaman kazandırabilir.

5.Performans optimizasyonu

Fintech uygulamasının MVP'sini hayata geçirdiğimizde oldukça karmaşık bir formla karşılaştık. O zamanlar henüz genç ve tecrübesizdim. Ve sonunda projemizin yavaşladığını fark ettik. Sebebini bulmak için fazladan saatler harcamak zorunda kaldık. React'teki aksesuarlarla ilgili temel kuralları göz ardı ettiğimiz için birçok gereksiz yeniden işleme yaşadık. Gelecekte bu tür durumlarla karşılaşmamak için mümkün olan her şeyi yapmak istedim.

Böylece, projeye buna benzer linterler ve package.json dosyasına Why-did-you-render dosyasını çalıştırmak için ek bir başlangıç yapılandırması ekledim. Kısacası bu eklenti, bir şeyin gereksiz yere yeniden işlenmesi durumunda uyarı verir ve bundan nasıl kaçınılacağını önerir. Ayrıca Lighthouse'u başsız modda çalıştırmayı da dahil ettik. Bazıları erken optimizasyonların kötü olduğunu söylüyor ama benim için bu bir prensip: bunu en başından itibaren yapın .

6.Tüm ekip projeleri için tanımlanmış kod stili

Muhtemelen kırık cam teorisini duymuşsunuzdur. Bir binanın tek bir penceresi kırılırsa ve kimse onu değiştirmezse, sonunda o binada tek bir sağlam pencere bile kalmayacaktır.

Bir projede ne kadar az kural ve kontrol varsa, düşük kaliteli kod yazma veya onu tamamen farklı bir tarzda yazma isteği de o kadar artar. Tutarsız kod, onu anlamak için gereken süreyi artırırken açık, tanıdık ve kısa kod, hızlı okumaya olanak tanır. Ekiplerimizden birinde kodlama stilini tek bir yerde anlattık. Harika bir başlangıç noktası olarak Prettier veya Airbnb kod stilini kullanabilirsiniz.

7.Regresyon testleri

Farklı test türleri, yaklaşımlar ve bunların doğru şekilde nasıl yazılacağı hakkında önemli miktarda literatür zaten yazılmıştır. Burada bahsetmeye değer tek şey, hiçbir üretim uygulamasının regresyon testi olmadan hayatta kalamayacağıdır. Bu nedenle tüm çabalarımızı kapsamlı bir uçtan uca test çerçevesi oluşturmaya odakladık ve buna dayanarak BDD senaryoları ve kullanıcı hikayeleriyle bağlantılı testler yazdık. Kodumuzu düzenlemek için Sayfa Nesnesi modelini ve tarayıcıyla etkileşim kurmak için Oyun Yazarı çerçevesini kullandık. Safari dahil farklı tarayıcılarda test yapmak için Moon adlı çözümü kullanabilirsiniz. Sunucularınızdan birine dağıtılabilir.

Çözüm

Bu makaleyi okumaya zaman ayırdığınız için teşekkür ederiz! Sonuç olarak bu makale, geliştirme süreçlerini ve kod kalitesini artıran temel yazılım mühendisliği uygulamalarını vurgulamaktadır. Arka uç yanıt alayı, özellik işaretleri, hata izleme, performans optimizasyonu, kod stili standartları, regresyon testleri ve izleme gibi teknikleri benimseyerek daha verimli ve güvenilir yazılım oluşturabilirsiniz. Yazılımımızı geliştirmeye ve iletişim halinde kalmaya devam edelim! :)

Bu makalenin ana görseli HackerNoon'unYapay Zeka Görüntü Oluşturucusu tarafından "hız" istemi aracılığıyla oluşturuldu.