bencede
New member
Hata ayıklama, izleme ve kod kalitesi: web geliştirmede araçlar
Web geliştirmede bile sıcak çevrimiçi işler her zaman ilk seferinde düzgün gitmez. Yıllar geçtikçe kodun hata ayıklaması, izlenmesi ve kalitesinin artırılması için çeşitli araçlar oluşturulmuştur.
Kod yazdığınız, bazı testler yaptığınız, olası tüm güvenlik sorunlarını göz önünde bulundurduğunuz, kullanılabilirlik, erişilebilirlik ve performans yönlerini zaten göz önünde bulundurduğunuz ve bunun üzerine her şeyi bölümün geri kalanıyla aynı tarzda yazdığınız bir dünya ne güzel olurdu. vardır? Ancak, bu genellikle destek olmadan çalışmaz.
Bir yandan, hatalar her zaman daha sonra izini sürmemiz gereken üretken koda girer. Öte yandan, geliştirme sırasında kodumuzun kalitesinin artmasını sağlamaya ve daha sonra düzeltmek zorunda kalmadan hataları ve diğer sorunları olabildiğince önlemeye çalışıyoruz.
yaratılış için
Lint eklentileri, düzenleyicideki Lint kurallarımıza göre kodu zaten kontrol eder, JavaScript için yapılandırmamız genel depoda da mevcuttur. Ortak tiftik kuralları çoğunlukla bir kod tabanındaki farklı stillere karşı yardımcı olur, ancak aynı zamanda gözden kaçmayı da önler. Açılış ayracı artık satıra ait if veya daha doğrusu aşağıda ayrı bir satırda? Net tiftik kuralları bu tartışmaları engeller – bu aynı zamanda eski “sekmeler mi yoksa boşluklar mı?” sorusu için de geçerlidir.
Ayrıca, kullanışlılıklarına bağlı olarak çeşitli birim ve entegrasyon testleri vardır. Bazı projelerde, testte tüy veya hata sorunu olup olmadığını iki kez kontrol eden ön işleme ve ön itme kancalarımız vardır. Yayın otomasyonu kullandığımız projeler için, bu ön taahhüt kancaları, yayın dışı otomasyon uyumlu taahhüt mesajlarından da kaçınmaya yardımcı olur.
Özellikle ön uç çerçevemiz akwa için araca hala sahibiz akwaDebuggeliştirme aşamasında ve canlı sistemde aktif hale getirilebilen ve bu sayede süreçleri hakkında daha detaylı bilgi sağlayan, özellikle karmaşık problemlerde çok faydalı olabilen bir sistemdir.
Kritik CSS’yi kullandığımız her yerde, dosyada bir giriş performanceOluşturma işlemi sırasında web paketi yapılandırmasının, ayarlanan dosya boyutu sınırlarımızın aşılmaması bölümü. AMP projeleri için, yalnızca 75 KB CSS’ye izin verildiği için bu bir zorunluluktur.
Birden çok aşamaya ve başarılı bir “tiftik” etkinliğine sahip bir GitLab CI ardışık düzeni.
CI aşamaları
Kod, paylaşılan sürüm yönetimine girdikten sonra, testler (yeniden) çalıştırılır. Bir birleştirme isteği durumunda, bir tamamlamadan sonra bir SonarQube örneği, birleştirme sonucunda kod tabanının bozulup bozulmayacağını kontrol eder. Bir yandan SonarQube, kodun kalitesine (kod kokusu, erişilebilirlik sorunları, kod tekrarı vb.) ve aynı zamanda güvenlik risklerine bakar.
SonarQube’u ilk tanıttığımızda, hatalar ve uyarılarla boğulmuştuk. Ama korkma. Bir yandan, başlangıçta konfigürasyonu ihtiyaçlarımıza göre ayarlamak zorunda kaldık. Öte yandan, sorunların çoğu oldukça küçük nitelikteydi. Bu nedenle, bazılarımız zaman zaman birçok uyarıyı ve hatayı silmekten ve böylece alanları 0’a getirmekten keyif aldı. Ancak, prensipte, SonarQube, giriş anında kodun mevcut durumunu dikkate alacak şekilde ayarlanabilir. temel olarak ve bir birleştirme talebinden geçmiyorsa Dahası oluşturulan hatalar veya uyarılar.
İnsanların okumayı sevdiği şekilde SonarQube analizi – hepsi geçti! GitLab’a her gönderimden sonra, SonarQube bir analiz raporuyla kontrol eder ve yorumlar.
Yayınlandıktan sonra hatalar? Hayır! Hepsinden sonra! Ey!
Sürümden sonra, her geliştirici artık (daha fazla) hata olmamasını umuyor, ancak tüm özene rağmen, deneyim bunun her zaman böyle olmadığını gösteriyor. Yığın izlemeleri ve bağlam bilgileri dahil olmak üzere gerçek zamanlı işlemlerde kod izlemeyi mümkün kılan Sentry aracı, kümedeki sorunları gidermemize yardımcı olur. Örneğin, bir hatanın tek bir göreve uzun süre neden olup olmadığını da görebilir ve hatanın kaynağını araştırmak için doğrudan bu noktadan başlamanıza olanak tanır. Aynı şekilde, performans darboğazları tam bir sorun haline gelmeden önce tespit edilebilir.
altyapı
Kodun bir yerde çalışıyor olması gerekir ve bu genellikle sunucudur. Ama orada bile gıcırdayabilir. Limit değerlerin aşılması durumunda anında alarm veren sistemlerin genel izlenmesi için çalışan Icinga2’ye sahibiz. Zaman serisi verilerinin anlamlı görselleştirmeleri için Grafana panolarını kullanıyoruz. Özellikle hataların nedenleri henüz bulunamadığında, örneğin sunucu yükü gibi sistemin durumunun ne zaman önemli ölçüde değiştiğini bir bakışta görebilmek faydalıdır. Genel günlük verilerini aramak ve aramak için Kibana’yı kullanıyoruz. Kubernetes kümemizi kendi izleme sistemimizle donattık ve şu anda Prometheus’a güveniyoruz.
Sonuç olarak, pek çok araç var, ancak her biri farklı görevlerde yardımcı olduğu için hepsinin var olma hakkı var. Ayrıca, herkesin bu araçların her birine ayrıntılı olarak aşina olması gerekmez, bazı araçlar bölümümüzdeki belirli gruplara diğerlerinden daha uygundur.
Son olarak, okuyucularımızın yaşadıkları deneyimlerle de ilgileneceğiz: Hangi araçları kullanıyorsunuz? Hata ayıklama, izleme ve kalite güvencesi için geliştirme aşamasında hangi aracı kullanmak istemezsiniz? Yorumlara yazmaktan çekinmeyin.
(hehe)
Haberin Sonu