Takım arkadaşlarımı, derleyici uyarılarını göz ardı etmememiz gerektiğine nasıl ikna edebilirim?

Java'da eclipse kullanarak büyük bir proje üzerinde çalışıyorum (daha çok bağımlılık yönetimi nedeniyle kolayca ayrıştırılamayan düzinelerce küçük projenin karışık bir birleşimi gibi). Derleyici ayarlarından bazı uyarıları zaten kapattık ve projede hala 10.000'in üzerinde uyarı var.

Tüm uyarıları ele almaya, mümkünse hepsini düzeltmeye ve güvenli görünen ve güvenli görünenlere karşı onları bastırmaya çalıştığım için büyük bir savunucuyum. (Aynı tüm uygulanan / geçersiz kılınan yöntemi @Override olarak işaretleme konusundaki dini takıntım için de geçerli). En büyük argümanım, genel olarak uyarıların, derleme süresi boyunca olası hataları bulmanıza yardım etmesidir. Belki de 100 kere 99'luk uyarılar önemsizdir, ama bence kafam büyük bir hatayı önlediği için bir kez tasarruf edeceğini düşünüyor, hepsi buna değer. (Diğer nedenim kod temizliği olan görünür OKB'im).

Ancak, takım arkadaşlarımın çoğu umursamıyor. Arada sırada rastlandığımda uyarıları düzeltirim (ancak bir iş arkadaşınız tarafından yazılan koda dokunduğunuzda zor olduğunu biliyorsunuz). Şimdi, gerçek anlamda sınıflardan daha fazla uyarı ile, uyarıların avantajları çok azaltılabilir, çünkü uyarılar çok yaygın olduğunda, hiç kimse bunlara bakmaktan rahatsız olmaz.

Takım arkadaşlarımı (veya olabilecek güçleri) uyarıların ele alınması gerektiği (veya tamamen araştırıldığı zaman bastırılması) gerektiği konusunda nasıl ikna edebilirim? Yoksa kendimi deli olduğuma ikna etmeli miyim?

Teşekkürler

(PS, nihayetinde bu soruyu göndermeme neden olan şeyi söylemeyi unuttum, uyarıları üretildiklerinden daha yavaş düzelttiğimi üzülerek farkettim.)

İki şey yapabilirsin.

1. Uyarıların bir nedeni olduğuna dikkat edin. Derleyici yazarlar onları içine almazlar çünkü kötü ruhlular. Endüstrimizdeki insanlar genellikle yardımcı olur. Birçok uyarı faydalıdır.

2. İhmal edilen uyarılardan kaynaklanan muhteşem başarısızlıkların tarihini toplayın. "Derleyici uyarılarına dikkat edin" için bir web araması bazı fıkraları döndürür.

Senin takıntın @Overridebir "takıntı" değil. Bu iyi bir şey. Hiç bir yöntem adını yanlış yazdınız mı?

İlgili okuma burada . C ++, ancak yine de alakalı. Özellikle bu örneği beğendim (kod açıklaması benimdir):

int searchArray(int to_search[], int len, int to_find)
{
    int i;
    for( i = 0; i < len; ++i )
    {       
        if ( to_search[i] == to_find )
        {
            return i;
        }
    }
    // should be returning designated 'not found' value (0, -1, etc)
}

Bir uyarı, çoğu zaman, bir tasarım hatasını izlemenize ve bunu (örneğin güvenli tip belirleme gibi) düzeltmenize ya da uygulamada varsayımlarda bulunmaya başlamanıza ve daha sonra yanlış bir davranışta bulunmanıza yardımcı olacak bir hatayı düzelterek uygulama arasındaki fark anlamına gelir. veya hatalı şekilde ( güvensiz tiplemede olduğu gibi). Benzer şekilde, aynı zamanda, C ++ için yukarıdaki örnekte olduğu gibi, testte ortaya çıkacak durumlar için, kod optimizasyonu olarak kabul edilebilecek (erişilemeyen kod blokları, kullanılmayan değişkenler) kaldırılabilen (veya erişilemeyen kod blokları, kullanılmayan değişkenler) kodsuz veya ölü kodlara işaret ederler. Bu örnekte, Java'da derleme zamanı hatasıyla sonuçlandığını unutmayın.

Dolayısıyla, uyarıların düzeltilmesi (en azından) yönetim için birçok avantaja sahiptir:

1. Kullanıcı imajı ve şirketin imajı ve müşterilerinin verilerini nasıl ele aldığı ile ilgili endişeleri yüksek olanlara göre, kullanıcı tarafından girilen verilerde kodun yanlış davranış gösterme olasılığı daha düşüktür. Bir kullanıcının aptalca bir şey yapmasını önlemek için çarpmak, çarpmamak ve yapmalarına izin vermekten daha iyidir.
2. Personeli görevlendirmek istiyorlarsa, insanlar uyarı içermeyen bir kod tabanına girebilirler (ve bu kadar çıldırmamak ya da şikayet etmemek). Belki bu, devam eden huysuzluk miktarını veya X Takımının Y Projesine katkısının sürdürülebilirliği veya kalitesi hakkındaki görüşlerini azaltacaktır.
3. Derleyici uyarılarını kaldırarak kodu optimize etmek, çalışma süresinde önemli bir ilerleme göstermemekle birlikte, test söz konusu olduğunda sayısız puanları artıracak:
   • Herhangi bir kod kapsamı puanı muhtemelen artacaktır.
   • Test sınırı ve geçersiz test durumları muhtemelen daha sık başarılı olacaktır (yukarıda belirtilen güvenli tip belirleme nedeniyle , diğer şeylerin yanı sıra).
   • Bir sınama durumu başarısız olduğunda, bunun kaynak dosyadaki derleyici uyarılarından biri yüzünden olup olmadığını düşünmeniz gerekmez.
   • Sıfır derleyici uyarılarının binlercedan daha iyi olduğu kolayca tartışılabilir. Hiçbir kod veya hata kodun kalitesi hakkında konuşmaz, bu nedenle kod kalitesinin daha az uyarı bulunduğunu söyleyebilirsiniz.
4. Derleyici uyarıları yoksa ve bir veya daha fazla tanıtıldıysa, kod bazında kimin görünmesine neden olduğunu bilmek çok daha kolaydır. Eğer bir "uyarı yok" politikanız varsa, bu belki de işlerini doğru yapmayan insanları tespit etmelerine yardımcı olur, belki de? Kod yazmak sadece bir şeyin çalışmasını sağlamakla ilgili değildir, aynı zamanda iyi çalışmasını sağlamakla ilgilidir .

Hala proje yönetimi hakkında çok az şey bilen küçük bir dev olduğumu unutmayın, bu yüzden yanlış bir şey söylersem lütfen düşüncemi düzeltin ve beni varoluştan düşürmeden önce düzenleme şansı verin :)

Geçmişte benzer özelliklere sahip bir proje üzerinde çalıştım. Özellikle bu, ilk olarak Java 1.4 ile yazılmış. Jenerikler içeren Java 5 çıktığında, derleyici tarafından Koleksiyonlar API'sinin her kullanımı için atılan uyarıların sayısı tahmin edilebilir.

Generikleri kullanmaya başlayarak tüm uyarılardan kurtulmak epey zaman alabilirdi. Bu hesaba katılması gereken bir faktördür, ancak birini (özellikle yöneticinizi) tamir etmesi gerektiğine ikna etmeniz gerektiğinde,

Eski veya standart olmayan uyumlu bir kodda (standart projenizin kodlama standardı) hatalardan kaçınılması gereken zamandır.

“Belirli” uyarıları göz ardı ederek zaman ve parayı nasıl kaybettiğinizi gösteren bir fatura sunmaya devam edebilirsiniz ve birileri bu fikri anlayacaktır. Önemli olan, tüm uyarıların en azından hemen değil, dikkate almaya değer olmadığı; daha basit bir deyişle, hemen ele alınması gereken uyarıların önceliğini belirlemeniz gerekecektir. Başlamak için, projenizde gördüğünüz hatalarla ilgili olanları düşünün.

Ayrıca hata izleyicide, hataları düzelttiğinizde, söz konusu hatanın bir uyarıyı göz ardı etmeyerek (veya bir CI veya sisteminiz varsa belki PMD veya FindBugs çalıştırarak) önlenebileceği konusunda notlar alınabileceğini not edebilirsiniz. Derleyici uyarılarını dikkate alarak tespit edilebilecek yeterli sayıda hata olduğu sürece, derleyici uyarılarına bakma noktanız geçerli olacaktır. Aksi halde, bu bir iş kararıdır ve bu savaşla savaşmak için harcadığınız zamana değmez.

Başarılıysanız ve ekibiniz uyarılara uymaya karar verirse, adım adım yaklaşmalısınız. Hiç kimse bir seferde 10000 uyarı alamaz ve alamaz. Böylece en önemli olanları (yüksek olasılıklı olanlar) seçebilir ve daha az anlamlı olanları devre dışı bırakabilirsiniz. Sabitlerse, uyarı seviyesini tekrar yükseltin. Ek olarak, neredeyse her zaman bir hata olan kodla ilgili uyarı veren FindBugs ile başlayabilirsiniz.

Sizinle tamamen aynı fikirdeyim, derleme uyarılarını olabildiğince fazla temizlemenin en iyi yoludur. Ekibinizin Eclipse'i geliştirme aracı olarak kullandığından bahsettiniz. Eclipse, kodu temizlemenize ve kod stili tutarlılığını sağlamanıza yardımcı olmak için çok iyi bir araçtır.

1. Her Java projeniz için, kod biçimlendirme, kullanılmayan yerel değişkenler, içe aktarma işlemlerini düzenleme gibi 'eylemi kaydet' tanımlayın (kimsenin bu tür temizlik işlemlerine itirazları olmadığını düşünüyorum).
2. Her proje için projeye özgü derleme seçeneklerini tanımlar. Örneğin, derleme seviyesi (kodunuzun jenerikle ilgili uyarıları temizlemek için 1.4 ile uyumlu olması gerekiyorsa), atamanın etkisi yoktur (örn. 'X = x') vb. Siz ve takım arkadaşınız bu öğeler için bir anlaşma yapabilir ve Eclipse, derleme hatası için bir anlaşma yaptıktan sonra bunları geliştirme aşamasında 'Hata' olarak rapor eder.

Eclipse, .settings klasörü altındaki tercihler için bazı özellik dosyaları yaratacaktır, bunları diğer Java projelerine kopyalayabilir ve kaynak kodun bir parçası olarak SCM'ye teslim edebilirsiniz.

Eclipse geliştiricilerinin bunu nasıl yaptığını görmek için Eclipse kodunu kontrol edebilirsiniz.

Tüm uyarılardan kurtulmanın iki yolu var (ve ince bir hatayı gizleyebileceğini kabul ediyorum):

1. Tüm ekibi bunun yapılacak en iyi şey olduğuna ikna edin ve düzeltmelerini sağlayın.
2. Patronunuzu, yapılacak en iyi şey olduğuna ikna edin ve zorunlu hale getirin. O zaman düzeltmeleri gerek.

Davanızda 1'in artık mümkün olmadığına inanıyorum. Ayrıca, bunun verimlilik çıktısında göstereceği uyarıların sayısı nedeniyle çok uzun sürecektir, böylece yönetim yine de bilmelidir.

Öyleyse benim önerim: Patronla konuşun, onu bir gıdıklama bombası olduğuna ikna edin ve resmi bir politika yapmasını sağlayın.

Sadece bunların çoğunun önemsiz uyarılar olduğunu ve bunları listeden çıkarmamızın çok önemli olduğunu söyleyebilirim. Böylece kalabalığın içindeki gerçek önemli uyarıyı kaçırmayacağız!

Onları ikna etmeye çalışırken çok fazla sabra ihtiyacınız olacak, çift programlama yaparken uyarıların kaldırılması diğerlerinin alışkanlık edinmelerine yardımcı olacaktır. Etkili Java 'Madde 24: Denetlenmeyen uyarıları kaldırın' (genel koleksiyon için) okumalarını önerin. Ve muhtemelen insanlar tavsiyenize uymadığında birçok örneği görmezden gelin;)

Buradaki etkili bir yaklaşım , projeyi otomatik olarak inşa eden ve herhangi bir kişi kodu kontrol ettiğinde testleri çalıştıran bir Sürekli Entegrasyon sunucusu kurmak olacaktır . Zaten bunu kullanmıyorsanız, kullanmalısınız ve başkalarını da bunu yapmanın yararlarına ikna etmek çok zor değil.

1. Yönetim / ekip liderlerinin bunu yapmanın yararlarına ikna edin (kötü inşaatların kurulmasını önleme, hataları erken bulma, özellikle yazılımın diğer kısımlarını yanlışlıkla etkileyenler, regresyon testlerini sürdürme, erken ve sık test etme, vb.)

2. CI sunucusunu tüm testler geçtikten sonra kurun (testleriniz yoksa, herkesin yeşil olduğunu görmesi için hızlı bir test yazın).

3. Her derlemenin durumu hakkında e-posta veya diğer bildirimleri ayarlayın. Kodda kimin kontrol ettiği, değişikliğin ne olduğu (veya taahhüdün bağlantısı) ve yapının durum + çıktısını dahil etmek önemlidir. Bu, hem başarılar hem de başarısızlıklar için ekip çapında görünürlük sağladığından, önemli bir adımdır.

4. Herhangi bir uyarı varsa testlerin başarısız olmasını sağlamak için CI sunucusunu güncelleyin. Bu, yönetim tarafından yönetilecek ve ekip önderliğinde, ekibin disiplinini sistematik bir şekilde arttırıyor ve hiç kimse dışarı çıkan tüm e-postaların gönderilmesinden sorumlu olmak istemiyor.

5. (isteğe bağlı) yapının durumunu ve onu kimin kırdığını / düzelttiğini göstermek için bazı görünür panolar, lav lambaları, yanıp sönen ışıklar vb.