Performansa Giden Yol Kirli Kod Bombalarıyla Dolu

Çoğu zaman, bir sistemin performans ayarı, kodu değiştirmenizi gerektirir. Kodu değiştirmemiz gerektiğinde, aşırı karmaşık veya yüksek düzeyde bağlı olan her parça, çabayı raydan çıkarmak için bekleyen kirli bir kod bombasıdır. Kirli kodun ilk zayiatı programınız olacaktır. İleriye giden yol düzgünse, ne zaman bitireceğinizi tahmin etmek kolay olacaktır. Kirli kodla beklenmedik karşılaşmalar, aklı başında bir tahminde bulunmayı çok zorlaştıracaktır.

Bir yürütme etkin noktası bulduğunuz durumu düşünün. Normal hareket tarzı, temel alınan algoritmanın gücünü azaltmaktır. Diyelim ki yöneticinizin tahmin talebine 3-4 saatlik bir cevapla cevap verdiniz. Düzeltmeyi uygularken, bağımlı bir parçayı kırdığınızı hemen anlarsınız. Yakından ilgili şeyler genellikle zorunlu olarak birleştiğinden, bu kırılma büyük olasılıkla beklenir ve açıklanır. Ancak bu bağımlılığı düzeltmek, diğer bağımlı parçaların kırılmasına neden olursa ne olur? Ayrıca, bağımlılık kökenden ne kadar uzaksa, onu bu şekilde tanımanız ve tahmininizde hesaba katmanız o kadar az olasıdır. 3-4 saatlik tahmininiz birdenbire 3-4 haftaya kolayca uzayabilir. Genellikle programdaki bu beklenmedik şişkinlik, bir seferde 1 veya 2 gün olur. Sonunda tamamlanması birkaç ay süren "hızlı" yeniden düzenlemeleri görmek nadir değildir. Bu durumlarda, sorumlu ekibin güvenilirliğine ve siyasi sermayesine verilen zarar, şiddetli ile ölümcül arasında değişecektir. Keşke bu riski belirlememize ve ölçmemize yardımcı olacak bir aracımız olsaydı.

Aslında, kodumuzun karmaşıklığını ve bağlantının derecesini ve derinliğini ölçmenin ve kontrol etmenin birçok yolu var. Yazılım ölçümleri, kodumuzdaki belirli özelliklerin oluşumlarını saymak için kullanılabilir. Bu sayıların değerleri kod kalitesiyle ilişkilidir. Bağlantıyı ölçen bir dizi metrikten ikisi, fan-in(bir mantık hücresinin giriş denklemlerini besleyen maksimum giriş sinyali sayısını ifade eder) ve fan-out(bir mantık hücresinin çıkış denklemleri tarafından beslenen maksimum çıkış sinyali sayısını ifade eder). Sınıflar için dağıtmayı düşünün: Bir ilgi sınıfından doğrudan veya dolaylı olarak başvurulan sınıfların sayısı olarak tanımlanır. Bunu, sınıfınız derlenmeden önce derlenmesi gereken tüm sınıfların bir sayısı olarak düşünebilirsiniz. Fan-in ise, ilgilenilen sınıfa bağlı olan tüm sınıfların bir sayısıdır. Fan-out ve fan-in'leri bilerek I = fo / (fi + fo) kullanarak bir istikrarsızlık faktörünü hesaplayabiliriz. . I 0'a yaklaştıkça paket daha kararlı hale gelir. I 1'e yaklaştıkça paket kararsız hale gelir. Kararlı paketler, yeniden kodlama için düşük riskli hedeflerken, kararsız paketlerin kirli kod bombalarıyla doldurulması daha olasıdır. Yeniden düzenlemedeki amaç I'yi 0'a yaklaştırmaktır.

Metrikleri kullanırken, bunların yalnızca temel kurallar olduğu unutulmamalıdır. Tamamen matematikte, fo'yu değiştirmeden fi artırmanın I'yi 0'a yaklaştıracağını görebiliriz. Ancak, bu sınıfta çok büyük bir fan-in değerinin dezavantajı vardır. bağımlıları kırmadan değiştirmek daha zor olacaktır. Ayrıca, fan-out'u ele almadan risklerinizi gerçekten azaltmıyorsunuz, bu nedenle bir miktar denge uygulanmalıdır.

Yazılım metriklerinin bir dezavantajı, metrik araçlarının ürettiği çok sayıda sayının tecrübesiz kişiler için göz korkutucu olabilmesidir. Bununla birlikte, yazılım metrikleri temiz kod mücadelemizde güçlü bir araç olabilir. Performans ayarlama alıştırması için ciddi bir risk oluşturmadan önce kirli kod bombalarını belirlememize ve ortadan kaldırmamıza yardımcı olabilirler.

Kirk Pepperdine Tarafından