Kod kapsamı kullanılmayan yöntemleri vurgulamaktadır - ne yapmalıyım?

Var olan bir Java projesinin kod kapsamını arttırmakla görevlendirildim.

Kod kapsamı aracının ( EclEmma ) hiçbir zaman bir yerden çağrılmayan bazı yöntemleri vurguladığını fark ettim .

İlk tepkim, bu yöntemler için birim testleri yazmak değil , onları bölüm müdürüme / ekibime vurgulamak ve neden bu işlevlerin neden orada olduğunu sormak.

En iyi yaklaşım ne olurdu? Onlar için birim testleri yaz veya neden orada olduklarını sorguluyor musun?

1. Silin.
2. Teslim Et.
3. Unutmak.

Gerekçe:

1. Ölü kod öldü. Tanımı gereği hiçbir amacı yoktur. Bir noktada bir amacı olabilirdi, ama bu gitti ve kodun gitmesi gerekiyordu.
2. Sürüm kontrolü, (benim deneyimime göre) birinin daha sonra bu kodu aramaya devam etmesiyle ortaya çıkan nadir benzersiz olayın alınabilmesini sağlar.
3. Yan etki olarak, kod kapsamını hiçbir şey yapmadan anında geliştirirsiniz (ölü kod test edilmedikçe, bu nadiren gerçekleşmez).

Yorumlardan kaçınmak: Orijinal cevap, kodun şüphesiz ölü olduğunu doğruladığınızı kabul etti. IDE'ler yanılabilir ve ölü görünen kodun aslında çağrılabileceği çeşitli yollar vardır . Kesinlikle emin değilseniz bir uzmana getirin.

Diğer tüm cevaplar, söz konusu yöntemlerin gerçekten kullanılmadığı varsayımına dayanmaktadır. Ancak, soru, bu projenin kendi kendine yeterli olup olmadığını veya bir tür kütüphanenin olup olmadığını belirtmedi.

Söz konusu proje bir kütüphane ise, görünüşte kullanılmayan yöntemler projenin dışında kullanılabilir ve bunları kaldırmak diğer projeleri bozabilir. Kütüphanenin kendisi müşterilere satılıyorsa veya kamuya açık hale getiriliyorsa, bu yöntemlerin kullanımını takip etmek bile mümkün olmayabilir.

Bu durumda, dört olasılık vardır:

• Yöntemler özel veya paket özel ise, güvenle kaldırılabilir.
• Metotlar halka açıksa, özellikleri eksiksiz olmaları için fiili kullanım olmadan bile gerekçeleri haklı görülebilir. Yine de test edilmeleri gerekir.
• Metotlar halka açık ve gereksiz ise, bunların kaldırılması zor bir değişiklik olacaktır ve kütüphane anlamsal versiyonlamayı takip ederse , buna yalnızca yeni bir ana versiyonda izin verilir.
• Alternatif olarak, halka açık yöntemler de kullanımdan kaldırılabilir ve daha sonra kaldırılabilir. Bu, API tüketicilerinin bir sonraki ana sürümde kaldırılmadan önce kullanımdan kaldırılan işlevlerden geçiş yapması için biraz zaman verir.

İlk önce kod kapsamı aracınızın doğru olduğunu kontrol edin.

Arayüze referanslar aracılığıyla çağrılan yöntemlerden ya da sınıfın dinamik olarak bir yere yüklenip yüklenmediğini tespit ettikleri durumlar yaşadım.

Java statik olarak derlendiğinden, yöntemleri kaldırmak oldukça güvenli olmalıdır. Ölü kodu kaldırmak her zaman iyidir. Onları çalışma zamanında çalıştıran çılgın bir yansıma sistemi olma ihtimali vardır, bu yüzden önce diğer geliştiricilere danışın, ancak bunları kaldırın.

En iyi yaklaşım ne olurdu? Onlar için birim testleri yaz veya neden orada olduklarını sorguluyor musun?

Kod silmek iyi bir şeydir.

Kodu silemediğinizde , yöntemi kaldırmak için hangi ana yayını hedeflediğinizi belgeleyen @Deprecated olarak işaretleyebilirsiniz . Sonra "sonra" silebilirsiniz. Bu arada, ona bağlı hiçbir yeni kod eklenmemesi gerektiği açık olacaktır.

Kullanımdan kaldırılmış yöntemlere yatırım yapmayı tavsiye etmem - bu yüzden sadece kapsama hedeflerine ulaşmak için yeni birim testleri yapılmaz.

İkisi arasındaki fark, öncelikle yöntemlerin yayınlanmış arayüzün bir parçası olup olmadığıdır . Yayınlanan arayüzün bölümlerini keyfi olarak silmek, arayüze bağlı olan tüketiciler için hoş olmayan bir sürpriz olabilir.

EclEmma ile konuşamıyorum, ama deneyimlerime göre, dikkat etmeniz gereken şeylerden biri yansıma. Örneğin, hangi sınıflara / yöntemlere erişeceğinizi seçmek için metin yapılandırma dosyalarını kullanırsanız, kullanılan / kullanılmayan ayrım açık olmayabilir (bu birleştirilmiş zamanlar tarafından yakıldım).

Projeniz bağımlılık grafiğinde bir yapraksa, kullanımdan kaldırılma durumu zayıflar. Projeniz bir kütüphane ise, kullanımdan kaldırılma durumu daha güçlüdür.

Şirketiniz bir mono repo kullanıyorsa , silme çoklu repo durumundan daha düşük risk taşır.

10b0'da belirtildiği gibi , yöntemler kaynak kontrolünde zaten mevcutsa, silme işleminden sonra bunları geri kazanma işlemi düz ileri bir egzersizdir. Bunu yapmanız gerektiğinden gerçekten endişe duyuyorsanız, taahhütlerinizin nasıl organize edileceğine biraz düşünün, böylece ihtiyaç duyduğunuzda silinen değişiklikleri kurtarabilirsiniz.

Belirsizlik yeterince yüksekse, silmek yerine kodu yorumlamayı düşünebilirsiniz . Mutlu yoldaki (silinen kodun hiçbir zaman geri yüklenmediği) ekstra bir iş, ancak geri yüklemeyi kolaylaştırıyor. Tahminimce, birkaç defa yakılana kadar düz silmeyi tercih etmeniz gerektiği ve bu bağlamda "belirsizliğin" nasıl değerlendirileceği hakkında bazı bilgiler verecek.

neden orada olduklarını sorguluyor?

Lore yakalamaya harcanan zaman mutlaka boşa gitmez. Kaldırma işlemini iki adımda gerçekleştirdiğimi biliyordum - ilk önce kod hakkında ne öğrendiğimizi açıklayan bir yorum ekleyip onaylayarak ve daha sonra kodu (ve yorumu) silerek.

Mimari karar kayıtlarına benzer bir şeyi , kaynak koduyla irfanı yakalamanın bir yolu olarak da kullanabilirsiniz .

Bir kod kapsamı aracı her şeyi bilmez, her şeyi görür. Sadece aracı yöntemi denir olmadığını iddia çünkü o anlamına gelmez değil denir. Yansıma var ve dile bağlı olarak yöntemi çağırmanın başka yolları da olabilir. C veya C ++ 'da işlev veya yöntem isimleri oluşturan makrolar olabilir ve araç çağrıyı göremeyebilir. Böylece ilk adım şöyle olacaktır: Yöntem ismi ve ilgili isimler için yazılı bir arama yapın. Deneyimli meslektaşları sorun. Aslında kullanıldığını bulabilirsiniz.

Emin değilseniz, her "kullanılmamış" yöntemin başına bir assert () koyun. Belki denir. Veya bir kayıt ifadesi.

Belki de kod aslında değerlidir. Bir meslektaşın iki haftadır üzerinde çalıştığı ve yarın açacağı yeni bir kod olabilir. Bugün çağrılmadı, çünkü çağrıları yarın eklenecek.

Belki kod aslında 2. bölümdür: Kod, yanlış giden şeyleri bulabilecek çok pahalı çalışma zamanı testleri gerçekleştiriyor olabilir. Kod sadece işler gerçekten yanlış giderse açıktır. Değerli bir hata ayıklama aracını siliyor olabilirsiniz.

İlginç bir şekilde, olası en kötü tavsiye "Sil. Taahhüt et. Unut." en yüksek puan. (Kod incelemeleri? Kod incelemeleri yapmıyorsunuz? Kod incelemeleri yapmazsanız ne yapıyorsunuz?

Yazılımın çalıştığı ortama bağlı olarak, yöntem çağrılırsa günlüğe giriş yapabilirsiniz. Uygun bir süre içinde aranmazsa, yöntem güvenle kaldırılabilir.

Bu, yalnızca yöntemi silmek yerine daha temkinli bir yaklaşımdır ve çok hataya duyarlı bir ortamda çalışıyorsanız faydalı olabilir.

#unreachable-codeKaldırma için her aday için benzersiz bir tanımlayıcı içeren özel bir boşaltma kanalına giriş yapıyoruz ve oldukça etkili olduğu kanıtlandı.