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)
İki şey yapabilirsiniz.
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.
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ı?
İ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:
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 :)
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.
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.
Tüm uyarılardan kurtulmanın iki yolu var (ve ince bir hatayı gizleyebileceğini kabul ediyorum):
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.
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.
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!
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.
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.
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.)
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).
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.
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.
(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.