Kodumun 'döngüsel karmaşıklığı' ne anlama geliyor?

Kodun statik analizinde yeniyim. Uygulamamın 17,754 bir Döngüsel karmaşıklığı vardır. Uygulamanın kendisi sadece 37.672 kod satırıdır. Karmaşıklığın kod satırlarına göre yüksek olduğunu söylemek geçerli midir? Cyclomatic karmaşıklığı bana tam olarak ne söylüyor?

Cyclomatic karmaşıklığı bana tam olarak ne söylüyor?

Siklomatik karmaşıklık, kod satırlarının bir ölçüsü değil, bir modül boyunca bağımsız yolların sayısıdır. 17,754'teki döngüsel karmaşıklığınız, uygulamanızın içinden 17,754 benzersiz yolu olduğu anlamına gelir. Bunun tipik olarak başvurunuzu anlamanın ve test etmenin ne kadar zor olduğu konusunda bir takım çıkarımları vardır. Örneğin, siklomatik karmaşıklık, iyi yazılmış testler varsayarak% 100 dal kapsamı elde etmek için gereken test vakalarının sayısıdır.

İyi bir başlangıç ​​noktası, Vikipedi'deki çevrimsel karmaşıklık üzerine yazılmış makale olabilir . Sözde kod parçacığı bir çift parçası ve ne siklomatik karmaşıklık hakkında olduğunu gösteren bazı grafikler vardır. Daha fazla bilgi edinmek istiyorsanız, McCabe'nin siklomatik karmaşıklığı tanımladığı makalesini de okuyabilirsiniz .

Uygulamamın 17,754 kod satırı içeren bir döngüsel karmaşıklığı var. Uygulamanın kendisi sadece 37.672 kod satırıdır. Karmaşıklığın kod satırlarına göre yüksek olduğunu söylemek geçerli midir?

Bir şey değil. Birkaç kod satırı ve döngüler içine yerleştirilmiş çok sayıda koşullu bir uygulama, son derece yüksek bir döngüsel karmaşıklığa sahip olabilir. Öte yandan, az koşullu bir uygulama düşük siklomatik bir karmaşıklığa sahip olabilir. Bu, onu büyük ölçüde basitleştiriyor, ama bence bu fikir onun karşısına çıkıyor.

Uygulamanızın ne yaptığı hakkında daha fazla bilgi olmadan, daha yüksek bir döngüsel karmaşıklığa sahip olmak normal olabilir. Bununla birlikte, sadece uygulama seviyesi yerine, sınıf veya yöntem düzeyinde döngüsel karmaşıklığın ölçülmesini öneririm. Bu biraz daha yönetilebilir, kavramsal olarak bence - yolları bir yöntemle görselleştirmek ya da kavramsallaştırmak, büyük bir uygulamadaki yollardan çok daha kolay.

Döngüsel karmaşıklık, kodunuzun yeniden yapılandırılması gerekip gerekmediğini belirlemenin bir yoludur. Kod analiz edildi ve karmaşıklık sayısı belirlendi. Karmaşıklık, dallanma ile belirlenir (eğer ifadeler, vb.) Karmaşıklık, döngülerin vb.

Numara, yöntem seviyesinde kullanışlıdır. Daha yüksek seviyelerde sadece bir sayıdır.

17,754 sayısı, çok fazla bir anlamı olmayan proje düzeyinde karmaşıklığı (toplam kod) gösterir.

Sınıf ve yöntem düzeyinde karmaşıklığı delmek, kodun daha küçük yöntemlere yeniden yansıtılması veya karmaşıklığı ortadan kaldırmak için yeniden tasarlanması gereken alanları belirler.

CASEBir yöntemde 50 durumlu bir ifade düşünün . Belki her devletin farklı iş mantığı vardır. Bu, 50'lik bir döngüsel karmaşıklık yaratacaktır. 50 karar noktası var. CASE ifadesinin, dallanma mantığından kurtulmak için bir fabrika modeli kullanılarak yeniden tasarlanması gerekebilir. Bazen yeniden ateşleyebilir (yöntemi daha küçük parçalara böler) ve bazı durumlarda sadece yeniden tasarım karmaşıklığı azaltabilir.

Genel olarak, yöntem düzeyinde karmaşıklık için:

• <10 bakımı kolay
• 11-20 bakımı zor
• Yeniden düzenleme / yeniden tasarım için 21+ Aday

Ayrıca daha yüksek karmaşıklıkların kodu birim testine zorlaştırdığını da göz önünde bulundurun.

Tek bir yöntemde gördüğüm en yüksek karmaşıklık 560'dı. Bir yöntemdeki if ifadelerinin yaklaşık 2000 satırıydı. Temelde sürdürülemez, denenemez, potansiyel hatalarla dolu. Dallanma mantığı için gerekli tüm birim test durumlarını düşünün! İyi değil.

Tüm yöntemleri 20'nin altında tutmaya çalışın ve daha az karmaşık hale getirmek için herhangi bir yöntemi yeniden düzenlemenin bir maliyeti olduğunu fark edin.

Uygulamanızdaki farklı yolların sayısı. CC'deki bu IBM makalesine göz atın .

Yüksek görünüyor ama sizin durumunuzda, tüm sınıflarınız ve metotlarınızın tüm metotlarının CC'sinin eklenmesi. Kodlarımın nasıl yapılandırıldığını bilmediğim için örneklerim çok gergin, ancak 37672 kod satırlı bir canavar yönteminiz veya 10 satır kod içeren 3767 yönteminiz olabilir. Demek istediğim, uygulama düzeyinde, bu göstergenin fazla bir anlamı olmadığı, ancak yöntem düzeyinde, kodunuzu daha az hataya daha açık olması için kodunuzu daha küçük yöntemlere göre optimize etmenize / yeniden yazmanıza yardımcı olabilir.

Şahsen çok defa okuduğum, 10'dan yüksek CC'li yöntemlerin daha yüksek hata riskine sahip olmasıdır.

Uygulamalarımın kod kalitesini test etmek için Sonar'ı kullanıyorum ve varsayılan olarak +10 CC olan yöntemleriniz varsa bir uyarı oluşturduğunu düşünüyorum. Yine de bu hiçbir şey ifade etmiyor olabilir. Somut bir örnek: equalsFasulyenizin özelliklerini temel alan bir yöntem üretmek için Eclipse kullanıyorsanız , CC çatının çok hızlı bir şekilde üzerine çıkacaktır ...

Hangi aracı kullandığınızı bekliyor. Dışarıdaki açık kaynak araçlarından bazıları modül olarak sınıf veya modül olarak diğer yapı seviyesini alıyor. Bu nedenle, bir proje büyüdükçe, alma eğiliminde olan Siklomatik Karmaşıklık da artar. Ancak, benim kişisel anlayışım için, bir işlevsellik temelinde olmalı. Bir proje büyüdükçe, sahip olması gereken işlevler.

Lizard adındaki aracı kullanmanızı öneririm, kaynak kodunu bulup zip dosyasını github'dan indirebilirsiniz. Ayrıca, kodunuzda çok fazla gizli bilgi yoksa, çevrimiçi bir sürümü de vardır.

Dikkat etmeniz gereken anlamlı CCN, diğerlerinden farklı bir fonksiyon tabanındadır. Ayrıca, her bir fonksiyonun CCN'sini koru unber 15 ideal aralık olacaktır.