it-swarm.asia

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

Java Eclipse kullanarak Java = ===) Derleyici ayarlarından bir dizi uyarıyı zaten kapattık ve projenin hala 10.000'den fazla uyarısı var.

Tüm uyarıları ele almaya, mümkünse hepsini düzeltmeye çalıştığım ve güvenli görünen ve güvenli olduğu düşünülen kişiler için büyük bir destekçiyim. (Tüm uygulanan/geçersiz kılma yöntemini @Override olarak işaretleme ile dini takıntım için de geçerlidir). Benim en büyük argümanım genellikle uyarıların derleme zamanı sırasında olası hataları bulmanıza yardımcı olmasıdır. 100'den 99'unda belki, uyarılar önemsizdir, ancak bence bir zamanlar büyük bir hatayı önlediği için kaydettiği kafa çizik, buna değer. (Benim diğer neden kod temizliği ile görünür OKB).

Ancak, takım arkadaşlarımın çoğu umursamıyor gibi görünüyor. Aralarında karşılaştığımda bazen uyarıları düzeltirim (ancak bir iş arkadaşı tarafından yazılan koda dokunduğunuzda zor olduğunu bilirsiniz). Şimdi tam anlamıyla sınıflardan daha fazla uyarıyla, uyarıların avantajları çok minimize edilir, çünkü uyarılar çok yaygın olduğunda, kimse hepsine bakmaya zahmet etmez.

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

Teşekkürler

(Not: Bu soruyu nihayet göndermem için beni neyin harekete geçirdiğini belirtmeyi unuttum, uyarıları üretildiklerinden daha yavaş düzelttiğimi ne yazık ki fark ettim)

51
user32020

İki şey yapabilirsiniz.

  1. Uyarıların bir sebepten kaynaklandığına dikkat edin. Derleyici yazarları onları kötü niyetli oldukları için koymaz. Sektörümüzdeki insanlar genellikle yardımcı olur. Birçok uyarı faydalıdır.

  2. Yoksayılan uyarılardan kaynaklanan muhteşem hataların geçmişini toplayın. "Derleyici uyarılarına dikkat edin" için yapılan web araması bazı fıkralar döndürür.

@Override İle olan takıntılarınız bir "takıntı" değildir. Bu iyi bir şey. Hiç bir yöntem adını yanlış yazdınız mı?

37
Ray Toal

İlgili okuma burada . C++, ancak yine de alakalı. Özellikle bu örneği seviyorum (kod yorumu benim):

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)
}

Çoğu zaman, bir uyarı, bir tasarım kusurunu izlemenize ve düzeltmenize (örneğin safe yazım hatası) uygulama ile bir hata ile kilitlenen uygulama arasındaki fark anlamına gelir. varsayımlarda bulunmak ve sonra aslında yanlış veya hatalı bir şekilde davranmak ( güvensiz daktiloda böyle olur). Benzer şekilde, kod optimizasyonu olarak kabul edilebilecek (erişilemeyen kod blokları, kullanılmayan değişkenler) veya test edilemeyen durumları, örneğin C++ için yukarıdaki örnekte olduğu gibi kaldırılabilen ham veya ölü kodu da işaret ederler. Bu örneğin Java'da derleme zamanı hatasına neden olduğunu unutmayın.

Bu nedenle, uyarıları düzeltmenin (en azından) yönetim için birkaç avantajı vardır:

  1. Kodun, şirketin imajı ve müşterilerinin verilerini nasıl ele aldığı ile ilgili daha üst düzeylere kadar büyük bir anlaşma (tm) olması gereken, kullanıcı tarafından girilen verilerle uygunsuz davranma şansı daha düşüktür. Bir kullanıcının aptalca bir şey yapmasını önlemek için çarpmak, çökmemek ve yapmasına izin vermekten daha iyidir.
  2. Personeli yeniden karıştırmak isterse, insanlar uyarısız bir kod tabanına girebilirler (ve çıldırmazlar veya çok fazla şikayet etmezler. Belki de bu, devam eden homurdanma 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üşleri azaltacaktır.
  3. Derleyici uyarılarını kaldırarak kodun optimize edilmesi, çalışma süresinde önemli bir iyileşme sağlamazken, test söz konusu olduğunda çok sayıda puanı iyileştirecektir:
    • Kod kapsamı puanları muhtemelen artacaktır.
    • Test sınırı ve geçersiz test senaryoları muhtemelen daha sık başarılı olacaktır (yukarıda belirtilen güvenli diğer şeylerin yanı sıra.
    • Bir test senaryosu başarısız olduğunda, bunun kaynak dosyadaki derleyici uyarılarından birine bağlı olup olmadığını düşünmeniz gerekmez.
    • Sıfır derleyici uyarılarının binlerceden daha iyi olduğu kolayca tartışılabilir. Kodun kalitesi hakkında hiçbir uyarı veya hata söz konusu değildir, bu nedenle kod kalitesinin daha az uyarı olduğunu geliştirdiğini iddia edebilirsiniz.
  4. Derleyici uyarılarınız yoksa ve bir veya daha fazla tanıtıldıysa, bunların kod tabanında kimin görünmesine neden olduğunu bilmek çok daha kolaydır. "Uyarı yok" politikanız varsa, bu onların işlerini düzgün yapmayan kişileri tanımlamalarına yardımcı olabilir, belki de? Kod yazmak sadece bir şeyin işe yaraması değil, aynı zamanda iyi çalışması ile ilgilidir.

Hala sadece proje yönetimi hakkında çok az şey bilen bir genç geliştirici olduğumu unutmayın, bu yüzden yanlış bir şey söylediysem lütfen düşüncemi düzeltin ve beni varlığımdan aşağı indirmeden önce düzenleme şansı verin :)

12
user31713

Geçmişte benzer özelliklere sahip bir proje üzerinde çalıştım. Bu özellikle başlangıçta Java 1.4 yazılmıştır. Java 5 çıktı), her biri için derleyici tarafından atılan uyarıların sayısını hayal edebilir Koleksiyonlar API'sinin kullanımı.

Jenerik ilaç kullanmaya başlayarak tüm uyarılardan kurtulmak oldukça zaman alacaktı. Bu, hesaba katılması gereken bir faktördür, ancak birisini (özellikle yöneticiniz) onarılması gerektiğine ikna etmeniz gerektiğinde, gibi sert verilere ihtiyacınız olacaktır.

eski veya standartlara uygun olmayan kodda hatalar için harcanan süre (standart, projenizin kodlama standardıdır) kaçınılmış olabilir.

"Belirli" uyarıları görmezden gelerek zaman ve para kaybettiğinizi gösteren bir fatura sunmaya devam edebilirsiniz. Kilit nokta, tüm uyarıların en azından hemen değil, bakmaya değmemesidir; 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, hataları giderirken hata izleyicide, söz konusu hatanın bir uyarıyı göz ardı etmeyerek (veya bir CI veya derleme sisteminiz varsa PMD veya FindBugs çalıştırarak) önlenebileceğine dair notlar alabilirsiniz. Derleyici uyarılarını dikkate alarak düzeltilebilecek yeterli sayıda hata olduğu sürece, derleyici uyarılarına bakma noktanız geçerli olacaktır. Aksi takdirde, bu bir ticari karardır ve genellikle bu savaşa karşı savaşmak için zaman ayırmaya değmez.

7
Vineet Reynolds

Başarılı olursanız ve ekibiniz uyarılara uymaya karar verirse, adım adım bir yaklaşım izlemelisiniz. Hiç kimse bir seferde 10000 uyarı yapamaz ve yapmayacaktır. Böylece en önemlilerini (yüksek olasılıklı hata olanları) seçebilir ve daha az önemli olanları devre dışı bırakabilirsiniz. Sabitlendiyse uyarı seviyesini tekrar artırın. Ayrıca, neredeyse her zaman bir hata olan kod konusunda uyaran FindBugs ile başlayabilirsiniz.

2
Heiko Schmitz

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 bunun yapılacak en iyi şey olduğuna ikna edin ve zorunlu yapın. Sonra düzeltmeleri gerekiyor.

1'in artık sizin durumunuzda mümkün olmadığına inanıyorum. Ayrıca, bunun verimlilik çıktısında göstereceği uyarıların sayısı nedeniyle bu kadar uzun sürecektir, böylece yönetimin zaten bilmesi gerekir.

Benim önerim şudur: Patronu ele geçir, onu bir bomba olduğuna ikna et ve resmi politika yapmasını sağla.

Size tamamen katılıyorum, derleme uyarılarını mümkün olduğunca temizlemek en iyi uygulamadır. Ekibinizin Eclipse'i geliştirme aracı olarak kullandığından bahsettiniz. Eclipse, kodu temizlemenize ve kod stili tutarlılığını sağlamanıza yardımcı olacak çok iyi bir araçtır.

  1. her bir Java proje için '' Eylemi kaydet '' tanımlayın (sanırım kimsenin bu tür temizlik konusunda itirazları yoktur).
  2. her proje için projeye özgü derleme seçeneklerini tanımlar. Örneğin, derleme düzeyi (genelle ilgili uyarıları temizlemek için kodunuzun 1.4 ile uyumlu olması gerekiyorsa), atamanın herhangi bir etkisi yoktur (örn. 'X = x') vb. Siz ve ekip arkadaşınız bu öğeler için bir anlaşma yapabilirsiniz ve derleme hatası için anlaşmanızın ardından Eclipse bunları geliştirme aşamasında 'Hata' olarak bildirirsiniz.

Eclipse, .settings klasörü altında bu tercih için bazı özellikler dosyaları oluşturur, bunları diğer Java projelerine kopyalayabilir ve kaynak kodunun bir parçası olarak SCM'ye teslim edebilirsiniz.

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

1
Kane

Onlara, bunların çoğunun önemsiz uyarılar olduğunu söyleyebilirim ve bunları listeden çıkarmamız çok önemlidir. Böylece, kalabalıktaki gerçek önemli uyarıyı kaçırmayacağız, olduğu gibi!

1
WinW

Onları ikna etmeye çalışırken çok fazla sabra ihtiyacınız olacak, çift programlama yaparken uyarıları kaldırmak başkalarının bu alışkanlığı almasına yardımcı olacaktır. Onları Etkili Java 'Madde 24: Kontrol edilmeyen uyarıları ortadan kaldırın' (genel toplama için) 'i okumalarını önerin.

0
Mehul Lalan

Burada etkili bir yaklaşım, projeyi otomatik olarak oluşturan ve herkes kodları kontrol ettiğinde testleri çalıştıran bir Sürekli Entegrasyon sunucusu kurmak olacaktır. Bunu zaten kullanmıyorsanız, olmalısınız ve başkalarını bunu yapmanın yararlarına ikna etmek çok zor değil.

  1. Yönetim/ekip bunu yapmanın faydalarına ikna eder (kötü yapıların dağıtılmasını önler, hataları erken bulur, özellikle yazılımın diğer bölümlerini yanlışlıkla etkileyen, regresyon testini sürdürür, erken ve sık sık test eder, vb.)

  2. Tüm testleri geçen CI sunucusunu kurun (testleriniz yoksa, hızlı bir tane yazın, böylece herkes yeşil olduğunu görür).

  3. Her yapının durumu ile ilgili e-postaları veya diğer bildirimleri ayarlayın. Burada kodu kimin kontrol ettiğini, değişikliğin ne olduğunu (veya işlemin bağlantısını) 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. Uyarılar varsa testlerin başarısız olması için CI sunucusunu güncelleyin. Bu yönetim ve takım liderleri tarafından takımın disiplinini sistematik bir şekilde arttırmak olarak görülecektir ve dışarı çıkan tüm başarısızlık e-postalarından kimse sorumlu olmak istemez.

  5. (isteğe bağlı), yapının durumunu ve kimin kırdığını/düzelttiğini göstermek için bazı görünür gösterge tabloları, lav lambaları, yanıp sönen ışıklar vb. ekleyerek bununla Nice ve geeky'yi edinin.

0
Ben Taitelbaum