Koddaki basitliği nasıl tanımlayabilir ve ölçebilirim?

Önceki sorumda okunabilirlikle ilgili basitlik hakkında , koddaki basitlik tanımımı ve anlayışımı görmeme yardımcı olan birçok cevap var, muhtemelen yanlıştı.

Koddaki basitliği nasıl tanımlayabilirim? Kod basitliğini ölçmek için hangi yazılım ölçümleri ve metrikleri mevcuttur?

Karmaşıklığı ölçmek için en yaygın metrikler (veya karmaşıklığın tersi olarak sadeliği alırsanız basitlik), McCabe'nin Siklomatik Karmaşıklığı ve Halstead Karmaşıklığı Metrikleridir .

Siklomatik karmaşıklık, bir sınıfta da hesaplanabilmesine rağmen, genellikle bir yöntem veya işlev olan belirli bir birimdeki farklı yolların sayısını ölçer. Yolların sayısı arttıkça, çalışma belleği kavramıyla ilgili olan belirli bir modülden veri akışını hatırlamak daha da zorlaşır . Yüksek siklomatik karmaşıklık, bir modülü test etme yeteneğinde zorluk olduğunu gösterir - sistemdeki çeşitli yolları kapsamak için daha fazla test durumu gerekir. Yüksek siklomatik karmaşıklığı yüksek kusur oranlarıyla ilişkilendiren çalışmalar da vardır. Tipik olarak, 10'luk bir siklomatik karmaşıklık, bir birimin gözden geçirilmesi ve muhtemelen yeniden düzenlenmesi gerektiğini gösterir.

Halstead karmaşıklığı ölçümleri, bir kod parçasının hacmini, zorluğunu ve çabasını hesaplamak için toplam ve farklı operatörlerin ve işlenenlerin girdilerini kullanır. (Benzersiz operatör sayısı / 2) * (toplam işlenen sayısı / benzersiz işlenen sayısı) olan zorluk, sistemi öğrenme veya kod incelemesi yapma gibi görevlerin kodunu okuma ve anlama yeteneğine bağlıdır. Yine, bunu bir sistem düzeyinde, bir sınıf düzeyinde veya bir yöntem / fonksiyon düzeyinde sayabilirsiniz. Bu ölçümlerin burada ve burada hesaplanmasıyla ilgili birkaç gönderi var .

Sadece kod satırlarını saymak size karmaşıklık fikri de verebilir. Daha fazla kod satırı, bir modülde okunacak ve anlaşılacak daha çok şey olduğu anlamına gelir. Bunu bağımsız bir ölçüm olarak kullanmakta tereddüt ederdim. Bunun yerine, hata yoğunluğunu elde etmek için belirli bir modüldeki hata sayısı gibi diğer ölçümlerle birlikte kullanırım. Yüksek hata yoğunluğu, karmaşık koddan kaynaklanabilecek veya kaynaklanmayabilecek test yazma ve kod gözden geçirme işlemlerindeki sorunları gösterebilir.

Fan girişi ve fan çıkışı, veri akışıyla ilgili diğer iki metriktir. Tanımlandığı gibi burada , fan parametreleri okumak, denilen prosedürler toplamıdır ve küresel değişkenler okumak ve fan dışarı verilen bir prosedür çağrı prosedürleri toplamıdır, yazılı parametreler (referans olarak geçirilen, dış kullanıcılara maruz), ve global değişkenlere yazılmıştır. Yine, yüksek fan girişi ve fan çıkışı, anlaşılması zor olabilecek bir modülün göstergesi olabilir.

Belirli paradigmalarda, yararlı olan başka önlemler veya metrikler de olabilir. Örneğin, nesne yönelimli dünyada, bir sistemin ne kadar basit veya karmaşık olduğunu değerlendirmek için eşleşmenin (düşük arzu), bütünlüğün (yüksek arzu) ve kalıtım derinliğinin (düşük arzu) izlenmesi kullanılabilir.

Tabii ki, birçok önlemin ve metriklerin sadece göstergeler olduğunu anlamak önemlidir. Basitliği artırmak için yeniden düzenleme yapmanın gerekli olup olmadığını veya bunu yapmaya çabalamaya değip değmeyeceğini belirlemek için kararınızı kullanmanız gerekir. Ölçümleri yapabilir, metrikleri hesaplayabilir ve kodunuzu öğrenebilirsiniz, ancak sisteminizi sayılara göre tasarlamak istemezsiniz. Sonuçta, mantıklı olanı yapın.

Sadeliği tanımlayan resmi bir moda bakmak yerine, sadeliği kod yazma kalitesinin bir niteliği olarak tanımlamak istiyorum.

Ben basitlik ölçüsü koymuyorum ama ne zaman basit ya da basit bir şey diyorsunuz.

1. Kod Geçişi: Kodda
gezinmek ne kadar kolay? API işlevlerinin nerede yazıldığını tespit etmek kolay mı? Çağrı akışlarını anlamak kolay mı, örneğin hangi yöntemleri başkalarını çağırıyor (ve neden) - iyi durum makineleri uygulanmış veya temiz bir şekilde tanımlanmış algoritmalar var mı?

Kod geçişi kolay olduğunda, kodu takip etmek kolaydır .

2. Adlandırma
Diğer kodlama standartları kodun daha temiz görünmesine yardımcı olurken, en önemli şey sınıfların / nesne örneklerinin / Değişkenlerin / yöntemlerin adlandırılmasıdır. Açık ve net isimler kullanımı açıkça üzerinde büyük bir etkisi vardır Sadelik kodunun. Basit bir isim tanımlamak zor olduğunda, bu değişken / yöntem olduğu fikrini yeniden düşünmek isteyebileceğiniz bir işarettir.

3. Yorum ve referanslar
Metodunuzun her birinin açık bir rolü var mı? Her değişken / öznitelik oynadıkları rolü belirlemek kolay mıdır? Bir kod parçası varsayımları ima eden veya alakasız değişken setini etkileyen bir şey yaptığında, bakım kabusu haline gelebilir.

4. Bağımlılık veya bağlantı
Sadece koda bakarak yargılamak zordur, ancak birisi hatalarınızı düzeltmeye çalışırsa çok belirginleşir. Başka bir nesnede başka şeyler değiştiğinde, buradaki işlem değişir mi? Bu değişiklikler açık mı? Bir şeyleri barındırmak için API'yı sık sık değiştirmeniz gerekiyor mu? Bunlar, modüller arası ilişkilerin basit olmadığını göstermektedir.

5. Girişler Kullanıcı veya Uygulamalar
Son olarak, kullanıcı girişleri veya uygulama API / kullanıcı arayüzünde ne kadar basit kabul edilir? Birden fazla olası Kullanıcı / Uygulamanın (farklı amaçlar için) size vermesi gerektiğinde, bunlar açık mıdır? Daha yüksek soyutlama ile ilgili olmayan, ancak yine de arayüzde ileriye giden durumlar / ayrıntılar var mı?

Genellikle soracağım basit bir soru aşağıdaki gibidir: Bir program yerine, aynı işlevi bir insan tarafından gerçekleştirilmesini isteseydim, bu bilgileri kağıt formda doldurur muydum ? Değilse, burada yeterince basit değilim .

Bu listenin kapsamlı olduğunu söylemeyeceğim, ama sanırım kriterler yazılımı kullanmak ve değiştirmek ne kadar kolay veya zor. Bu basit.

Kod sadeliği için iyi bir mevcut metriklerin farkında değilim (bu onların var olmadığı anlamına gelmez - sadece onlar hakkında bilmiyorum). Bazıları önerebilirim, belki bazıları yardımcı olacaktır:

• Kullanılan dil özelliklerinin sadeliği: dilde "gelişmiş" ve "basit" olarak kabul edilebilecek özellikler varsa, gelişmiş özelliklerin gerçekleşme sayısını sayabilirsiniz. "Gelişmiş" i nasıl tanımladığınız biraz daha öznel olabilir. Bazılarının bunun bir programın "zekasını" ölçmek gibi olduğunu söyleyebileceğini düşünüyorum. Yaygın bir örnek: bazıları ?:operatörün "gelişmiş" bir özellik olması gerektiğini söyleyebilir , bazıları ise aynı fikirde olmayabilir. Bunu test edebilecek bir araç yazmanın ne kadar kolay olacağını bilmiyorum.

• Program içindeki yapıların sadeliği: Bir fonksiyonun kabul edeceği parametre sayısını ölçebilirsiniz. > M parametrelerine sahip tüm işlevlerin > n % 'si varsa, n ve m'yi nasıl tanımladığınıza bağlı olarak basit değil saymayı seçebilirsiniz (belki n = 3 ve m = 6?). Ben bunu ölçmek statik bazı analiz araçları olduğunu düşünüyorum - Ben JTest sadece> m parametreleri ile fonksiyonları ölçülen düşünüyorum .

• İç içe döngülerin veya denetim yapılarının sayısını saymayı deneyebilirsiniz. Bu aslında kötü bir metrik değildir ve bunun için bir isim olduğunu düşünüyorum (başımın üstünü hatırlayamıyorum). Yine, bunu bir dereceye kadar ölçebilen araçlar (yine JTest gibi) olduğunu düşünüyorum.

• "Yeniden düzenlenebilirliği" ölçmeyi deneyebilirsiniz. Kodunuzu kod parçalarından sürü içeriyorsa olabilir refactored ama değil , belki de olabildiğince basit olmaz. Ayrıca JTest ile çalıştığım zamandan bunu da ölçmeye çalıştığını hatırlıyorum, ancak bu durumda sık sık hemfikir olmadığımı hatırlıyorum, bu yüzden YMMV.

• Sisteminizin farklı bölümleri arasındaki katman sayısını ölçmeyi deneyebilirsiniz. Örneğin: veritabanında depolanmadan önce bir web formundan gelen verilere kaç farklı kod parçası dokunur? Bu düzgün ölçmek zor olabilir ...