Statik analizin tuzaklarından nasıl kaçınılır

Joel Test'te 11 puan alan bir şirkette çalışıyorum - en azından kağıt üzerinde.

Bununla birlikte, uygulamada, hiçbir şey beklendiği kadar iyi çalışmaz ve proje yarım aydır DEFCON 1'de . Şimdi, akranlarımın çoğu Pazar günü akşam 6'da eve dönebilirlerse mutlu olurlar.

Çalışmama beni etkileyen en iyi uygulamalardan biri statik analiz araçlarının kullanılmasıdır. Proje hem gcc -Wall uyarılarını hem de özel ve çok pahalı bir "C / C ++" aracını takip ediyor.

Gcc uyarıları, gerçek (çoğu zaman rahatsız edici ise) hatalara işaret etmekten daha sık yapılır.

Ancak, tescilli araçlar, örtülü kastlar ve bir dizgi değişmez boyutu gibi şeyleri listeler. Örtülü yayınlar da stil kitaplarında kara listeye alınır.

Standart uygulama, insanların her bir uyarıyı kapatmak için baskı altında olmasıdır. Bunun ağırlıklı olarak yanlış pozitif olan uyarıları hariç tuttuğunu unutmayın, sorun bu değildir.

Sonuç:

1. İnsanlar süreçteki gerçek sorunlu tür uyumsuzluklarını gizleyen her rvalue ve argümana tip dökümleri ekler.
2. İnsanlar bir hata ile ortaya çıkar veya farklı bir sorunlu dil özelliği kullanırlar. (Sizeof yerine strlen, strcpy yerine strncpy vb.)
3. Uyarılar susturulur.
4. Hata raporları yayınlanmaya başlar.

Ana nokta, orijinal kodun dil yetenekleri içinde güvenli oynayan insanlar tarafından çalışılması ve yazılması, ancak düzeltmelerin yapılmamasıydı.

Şimdi, bu şirketin kurtarılabileceğini sanmıyorum. Ancak, "pro" araçlarını kullanmak için daha iyi, tercihen çalışan bir yol olup olmadığını veya gelecekte karar verecek olan ben olursam bunları tamamen kullanmaktan kaçınmam gerekip gerekmediğini bilmek istiyorum.

Tüm programcıların hata yapamayan dahiler olduğunu varsaymayan bir çözüm. Çünkü eğer öyleyse, ilk etapta araçları kullanmaya gerek yoktur.

Bununla birlikte, uygulamada, hiçbir şey beklendiği kadar iyi çalışmaz ve proje yarım aydır DEFCON 1'de yer almaktadır. Şimdi, akranlarımın çoğu Pazar günü akşam 6'da eve dönebilirlerse mutlu olurlar.

Bu kesinlikle probleminizin iyi bir parçası. Bir yazılım mühendisi haftada 40 saatten fazla üretken çalışamaz. Bunun üzerine çıkarsanız, çalışma kapasitenize ciddi hasar verirsiniz - haftada 80 saat çalışmanın bile projeye çok az değer kattığı noktaya kadar ve bazen projeler gerileyebilir, çünkü takım daha fazla hata verir düzeltebilirler. Yarım yıl boyunca haftada 60 saat veya daha uzun bir süredir devam ediyorsanız, tüm ekibinizin uzun bir mola vermesi ve haftada 40 saat geri dönmesi gerekir. Çok fazla çalıştıkları için klavyeye dayanamayacak bir işgücü ile hiçbir şeyi çözemezsiniz .

Ancak, tescilli araçlar, örtülü kastlar ve bir dizgi değişmez boyutu gibi şeyleri listeler. Örtülü yayınlar da stil kitaplarında kara listeye alınır.

Gerçekten aracı tamamen bırakmanız veya yeniden yapılandırmanız / değiştirmeniz gerekir. Her örtük oyuncuya ilişkin uyarı, herkesin başa çıkması için çok fazladır.

Joel Test'te 11 puan alan bir şirkette çalışıyorum - en azından kağıt üzerinde.

Bu test yazılım şirketleri ile çok az ilgilidir. Bu konuda yutturmaca anlamıyorum. 12 puan alabilir ve hala% 100 bok programcılarına sahip olabilirsiniz. İnsanlar araçlardan çok daha önemli.

Ancak, tescilli araçlar, örtülü kastlar ve bir dizgi değişmez boyutu gibi şeyleri listeler. Örtülü yayınlar da stil kitaplarında kara listeye alınır. Standart uygulama, insanların her bir uyarıyı kapatmak için baskı altında olmasıdır. Bunun ağırlıklı olarak yanlış pozitif olan uyarıları hariç tuttuğunu unutmayın, sorun bu değildir.

Bu, tüm statik analizörlerle ilgili en büyük sorundur: çok fazla yanlış pozitif. Bunu ele almanın tek yolu , aracın belirli bir sorun için neden bir uyarı vermek üzere ayarlandığını ayrıntılı olarak öğrenmektir . Ancak o zaman bir uyarının yanlış olup olmadığı konusunda nitelikli varsayımlar yapabilirsiniz.

Örtük tipleştiriyor spesifik döküm için, çünkü resmen olarak bilinir C. iki (zekâlı) örtülü tip yükseltme kuralları nedeniyle C dilinde bazı çok yaygın ince ve tehlikeli böcek, orada olan tamsayı yükseltme kuralları ve olağan aritmetik dönüşümler . Profesyonel C programcılarının her on kişiden birinden daha azı bu iki kuralın ne yaptığını ve yapmadıklarını açıklayabilir. Yine de bu kurallar son derece temeldir ve herhangi bir normal C programındaki satırlar arasında binlerce kez uygulanır.

MISRA-C standardı, bu tehlikeli örtülü dönüşüm kurallarını açıklamak için bütün bir bölümü ayırdı ve daha sonra örtük dönüşümden kaynaklanan hataların nasıl önleneceğine dair oldukça karmaşık kurallar ekledi. Bunun piyasadaki tüm statik analizörler üzerinde oldukça etkisi oldu.

Herhangi bir C programcısına bu MISRA-C bölümünü okumasını veya en azından Google'da bahsettiğim ve onlar hakkında olabildiğince çok okuduğum iki promosyon kuralını öneriyorum. Statik analizörü ancak bu kurallar hakkında bilinmesi gereken her şeyi bildiğinizde göz ardı edebilirsiniz.

Şimdi, bu şirketin kurtarılabileceğini sanmıyorum. Ancak, "pro" araçlarını kullanmak için daha iyi, tercihen çalışan bir yol olup olmadığını veya gelecekte karar verecek olan ben olursam bunları tamamen kullanmaktan kaçınmam gerekip gerekmediğini bilmek istiyorum.

Tüm programcıların hata yapamayan dahiler olduğunu varsaymayan bir çözüm. Çünkü eğer öyleyse, ilk etapta araçları kullanmaya gerek yoktur.

Etrafında kolay bir yol yok. Asıl sorun aslında araç değil, belirsiz C dilidir. Kısa bir bakışta kolay bir dil gibi görünebilir, ancak çizgiler arasında çok sayıda mantıksız ve garip mekanizmalar var. Ayrıca, dilde yüzlerce tanımlanmamış / belirtilmemiş / ifade edilmemiş özel davranış da vardır. Çoğu öğrenmeli ve kaçınmalısınız.

Bu yüzden ya tüm bu belirsiz uyarıları anlayan deneyimli bir C programcısı olmalısınız ya da en az bir kişiden oluşan bir ekipte olmalısınız. Takımda tecrübeli olmayan bir grup genç programcı kiralayan şirketler bu araçları kullanmamalı ve yüksek bütünlüklü yazılım geliştirme ile çalışmamalıdır.

Sorunu nasıl düzeltebileceğinizi veya ilk etapta nasıl önleyeceğinizi sorduğunuz açık değildir. Ben ikincisini varsayıyorum.

Böcekleri tespit etmek ve önlemek için birincil yönteminiz olarak statik analize güveniyormuşsunuz gibi görünüyor. Belki birim testlere ve bellek denetleyicileri gibi dinamik araçlara odaklanmaktan daha iyi olurdu.

Özellikle yanlış pozitifleri baskılayamıyorsanız, çok sayıda yanlış pozitif üreten bir araca güvenmek kötü bir fikirdir. Yorgun / aşırı çalışan (veya tembel) programcıları uyarıları ortadan kaldırmak için "düzeltmeler" yapmaya teşvik eder. Yanlış pozitifleri (örneğin yorumlarla) seçici olarak bastıramazsanız veya kural setini uyarlayamazsanız, daha iyi bir araca ihtiyacınız vardır. Ya da en azından, sadece idareli kullanmalısınız.

İnsanların dikkatsiz olmaları ve / veya fazla çalışma nedeniyle hata yapma konusunda bir sorununuz olduğu anlaşılıyor. Belki de kod incelemelerinde daha fazla zaman / çaba harcamalıydın. Bu, programcıların dahilik olmadığı gözleminize doğrudan hitap eder.

Son olarak, gerçekçi olmayan süreler, yoksul insanların kaynak bulma ve / veya değişen gereksinimler altında acı çekiyor gibi görünüyorsunuz. Bu bir yönetim problemidir ve bu düzeyde ele alınmalıdır ... yoksa proje arızası ve personel verimliliğine ve moraline uzun vadeli hasar riski önemli ölçüde yüksektir.

User29079'un mükemmel cevabına ek olarak, soruna ek olan C dilinin bir eksikliğini daha eklemek istiyorum. Java'ya geçene kadar bu eksikliğin farkında değildim.

Bir uyarının amacı, yazarın ve kodun gelecekteki okuyucularının dikkatini, balık halinde olan bir şey olduğu gerçeğine getirmektir. Bu, bir kavram olarak gayet iyi: ne kadar çok uyarıyı etkinleştirirseniz, o kadar çok balık bulursunuz.

Ne ölü yanlış , zımbırtı balık her küçük, her ne pahasına bağlanmış olması gerekir ki kavramıdır kod değiştirerek . O OP açıklayan olduğunu soruna neden budur: aceleyle için çuvalladığınıdüşünecek girişimleri uyarılar gayet güzel çalışıyor değiştiren koduna göre dindirir.

Aynı zamanda, derlediğimiz her seferinde kodumuzun yüzlerce uyarıyı yaymasını istemiyoruz, çünkü çok geçmeden uyarılar anlamsız hale geliyor ve artık yeni uyarılara kimse dikkat etmiyor.

Yani, bu çelişkili hedeflerin bir örneği gibi görünüyor; bir çelişki.

Bu imkansız görünen soruna çok iyi bir çözüm, ifadeye dayalı olarak belirli bir uyarıyı ifade bazında seçici bir şekilde bastırabilmektir, böylece ne yaptığımızı gerçekten bildiğimizi belirtmek istediğimiz yerde tam olarak bastırabiliriz. herhangi bir kodu değiştirmek zorunda.

@SuppressWarnings( "" )Ek açıklama ile Java'nın buna güzel bir çözümü var . Diyelim ki, java'da denetlenmeyen bir dönüşüm yapıyorsanız , derleyici bunu dikkatinize çekmek için bir uyarı yayınlar, incelersiniz, bunun ne yaptığınızı bildiğiniz durumlardan biri olduğunu belirlersiniz, bu yüzden rahatsız edici ifadeden önce yalnızca onu izleyen ifadeyi @SuppressWarnings( "unchecked" )etkileyen bir ek açıklama gelir ve hayatınıza devam edersiniz.

Böylece, uyarı kaybolur, kod değiştirilmez ve sözdizimi vurgulamasıyla yeşil renkli olan bastırma ek açıklaması orada durur, ancak iffy dönüşümünün gerçekleştiğini belgelemek için yazarın vaat ettiği iyidir. (*) Herkes mutlu.

Java'da @SuppressWarnings(), yalnızca belirli bir parametrede verilebilecek belirli bir uyarıyı devre dışı bırakmak için ayrı ayrı parametreleri işlevlere önek olarak ekleyebilirsiniz.

Ancak, bildiğim kadarıyla, C, ifadeler üzerindeki uyarıları seçici olarak bastırmak için herhangi bir standart mekanizmayı desteklemedi ve kendi mülkiyet mekanizmalarını uygulayan bazı derleyiciler bunu, örneğin #pragma warning (nnn:N)Microsoft C direktifleri gibi kurnaz bir şekilde yaptı. Her iki bastırmak amacıyla tek deyimi için bir uyarı direktifleri iki satır ihtiyaç olduğunu ve bu uyarı takip ettiği mali tablolara için etkinleştirilmiş bırakın. Bu nedenle, C programcılarının, bu özel ifadedeki bu uyarının iyi olduğunu bilseler bile, bireysel bir bildirim temelinde bir uyarıyı bastırma alışkanlığını almaları pek olası değildir.

(*) birisi buna izin verirseniz, evdeki her programcının uyarı vermeden uyarıları bastırdığını iddia edebilir; Bunun cevabı, programcıların işlerini daha iyi yapmalarına yardımcı olmak için elinizden gelen her şeyi yapabilmenizdir, ancak sizi sabote etmeye aktif olarak karar verirlerse yapabileceğiniz hiçbir şey yoktur.

(Ayrıntıları bilmeden) şirketinizin daha önemli hatalar yaptığını söyleyebilirim ve bu sadece belirti: üretilen yazılımın etki alanını doğru bir şekilde belirleyemedi , takımı düzgün bir şekilde yönetemedi ve makul hedefler tanımlayamadı.

Ekibinizin yazdığı yazılım, insan hayatının bağlı olduğu kritik bir şeyse, statik analiz araçları önemli ve yararlıdır. Parayla ölçülen bir hatanın "maliyeti" (ne kadar alaycı olduğunu göz ardı ederek) yüksek olduğundan, iş için gerekli özel araçlar vardır. Dil özelliklerini güvenle kullanmak için hem C hem de C ++ için yönergeler vardır (kaçınılması gereken ve kaçınılması gerekenleri okuyun).
Bununla birlikte, çalışanların Pazar günü çalışması çok kötü bir fikirdir, sağladığınız bağlamın ötesinde, özensiz çalışmanın seyrek olmadığını tahmin ediyorum. Bu durumda, sorun çok çokve yönetiminiz "daha iyi" araçları kullanarak çözmeye çalışıyor. Ne yazık ki, işler böyle çalışmaz. Düzeltmeye bile yakınsam, başka bir iş aramaya başladığınızı düşündüren kadar ileri giderdim. Görev açısından kritik önem taşıyan yazılımlar, dava umutlarından bahsetmemek yerine, sizi rahatsız edebilecek ve profesyonel itibarınızı bozabilecek bir şeydir.

Öte yandan, ekibiniz çok daha az kritik bir şey yazıyorsa, yanlış pozitif oranı yüksek 'statik analiz' araçları sizi yavaşlatır ve belirttiğiniz gibi, insanlar buna genellikle etkinliklerinde yerel maksimumu bulmak, bu durumda temel nedeni düzeltmeye çalışmak yerine, sadece uyarıları dolaştırmak yoluyla. Yani sizin durumunuzda, bu araçları kullanmak kaynak kodun kalitesini düşürebilir ve genellikle bunlardan kaçınılmalıdır.

Eğer siz bazı C veya C ++ kod yazıyor bir yazılım ekibi yönetmesi gereken, ana proje hedefleri belirlemek ilk derdim. Hatasız kod yazmak büyük önem taşıyorsa (örneğin, iOS ve Android için yeni süper harika sosyal uygulama buna uymuyorsa ), statik analiz kullanın, hatta resmi şartname ve resmi doğrulama kadar ileri gidin. Ancak durum buysa, iyi programcıların seçilmesi ve uygun iş yükü ve uygun 40 saatlik hafta ile aklı başında bir ortamda çalışmasını sağlamak çok daha önemlidir.

İnsanlar köle gibi muamele görürlerse (ve tatillerimi işgal eden biri tam olarak budur) sorumlu bir şekilde çalışamazlar ve iyi programcılar, daha iyi bilmedikçe (ve iyi iseler, şansları onlar yapar).

Alt nokta: Hedeflerinizi belirleyin, ardından araçları ve kullandığınız süreci belirleyin, mevcut araçların (kötü hedefler) süreci (kötü) yönetimin sizi zorlamak isteyebileceği şekilde tanımlamasına izin vermeyin.

K.steff'in cevabında belirtildiği gibi, 'C' için statik analiz araçları, kritik bir durumda yazılım (uçak yazılımı) oluşturuyorsanız yararlıdır ve ilk günden itibaren (tekrar üretilemeyen bir hata oluştuğunda aylarca geliştirildikten sonra değil) kullanılmalıdır. ).

Bu tür araçları geliştirme sürecinin sonlarında kullanmak genellikle sürecin başlarında kötü tasarım seçeneklerinin bir işaretidir.

Kritik olmayan yazılımlarda, bu tür araçlar aşağıdakiler için yararlıdır: -
risk yönetimi, onları kullanışlı hissettirmek (bir şey yaptık, yazılımı düzeltmek için çok para harcadık). Onlara powerpoint raporlarında gerçekleştirmesi kolay eylemler verir).
- 'Zehirli' geliştiricileri meşgul edin. Aracı yapılandırmasına ve araç sonuçlarını analiz etmelerine izin verin, böylece kötü hatalarını düzeltmek için zamanınız olabilir.
-kodlama kurallarını uygular. Bu durumda ilk günden kullanılmalıdır. Ancak iyi bir kod inceleme aracı daha iyi bir seçim olabilir.

Benim düşüncem, bu tür pahalı, zaman alıcı araçlardan kaçınmanız veya bunları 'zehirli' insanları meşgul etmek için kullanmanız gerektiğidir.

Joel Test'te 11 puan alan bir şirkette çalışıyorum - en azından kağıt üzerinde.

Joel Testi ile onaylama iyi uygulamaların bir ölçüsü değildir; Joel Testi tarafından geçersiz kılma, kötü / eksik uygulamaların bir ölçüsüdür. Başka bir deyişle, gerektiği gibi görülebilir, ancak yeterli değildir.

Şimdi, akranlarımın çoğu Pazar günü akşam 6'da eve dönebilirlerse mutlu olurlar.

Bir yönetim sorununuz olduğu anlaşılıyor. Sistematik fazla mesai, işleri halletmenin bir çözümü değildir; bir şey varsa, işleri çalışıyor ve teknik borç biriktirmiş gibi göstermek için bir çözümdür .

Şimdi, bu şirketin kurtarılabileceğini sanmıyorum. Ancak, "pro" araçlarını kullanmak için daha iyi, tercihen çalışan bir yol olup olmadığını veya gelecekte karar verecek olan ben olursam bunları tamamen kullanmaktan kaçınmam gerekip gerekmediğini bilmek istiyorum.

Evet, statik kod analizini akılcı bir şekilde kullanmanın bir yolu var.

Genellikle çok değer sağlayabilirler. Sadece, derleyici uyarıları gibi, bir statik analiz aracının (en fazla), hata raporları değil, hiçbir şeyin yanlış gittiğine dair ipuçları verebileceğini ve hiçbir kesinliğin olmadığını hatırlamanız gerekir.

Karar vericilerinizin statik analiz bayraklarını uygulama kusurlarıyla karıştırdığı anlaşılıyor.

Örtülü yayınlar da stil kitaplarında kara listeye alınır.

Bu, statik bir analiz sorunu değil, bir yönetim yeterlilik sorunu gibi görünür.

Sonuç:

İnsanlar süreçteki gerçek sorunlu tür uyumsuzluklarını gizleyen her rvalue ve argümana tip dökümleri ekler.

İnsanlar bir hata ile ortaya çıkar veya farklı bir sorunlu dil özelliği kullanırlar. (Sizeof yerine strlen, strcpy yerine strncpy vb.)

Uyarılar susturulur.

Hata raporları yayınlanmaya başlar.

Tüm bunlar, periyodik raporların iyi görünmesini sağlamanın yollarıdır, koddaki sorunları düzeltmenin yolları değildir (yine bir yönetim yeterlilik sorununuz olduğu anlaşılıyor).