Statik kod analizörünü denemek kolaydır. Ancak bunu uygulamak, özellikle de eski, büyük bir projenin geliştirilmesinde beceri gerektirir. Yanlış yapılırsa analizci iş ekleyebilir, gelişimi yavaşlatabilir ve ekibin motivasyonunu düşürebilir. Statik analizin geliştirme sürecine entegrasyonuna nasıl doğru bir şekilde yaklaşılacağından ve CI/CD'nin bir parçası olarak nasıl kullanılmaya başlanacağından kısaca bahsedelim.
Giriş
Son zamanlarda dikkatim yayına çekildi "". Bir yandan bu, tanışmaya değer güzel bir makale. Öte yandan bana öyle geliyor ki, statik analizin çok şey içeren bir projede ağrısız bir şekilde nasıl uygulanacağı konusunda hala tam bir cevap vermiyor. Makalede Teknik borcu kabul edip yalnızca yeni kod üzerinde çalışabileceğiniz belirtiliyor ancak bu teknik borçla daha sonra ne yapılacağına dair bir cevap yok.
PVS-Studio ekibimiz bu konuyla ilgili görüşlerini sunuyor. Statik kod analizörü uygulama sorununun ilk etapta nasıl ortaya çıktığına, bu sorunun nasıl aşılacağına ve teknik borcun acısız bir şekilde kademeli olarak nasıl ortadan kaldırılacağına bakalım.
Sorunlar
Bir statik analizörün başlatılması ve nasıl çalıştığını görmek genellikle zor değildir [] Kodda ilginç hatalar ve hatta korkutucu potansiyel güvenlik açıkları görebilirsiniz. Hatta bir şeyi düzeltebilirsiniz ama sonra birçok programcı pes eder.
Tüm statik analizörler yanlış pozitifler üretir. Bu, statik kod analizi metodolojisinin bir özelliğidir ve bu konuda hiçbir şey yapılamaz. Genel durumda bu, Rice teoreminin de doğruladığı gibi çözülemez bir sorundur [] Makine öğrenimi algoritmaları da yardımcı olmayacak [] Kişi her zaman şu kodun veya bu kodun yanlış olduğunu söyleyemese bile bunu programdan beklememelisiniz :).
Statik analizör önceden yapılandırılmışsa hatalı pozitifler sorun oluşturmaz:
- İlgisiz kural kümeleri devre dışı bırakıldı;
- Bazı alakasız teşhisler devre dışı bırakıldı;
- Eğer C veya C++'dan bahsediyorsak, makrolar, bu tür makroların kullanıldığı her yerde gereksiz uyarıların ortaya çıkmasına neden olan belirli yapıları içeren işaretlerdir;
- Sistem işlevlerine benzer eylemler gerçekleştiren kendi işlevleri işaretlenmiştir (kendi analogları). Memcpy veya printf) [];
- Yanlış pozitifler özellikle yorumlar kullanılarak devre dışı bırakılır;
- Ve böyle devam eder.
Bu durumda %10-15 civarında düşük bir yanlış pozitif oranı bekleyebiliriz.] Başka bir deyişle, 9 analizör uyarısından 10'u kodda gerçek bir sorun olduğunu veya en azından "kötü kokulu kod"u gösterecektir. Katılıyorum, bu senaryo son derece keyifli ve analizör, programcının gerçek bir arkadaşıdır.
Gerçekte, büyük bir projede ilk resim tamamen farklı olacaktır. Analizör eski kod için yüzlerce veya binlerce uyarı yayınlar. Bu uyarılardan hangisinin konuyla alakalı, hangisinin alakasız olduğunu hızlı bir şekilde anlamak mümkün değildir. Oturup tüm bu uyarılarla uğraşmaya başlamak mantıksız çünkü bu durumda asıl iş günlerce veya haftalarca duracak. Tipik olarak bir takımın böyle bir senaryoyu karşılaması mümkün değildir. Ayrıca değişim geçmişini bozan çok sayıda fark da olacak. Koddaki bu kadar çok parçanın hızlı bir şekilde toplu olarak düzenlenmesi, kaçınılmaz olarak yeni yazım hataları ve hatalara yol açacaktır.
Ve en önemlisi, uyarılara karşı mücadelede böyle bir başarının pek bir anlamı yok. Projenin uzun yıllardır başarılı bir şekilde yürütülmesinden bu yana, içindeki kritik hataların çoğunun zaten düzeltilmiş olduğunu kabul edin. Evet, bu düzeltmeler çok pahalıydı, hata ayıklanması gerekiyordu, hatalarla ilgili kullanıcıdan olumsuz geri bildirimler alıyordu vb. Statik bir analizör, bu hataların çoğunun kodlama aşamasında hızlı ve ucuz bir şekilde düzeltilmesine yardımcı olacaktır. Ancak şu anda öyle ya da böyle bu hatalar düzeltildi ve analizör esas olarak eski koddaki kritik olmayan hataları tespit ediyor. Bu kod kullanılmayabilir, çok nadir kullanılabilir ve içindeki bir hata gözle görülür sonuçlara yol açmayabilir. Belki düğmenin gölgesi bir yerlerde yanlış renktedir, ancak bu kimsenin ürünü kullanmasına engel değildir.
Elbette en küçük hatalar bile yine de hatadır. Ve bazen bir hata gerçek bir güvenlik açığını gizleyebilir. Ancak her şeyden vazgeçmek ve kendini zar zor belli eden kusurlarla uğraşmak için günler/haftalar harcamak şüpheli bir fikir gibi görünüyor.
Programcılar eski çalışma koduyla ilgili tüm bu uyarılara bakar, bakar, bakarlar... Ve şöyle düşünürler: Statik analiz olmadan da yapabiliriz. Hadi gidip bazı yeni kullanışlı işlevler yazalım.
Kendi açılarından haklılar. Öncelikle tüm bu uyarılardan bir şekilde kurtulmaları gerektiğini düşünüyorlar. Ancak o zaman kod analizörünün düzenli kullanımından faydalanabilecekler. Aksi takdirde, yeni uyarılar eskilerin içinde boğulacak ve kimse bunlara dikkat etmeyecektir.
Bu, derleyici uyarılarıyla aynı benzetmedir. Derleyici uyarılarının sayısını 0'da tutmayı önermeleri sebepsiz değil. 1000 uyarı varsa, o zaman 1001 olduğunda kimse buna dikkat etmeyecektir ve bu en yeni uyarının nerede aranacağı belli değildir.
Bu hikayedeki en kötü şey şu anda yukarıdan birinin sizi statik kod analizini kullanmaya zorlamasıdır. Bu sadece ekibin motivasyonunu düşürecektir çünkü onların bakış açısına göre ek bürokratik karmaşıklık sadece engel olacaktır. Hiç kimse analizörün raporlarına bakmayacak ve tüm kullanım yalnızca “kağıt üzerinde” olacaktır. Onlar. Resmi olarak analiz DevOps sürecine dahil edilmiştir ancak pratikte bunun kimseye faydası yoktur. Standlarda konferans katılımcılarından ayrıntılı hikayeler dinledik. Böyle bir deneyim, programcıların statik analiz araçlarını sonsuza kadar olmasa da uzun süre kullanmaktan vazgeçirebilir.
Teknik borcun uygulanması ve ortadan kaldırılması
Aslında, statik analizi büyük eski bir projeye bile dahil etmenin zor veya korkutucu bir yanı yoktur.
CI / CD
Ayrıca analizör anında sürekli geliştirme sürecinin bir parçası haline getirilebilir. Örneğin, PVS-Studio dağıtımı, raporu ihtiyaç duyduğunuz formatta rahatça görüntülemek için yardımcı programlar ve kodun sorunlu bölümlerini yazan geliştiricilere yönelik bildirimler içerir. PVS-Studio'yu CI/CD sistemlerinden başlatmakla daha fazla ilgilenenler için, ilgili belgeler ve bir dizi makale:
Ancak kod analiz araçlarının uygulanmasının ilk aşamalarında çok sayıda hatalı pozitif durum konusuna dönelim.
Mevcut teknik borcun düzeltilmesi ve yeni uyarıların ele alınması
Modern ticari statik analizörler yalnızca yeni veya değiştirilmiş kodda görünen yeni uyarıları incelemenize olanak tanır. Bu mekanizmanın uygulanması farklılık gösterse de özü aynıdır. PVS-Studio statik analiz cihazında bu işlevsellik aşağıdaki şekilde uygulanır.
Statik analizi hızlı bir şekilde kullanmaya başlamak için, PVS-Studio kullanıcılarına uyarıların toplu olarak bastırılmasına yönelik mekanizmayı kullanmalarını öneriyoruz.] Genel fikir şudur. Kullanıcı analizörü başlattı ve birçok uyarı aldı. Uzun yıllardır geliştirilmekte olan bir proje hayatta olduğundan, geliştiğinden ve para kazandığından, büyük olasılıkla raporda kritik kusurları belirten çok fazla uyarı olmayacaktır. Başka bir deyişle, kritik hatalar, daha pahalı yöntemler kullanılarak veya müşterilerden alınan geri bildirimler sayesinde şu veya bu şekilde zaten düzeltilmiştir. Buna göre, analizcinin şu anda bulduğu her şey teknik borç olarak değerlendirilebilir ve bunu hemen ortadan kaldırmaya çalışmak pratik değildir.
PVS-Studio'ya bu uyarıları şimdilik önemsiz olarak değerlendirmesini söyleyebilirsiniz (teknik borçları sonraya saklayın), artık bunları göstermeyecektir. Analizör, henüz ilgi çekici olmayan hatalar hakkındaki bilgileri kaydettiği özel bir dosya oluşturur. Ve artık PVS-Studio yalnızca yeni veya değiştirilmiş kod için uyarı verecektir. Üstelik tüm bunlar akıllıca uygulanıyor. Örneğin kaynak kod dosyasının başına boş bir satır eklenirse, analizci aslında hiçbir şeyin değişmediğini anlar ve sessiz kalmaya devam eder. Bu işaretleme dosyası bir sürüm kontrol sistemine yerleştirilebilir. Dosya büyük, ancak bu bir sorun değil çünkü onu sık sık saklamanın bir anlamı yok.
Artık tüm programcılar yalnızca yeni veya değiştirilmiş kodla ilgili uyarıları görecektir. Böylece analizörü dedikleri gibi ertesi günden itibaren kullanmaya başlayabilirsiniz. Daha sonra teknik borca dönebilir, hataları kademeli olarak düzeltebilir ve analizörü yapılandırabilirsiniz.
Böylece analizörün büyük ve eski bir projede uygulanmasıyla ilgili ilk sorun çözüldü. Şimdi teknik borçla ne yapacağımızı bulalım.
Hata düzeltmeleri ve yeniden düzenleme
En basit ve en doğal şey, büyük ölçüde bastırılan analizör uyarılarını analiz etmek için biraz zaman ayırmak ve bunlarla yavaş yavaş ilgilenmektir. Bir yerde koddaki hataları düzeltmelisiniz, bir yerde analizciye kodun sorunlu olmadığını söylemek için yeniden düzenleme yapmalısınız. Basit örnek:
if (a = b)Çoğu C++ derleyicisi ve çözümleyicisi bu tür kodlardan şikayetçidir, çünkü gerçekten yazmak isteme olasılıkları yüksektir. (bir == b). Ancak söylenmemiş bir anlaşma var ve bu genellikle belgelerde belirtilir, eğer ek parantezler varsa, o zaman programcının bu kodu kasıtlı olarak yazdığı kabul edilir ve yemin etmeye gerek yoktur. Örneğin, teşhis için PVS-Studio belgelerinde aşağıdaki satırın doğru ve güvenli sayılacağı açıkça yazılmıştır:
if ((a = b))Başka bir örnek. Bu C++ kodunda mı unutuldu? kırılma ya da değil?
case A:
foo();
case B:
bar();
break;PVS-Studio analizörü burada bir uyarı verecektir . Bu bir hata olmayabilir; bu durumda özniteliği ekleyerek ayrıştırıcıya bir ipucu vermelisiniz. veya örneğin __öznitelik__((son çare)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Bu tür kod değişikliklerinin hatayı düzeltmediği söylenebilir. Evet, bu doğru ama iki yararlı şeyi var. İlk olarak analizör raporu yanlış pozitiflerden kurtulur. İkinci olarak kod, bakımıyla ilgilenen kişiler için daha anlaşılır hale gelir. Ve bu çok önemli! Yalnızca bu nedenle, kodu daha net ve bakımı kolay hale getirmek için küçük yeniden düzenleme işlemleri gerçekleştirmeye değer. Analizci "ara"nın gerekli olup olmadığını anlamadığından, bu durum diğer programcılar için de belirsiz olacaktır.
Hata düzeltmeleri ve yeniden düzenlemelerin yanı sıra, açıkça yanlış olan analizör uyarılarını özel olarak bastırabilirsiniz. Bazı alakasız teşhisler devre dışı bırakılabilir. Örneğin birisi uyarıların anlamsız olduğunu düşünüyor float/double değerlerin karşılaştırılması hakkında. Bazıları bunları önemli ve çalışmaya değer olarak sınıflandırıyor [] Hangi uyarıların ilgili kabul edilip hangilerinin edilmediğine karar vermek geliştirme ekibine kalmıştır.
Yanlış uyarıları bastırmanın başka yolları da vardır. Örneğin, makro işaretlemeden daha önce bahsedilmişti. Bütün bunlar belgelerde daha ayrıntılı olarak açıklanmaktadır. En önemli şey, yanlış pozitiflerle çalışmaya kademeli ve sistematik bir şekilde yaklaşırsanız, bunda yanlış bir şey olmadığını anlamaktır. İlginç olmayan uyarıların büyük çoğunluğu yapılandırmadan sonra kaybolur ve yalnızca gerçekten dikkatli çalışma gerektiren yerler ve kodda bazı değişiklikler kalır.
Ayrıca herhangi bir zorlukla karşılaşılması durumunda müşterilerimize PVS-Studio kurulumunda her zaman yardımcı oluyoruz. Üstelik yanlış uyarıları kendimiz ortadan kaldırdığımız ve hataları düzelttiğimiz durumlar da vardı [] Her ihtimale karşı, bu genişletilmiş işbirliği seçeneğinin de mümkün olduğunu belirtmeye karar verdim :).
Cırcır yöntemi
Statik analizör uyarısını ortadan kaldırarak kod kalitesini kademeli olarak artırmaya yönelik ilginç bir yaklaşım daha var. Sonuç olarak, uyarıların sayısı yalnızca azalabilir.
Statik analizör tarafından verilen uyarıların sayısı kaydedilir. Kalite kapısı, artık yalnızca işlem sayısını artırmayan bir kodu girebileceğiniz şekilde yapılandırılmıştır. Sonuç olarak alarm sayısının kademeli olarak azaltılması süreci, analizörün ayarlanması ve hataların düzeltilmesiyle başlar.
Bir kişi biraz hile yapmak istese ve yeni kodundaki uyarıları ortadan kaldırarak değil, eski üçüncü taraf kodunu geliştirerek kalite kapısını geçmeye karar verse bile bu korkutucu değildir. Yine de cırcır tek yönde dönecek ve yavaş yavaş kusur sayısı azalacaktır. Bir kişi kendi yeni kusurlarını düzeltmek istemese bile komşu kodda bir şeyleri iyileştirmesi gerekecektir. Bir noktada uyarı sayısını azaltmanın kolay yolları sona eriyor ve gerçek hataların düzeltileceği bir nokta geliyor.
Bu metodoloji, Ivan Ponomarev'in çok ilginç bir makalesinde daha ayrıntılı olarak anlatılmaktadır ""kod kalitesini artırmakla ilgilenen herkese okumanızı tavsiye ederim.
Makalenin yazarının bu konuyla ilgili bir raporu da var: "".
Sonuç
Bu makaleden sonra okuyucuların statik analiz araçlarını daha fazla kabul edeceğini ve bunları geliştirme sürecine uygulamak isteyeceğini umuyorum. Sorularınız olursa her zaman hazırız Statik analizörümüz PVS-Studio'nun kullanıcıları ve uygulanmasına yardımcı olun.
Statik analizin gerçekten kullanışlı ve yararlı olup olamayacağı konusunda başka tipik şüpheler de vardır. Bu şüphelerin çoğunu "PVS-Studio statik kod analizörünü geliştirme sürecine dahil etme nedenleri" yayınında gidermeye çalıştım [].
İlginiz için teşekkür ederim ve gelin ve PVS-Studio analizörünü deneyin.
Ek bağlantılar
- Andrey Karpov.
- Wikipedia. .
- Andrey Karpov, Victoria Khanieva. .
- PVS-Stüdyo. Belgeler. .
- Andrey Karpov. .
- PVS-Stüdyo. Belgeler. .
- Ivan Andryashin. .
- Pavel Eremeev, Svyatoslav Razmyslov. .
- Andrey Karpov. .
Bu makaleyi İngilizce konuşan bir kitleyle paylaşmak istiyorsanız lütfen çeviri bağlantısını kullanın: Andrey Karpov. .
Kaynak: habr.com