Kod kokuları hata değildir. Hatalı bir program çöker, yanlış sonuçlar döndürür veya bir testi geçemez. Kod kokusu olan bir program yıllarca mükemmel çalışabilir, ancak her değişiklik gereğinden fazla maliyete yol açar, her yeni özellik beklenmedik riskler taşır ve her yeniden düzenleme girişimi, kimsenin varlığından haberdar olmadığı bağımlılıkları ortaya çıkarır. Kod kokuları, gelecekteki sorunları öngören kodun yapısal özellikleridir: anında bir hataya neden olmazlar, ancak gelecekteki her değişikliği gerekenden daha zor, daha yavaş ve daha tehlikeli hale getirirler.
Bu terim, Martin Fowler ve Kent Beck tarafından Fowler'ın "Refactoring: Improving the Design of Existing Code " (1999) adlı kitabında popülerleştirilmiştir. Bu kitapta 22 farklı kod kokusu listelenmiş ve her birine karşılık gelen bir yeniden düzenleme tekniği eşleştirilmiştir. Bu katalog, günümüzde de geçerliliğini koruyan temel referans kaynağıdır ve Fowler'ın adlandırdığı kod kokuları (Uzun Metot, Tanrı Sınıfı, Yinelenen Kod, Özellik Kıskançlığı, Sapkın Değişiklik, Rastgele Değişiklik vb.) SonarQube kural setlerinde, statik analiz araçlarında ve sektör genelindeki kod inceleme kontrol listelerinde yer almaktadır.
Kod Kokularını Temizle
SMART TS XL karmaşık sistemlerde haritalama ve düzeltmeye yardımcı olur.
Daha fazla bilgiKod Kokusu Nedir?
Kod kokusu, kaynak kodun yüzeysel bir özelliğidir ve daha derin bir yapısal veya tasarım sorununa işaret eder. Kod derlenir, testlerden geçer ve doğru çıktı üretir, ancak yapısındaki bir şey onu okumayı, genişletmeyi veya güvenli bir şekilde değiştirmeyi olması gerekenden daha zor hale getirir. Fowler'ın tanımı: "Genellikle sistemdeki daha derin bir soruna karşılık gelen yüzeysel bir gösterge."
Kod kokuları, sözdizimi hatası veya başarısız bir doğrulama gibi ihlaller anlamında değildir. Bunlar, deneyimli geliştiricilerin, hemen görünür bir hata olmasa bile, uyarı işaretleri olarak tanıdığı göstergelerdir, kalıplardır. Tehlike, bunların birikimli olmasıdır: 10,000 satırlık bir kod tabanında tek bir uzun metot küçük bir rahatsızlıktır. Yüzlerce uzun metot, düzinelerce modüle yayılmış tekrarlanan mantık ve bağımlılık grafiğinin merkezindeki "Tanrı Sınıfları", güvenli bir şekilde değiştirilmesi gerçekten zor hale gelen bir sistemdir.
Kod Kokuları, Hatalar ve Teknik Borç
Bu üç kavram birbiriyle ilişkili ancak birbirinden farklıdır ve bunların karıştırılması önceliklendirmede hatalara yol açar:
| Konsept | Tanım | Anında Başarısızlık mı? | Nasıl bulunur |
|---|---|---|---|
| Böcek | Yanlış davranışa neden olan kod | Evet, testler başarısız oluyor, kullanıcılar hata bildiriyor. | Test etme, izleme, hata kayıtları |
| Kod kokusu | Gelecekteki sorunları öngören yapısal model | Hayır, kod doğru çalışıyor. | Kod incelemesi, statik analiz |
| Teknik borç | Geçmişteki kestirme yolların ve kötü kararların birikmiş maliyeti | Hayır, ama zamanla bileşikler oluşur. | Ölçümler, karmaşıklık analizi, yeniden yapılandırma çaba tahminleri |
Kod kokuları, teknik borcun birikme mekanizmasıdır. Kod tabanına eklenen her uzun metot, oluşan teknik borcun bir birimidir; bunun faizi ise, gelecekteki her geliştiricinin onu anlamak için harcadığı ekstra zaman ve gelecekteki her değişikliğin, boyutunun yan etkilerinden kaçınmak için harcadığı zamandır.
SonarQube'da Kod Kokusu Nedir?
SonarQube, kod sorunlarını üç kategoriye ayırır: hatalar (kesinlikle yanlış), güvenlik açıkları (güvenlik sorunları) ve kod kokuları (sürdürülebilirlik sorunları). SonarQube'un kod kokuları, Fowler'ın kataloğuna doğrudan karşılık gelir ve uzun metotlar (yapılandırılabilir satır eşiklerinin üzerinde), yinelenen bloklar, çok fazla parametre, karmaşık bilişsel karmaşıklık puanları, eksik hata işleme ve mimari bağlantı ihlalleri için kurallar içerir. SonarQube'daki kod kokusu kuralları, Fowler'ın orijinal taksonomisinin sektörde en yaygın kullanılan otomatikleştirilmiş uygulamasıdır.
Martin Fowler'ın Kod Kokuları: Klasik Sınıflandırması
Fowler'ın kategoriye göre düzenlenmiş orijinal 22 kod kokusu, standart referans olmaya devam etmektedir. Her büyük statik analiz aracının kural seti bu taksonomiden türetilmiştir.
| Kategoriler | Kod Kokuları |
|---|---|
| Şişkinlikler, kontrol edilemeyecek kadar büyük bir boyuta ulaşmış kod | Uzun Metot, Büyük Sınıf, İlkel Takıntı, Uzun Parametre Listesi, Veri Kümeleri |
| Nesne Yönelimli Kuramı Kötüye KullananlarNesne yönelimli programlama ilkelerinin kötüye kullanımı | Switch Deyimleri, Geçici Alan, Reddedilen Miras, Farklı Arayüzlere Sahip Alternatif Sınıflar |
| Değişimi ÖnleyenlerDeğişimi zorlaştırmak | Farklılaşan Değişim, Rastgele Ameliyat, Paralel Kalıtım Hiyerarşileri |
| Kullanılıp atılacaklargereksiz kod | Aşırı Yorumlar, Yinelenen Kod, Tembel Sınıf, Veri Sınıfı, Ölü Kod, Spekülatif Genellik |
| Barelleraşırı bağlantı | Özellik Kıskançlığı, Uygunsuz Yakınlık, Mesaj Zincirleri, Aracı Adam |
Bir kokunun hangi kategoriye ait olduğunu anlamak, iyileştirme önceliklerini belirlemeye yardımcı olur: Şişkinlik yaratan ve Değişikliği Engelleyen unsurlar doğrudan yüksek yeniden yapılandırma maliyetiyle ilişkilidir; Bağlayıcı unsurlar doğrudan mimari kırılganlıkla ilişkilidir; Gereksiz unsurlar ise kaldırılması en güvenli olanlardır.
En Sık Görülen Kod Hataları: Hızlı Referans
| Kod Kokusu | Ne gibi görünüyor | Birincil Risk |
|---|---|---|
| Yinelenen Kod | Aynı mantık birçok yerde karşımıza çıkıyor. | Hata düzeltmeleri her yere uygulanmalıdır; kopyalar zamanla farklılık gösterir. |
| Uzun Yöntem | Birden fazla sorumluluğu olan ve 20-30 satırı aşan yöntemler | Yüksek bilişsel yük; izole davranışları test etmek zor. |
| Tanrı Sınıfı / Büyük Sınıf | Her şeyi yapabilen tek bir sınıf | Her özellik değişikliği aynı sınıfı etkiliyor; birleştirme çakışmaları, kırılganlık |
| Uzun Parametre Listesi | 4 veya daha fazla parametre alan yöntemler | Yanlış değerler geçirmek kolay; çağrı noktalarını okumak zor. |
| Özellik Kıskançlığı | Başka bir sınıfın verilerini kendi verilerinden daha fazla kullanan bir yöntem. | Sıkı bağlantı; bir sınıftaki değişiklik diğerini bozar. |
| Farklılaşan Değişim | Bir sınıf birçok farklı nedenden dolayı değiştirildi. | Tek sorumluluk ilkesini ihlal eder; öngörülemeyen yan etkiler |
| Av Tüfeği Ameliyatı | Tek bir değişiklik, birçok sınıfta düzenleme yapılmasını gerektirir. | Yüksek değişim maliyeti; bir örneği gözden kaçırmak kolay. |
| Ölü Kod | Hiçbir zaman çağrılmayan veya erişilmeyen kod | Geliştiricileri kafa karıştırır; yıllar içinde birikir; geçişi zorlaştırır. |
| İlkel Takıntı | Alan nesneleri yerine temel veri tiplerini (dizeler, tamsayılar) kullanmak | Doğrulama her yere dağılmış; ifade gücü zayıf. |
| Veri Kümeleri | Aynı alan grubu tekrar tekrar birlikte geçildi. | Bir etki alanı nesnesi olmalıdır; soyutlamanın eksik olduğunu gösterir. |
| Spekülatif Genellik | Gelecekteki ihtiyaçlar düşünülerek yazılmış kod. | Gereksiz karmaşıklık; kimse neden orada olduğunu anlamıyor. |
| Tutarlı Olmayan Hata İşleme | Sessiz yakalamalar, çeşitli istisna stratejileri | Arızalar tespit edilemez; hata ayıklama çok daha uzun sürer. |
Kod Kokusu Tanımları ve Örnekleri
Yinelenen Kod
Büyük sistemlerde en yaygın ve en maliyetli kod kusuru. Kopyala-yapıştır geliştirme, zaman baskısı ve aynı problemi bağımsız olarak çözen, kendi içlerinde izole çalışan ekiplerden kaynaklanır. Bunun doğrudan sonucu bakım maliyetidir: paylaşılan mantıkta yapılan her değişiklik, her kopyaya uygulanmalıdır.
Java
// ServiceA -- discount calculation
double calculateDiscount(double amount) {
if (amount > 1000) return amount * 0.1;
return 0;
}
// ServiceB -- same logic, copied and forgotten
double computeDiscount(double value) {
if (value > 1000) return value * 0.1;
return 0;
}İş kuralı değiştiğinde (eşik değeri 1500, oran %12 olduğunda), bir kopya güncellenirken diğeri güncellenmiyor. İki modül artık temel iş mantığı konusunda uyuşmazlık gösteriyor ve bu tutarsızlık test aşamasında değil, üretim ortamında denetim sırasında ortaya çıkıyor.
Çözüm : Paylaşılan mantığı, her iki çağıranın da referans verdiği tek bir fonksiyona, yardımcı sınıfa veya paylaşılan kütüphaneye ayırın.
Uzun Yöntem
Zaman içinde ek sorumluluklar üstlenerek asıl amacının ötesine geçen bir yöntem. 200 satırlık bir yöntemi okumanın bilişsel yükü, yalnızca niceliksel olarak değil, niteliksel olarak da yirmi adet 10 satırlık yöntemi okumaktan farklıdır. Uzun yöntemlerin test edilmesi zordur çünkü tek başına test edilemeyecek kadar çok şey gerçekleştirirler ve anlaşılması da zordur çünkü okuyucunun tüm uygulama bağlamını çalışma belleğinde tutması gerekir.
Tespit eşiği : 20-30 satırdan uzun metotlar incelemeyi gerektirir; 50 satırdan uzun metotlarda ise neredeyse her zaman yeniden düzenleme (refactoring) haklıdır. COBOL'da 100'den fazla ifade içeren paragraflar bunun eşdeğeridir.
piton
class OrderProcessor:
def process_order(self, order):
# Validate order -- 40 lines
# Calculate discounts -- 30 lines
# Update inventory -- 25 lines
# Send notification emails -- 20 lines
# Generate invoice -- 35 lines
# 150+ lines total
passBu yöntemdeki her sorumluluk ayrı bir sınıf veya fonksiyon olmalıdır. Bunları bir araya getirmek, faturalama, envanter veya bildirimlere yapılacak her gelecekteki güncellemenin tüm sipariş işleme akışını istikrarsızlaştırma riskini taşıdığı anlamına gelir.
Tanrı Sınıfı
Birden fazla alanda sorumluluk biriktirmiş, Tek Sorumluluk İlkesini o kadar ciddi şekilde ihlal etmiş bir sınıf ki, kod tabanının ağırlık merkezi haline geliyor: her şey ona bağlı ve içinde herhangi bir şeyi değiştirmek, onunla ilgili her şeyi anlamayı gerektiriyor.
Algılama sinyali : 20-30'dan fazla genel metoda sahip bir sınıf veya adında "Manager", "Processor", "Handler", "Utils" veya "Helper" kelimelerinin birden fazla ilgisiz alana uygulandığı bir sınıf.
Farklılaşan Değişim
Birbirinden farklı ve ilgisiz birçok nedenden dolayı değiştirilen bir sınıf. Veritabanı şeması her değiştiğinde bu sınıfı düzenliyorsunuz. Fiyatlandırma kuralları her değiştiğinde bu sınıfı düzenliyorsunuz. Bildirim formatı her değiştiğinde bu sınıfı düzenliyorsunuz. Bu sınıfın çok fazla sorumluluğu var ve bölünmesi gerekiyor.
Tanım : Çeşitli nedenlerle sürekli değişen bir sınıf. Rastgele yapılan ameliyatın tersi.
Av Tüfeği Ameliyatı
Tek bir kavramsal değişiklik, birçok farklı sınıfta düzenlemeler gerektirir. Vergi oranını değiştirmek, arka uç hesaplamasını, ön uç doğrulamasını, veritabanı tetikleyicisini, toplu işi ve raporlama sorgusunu beş farklı yerde değiştirmeyi gerektirir. Bunlardan herhangi birinin eksik olması tutarsız davranışlara yol açar.
sql
-- Tax logic duplicated across queries
SELECT amount * 0.05 FROM invoices;
SELECT amount * 0.05 FROM payments;
SELECT amount * 0.05 FROM reports;0.05'ten 0.07'ye değişiklik yapmak artık SQL dosyalarında, saklı prosedürlerde ve uygulama kodunda her bir örneğini bulmayı gerektiriyor.
Özellik Kıskançlığı
Bir metot, kendi veri ve metotlarından ziyade başka bir sınıfın veri ve metotlarını daha fazla kullanıyorsa, bu davranışın muhtemelen diğer sınıfa ait olması gerektiğini gösterir.
Java
// In ReportGenerator -- envious of Customer's data
double calculateCustomerRating(Customer customer) {
return customer.getOrderCount() * customer.getAverageOrderValue()
/ customer.getDaysSinceRegistration();
}
// This logic belongs in Customer, not ReportGeneratorÖlü Kod
Depoda bulunan ancak üretim ortamındaki hiçbir yürütme yolu tarafından çağrılmayan kod. Ölü kod, özellikler kaldırılırken, değiştirilirken veya yeniden yapılandırılırken eski kod silinmedikçe yıllar içinde birikir. Kod incelemesine gürültü katar, kod tabanına yeni katılan geliştiricileri karıştırır, geçiş analizini zorlaştırır ve bazen yanlışlıkla yeniden etkinleştirilir.
BulmaStatik analiz araçları arasında SonarQube, Knip (TypeScript/JavaScript için) ve diğerleri yer almaktadır. SMART TS XL Kod tabanında erişilemeyen fonksiyonları, çağrılmayan metotları ve kullanılmayan değişkenleri belirleyin.
DRY İlkesi İhlalleri
Kendini Tekrarlama (DRY) ilkesi, her bilgi parçasının bir sistem içinde tek ve net bir şekilde temsil edilmesi gerektiğini belirtir. DRY ihlalleri, tekrarlanan kod, veri kümeleri ve birçok rastgele çözümleme senaryosunun temel nedenidir. İş mantığı birden fazla yerde temsil edildiğinde, bu temsiller kaçınılmaz olarak birbirinden uzaklaşır. DRY ilkedir; tekrarlanan kod ise ihlali gösteren işarettir.
piton
# DRY violation: same validation logic in three places
def validate_email_in_registration(email):
return "@" in email and "." in email
def validate_email_in_profile_update(email):
return "@" in email and "." in email
def validate_email_in_checkout(email):
return "@" in email and "." in email
# DRY-compliant: one function, three callers
def is_valid_email(email):
return "@" in email and "." in emailAlgılama Eşikleri: Kod Ne Zaman Kötü Koku Olarak Kabul Edilir?
Kod kokusu tespiti, ölçülebilir eşik değerler gerektirir. Aşağıda yaygın olarak kullanılan ölçütler ve dikkat gerektiren bir kokuya işaret eden değerler yer almaktadır:
| metrik | Ne Ölçer? | Uyarı Eşiği | Kritik Eşik |
|---|---|---|---|
| Siklomatik Karmaşıklık | Bir yöntemdeki karar dallarının sayısı | 10 yukarıda | 20 yukarıda |
| Yöntem Uzunluğu (satır) | Bir metot/fonksiyondaki satır sayısı | 20 yukarıda | 50 yukarıda |
| Parametre Sayısı | Bir metodun kabul ettiği parametre sayısı | 4 yukarıda | 7 yukarıda |
| Sınıf uzunluğu | Bir sınıftaki satır sayısı | 200 yukarıda | 500 yukarıda |
| Çoğaltma Oranı | Yinelenen kod yüzdesi | 3 üzerinde | 10 üzerinde |
| Bilişsel Karmaşıklık | Kodun anlaşılmasının ne kadar zor olduğu | 15 yukarıda | 25 yukarıda |
| Afferent Bağlantı (Ca) | Bu sınıfa bağlı olan sınıf sayısı | 15 yukarıda | 30 yukarıda |
| Efferent Bağlantı (Ce) | Bu dersin bağlı olduğu ders sayısı | 15 yukarıda | 30 yukarıda |
Bu eşikler SonarQube'da yapılandırılabilir ve çoğu statik analiz platformu bu ölçütlere dayalı özel kurallar oluşturmaya izin verir. Kritik eşik değerine sahip sınıflar ve yöntemler en yüksek öncelikli yeniden düzenleme hedefleridir: bunlar gelecekteki hataların en olası kaynakları ve bakımı en pahalı bileşenlerdir.
Kod Kokusu Tespit Araçları
Otomatik tespit, büyük kod tabanlarında kod kusurlarını belirlemenin ölçeklenebilir tek yaklaşımıdır. Manuel inceleme, otomatik araçların bulduklarının yalnızca küçük bir kısmını yakalar ve milyonlarca satır kod içeren eski sistemlerde ölçeklenebilir değildir.
| araç | Birincil dil | Ne Tespit Ediyor? |
|---|---|---|
| SonarQube / SonarCloud | Java, Python, JS/TS, C# ve daha fazlası | Fowler koku sınıflandırmasının tamamı, güvenlik risk noktaları, tekrarlar |
| Checkstyle + PMD | Java | Stil ihlalleri, tekrarlar, karmaşıklık ölçütleri |
| ESLint + typescript-eslint | JavaScript, Yazı Tipi | Uzun fonksiyonlar, karmaşıklık, kullanılmayan kod |
| Pylint + Radon | Python | Karmaşıklık, stil, sürdürülebilirlik endeksi |
| ReSharper / Sürücü | C# | Gereksiz kod, uzun metotlar, bağlantı sorunları |
| Clippy | Rust | Rust'ta kod kokusu olarak kabul edilen yaygın kalıplar olan deyimsel ihlaller. |
| Kod İklimi | Çoklu dil | Karmaşıklık, tekrarlama, sürdürülebilirlik puanı |
| SMART TS XL | COBOL, JCL, Java, Python, RPG, SQL, .NET | Diller arası tekrarlama, ölü kod, bağımlılık, bağımlılık kayması |
Rust'ta kod kokuları Bu hatalar öncelikle Rust'a özgü kalıpları uygulayan Clippy tarafından yakalanır. En yaygın Rust'a özgü hatalar arasında gereksiz klonlama, yanlış kullanım vb. yer alır. unwrap() Üretim yollarında, aşırı iç içe geçmiş eşleşme ifadelerinde ve geri dönüş değeri vermesi gereken işlevlerde Result ama bunun yerine panik durumunu kullanın.
Kod Kokuları ve Teknik Borç: Aralarındaki Bağlantı
Teknik borç, geçmişte hızı kaliteye tercih eden kararların birikmiş maliyetidir. Kod kokuları ise bu borcun kod yapısında kendini gösterme mekanizmasıdır. İlişki doğrudandır: ele alınmayan her kod kokusu bir teknik borç birimidir ve faiz oranı, gelecekteki her değişikliğin bu sorunu aşmak için harcaması gereken ekstra zamandır.
Yazılım değişiklik yönetimi için etki analizi bağlamında açıklandığı gibi , kod kokularının işaret ettiği yapısal sorunlar (aşırı bağımlılık, tekrarlanan mantık, ölü kod birikimi), herhangi bir değişikliğin neleri etkileyeceğini belirlemeyi zorlaştırdığı için her değişikliğin kapsamını doğrudan artırır.
Teknik borcu kod kokuları açısından açıklayalım : Bir kod tabanında %40 oranında tekrar eden kod varsa, her hata düzeltmesi olması gerekenden 1.4 kat daha pahalıya mal olur. Çekirdek işlem sınıfı her şeyin bağlı olduğu bir "Tanrı Sınıfı" ise, her özellik eklemesi tüm sınıfın anlaşılmasını ve test edilmesini gerektirir. Hata yönetimi tutarsızsa, her üretim olayı daha fazla araştırma süresi gerektirir çünkü hata sinyalleri güvenilir değildir. Teknik borç soyut bir kavram değildir, bu birikimli verimsizliklerin toplamıdır.
CISQ araştırması, geliştiricilerin zamanlarının %30-40'ını yeni işlevler geliştirmek yerine teknik borçları gidermeye harcadığını sürekli olarak ortaya koymaktadır. Kod kokusu yoğunluğu, ne kadar borç biriktiğinin en doğrudan ölçüsüdür.
Ne kadar SMART TS XL Kurumsal ölçekte kod hatalarını tespit eder.
SonarQube ve Clippy gibi bireysel araçlar tek bir dil içinde çalışır. COBOL programlarının Java servislerinin okuduğu veri kümelerine yazdığı, JCL iş akışlarının birden fazla dildeki programları çağırdığı ve aynı iş mantığının üç farklı on yılda yazılmış üç farklı sistemde bağımsız olarak kopyalandığı kurumsal ortamlarda, tek dilli araçlar resmin tamamını göremez.
SMART TS XL'S statik kod analizi Ortamdaki her dilde eş zamanlı olarak kod kusurlarını tespit eder: bir COBOL copybook'u ile bir Java yardımcı sınıfı arasında tekrarlanan mantık, hiçbir JCL görevinin çağırmadığı RPG programlarındaki ölü kod, tek bir paragrafın elli paragrafın işini yaptığı COBOL programlarındaki "Tanrı Sınıfı" kalıpları ve diller arası sınırda tutarsız hata işleme kalıpları.
Uygulama bağımlılık eşleme özelliği, tek tek dosya düzeyindeki araçların göremediği mimari sorunları belirler: en yüksek bağımlılığa sahip (en çok bağımlı olunan, değiştirildiğinde bozulma riski en yüksek olan) bileşenler, bağımsız olması gereken modüller arasında döngüsel bağımlılıkların bulunduğu yerler ve kopyalanmış iş mantığının, iki kopyanın da diğerinden haberdar olmadan farklı sistemlerde bağımsız olarak sürdürüldüğü yerler.
Etki analizi özelliği, sorunlu kodları eyleme dönüştürülebilir hale getirir: Yüksek bağımlılık içeren herhangi bir bileşeni yeniden düzenlemeden önce, etki analizi test edilmesi, doğrulanması veya güncellenmesi gereken her bağımlı bileşeni listeler. Bu, ekiplerin büyük ve sorunlu kod tabanlarında yaşadığı "yeniden düzenleme felcini", her değişikliğin bilinmeyen bir risk yerine tanımlanmış bir kapsamı olduğu yapılandırılmış, kapsamlı bir iyileştirme programına dönüştürür.
Eski sistemlerin modernizasyon programlarını yürüten ekipler için , kod kokusu analizi modernizasyon planının temelini oluşturur: ölü kod, geçiş başlamadan önce ortadan kaldırılır (kapsam azaltılır), tekrarlanan mantık, standart uygulamalara dönüştürülür, en yüksek bağımlılığa sahip bileşenler en son modernize edilir (onlara bağımlı her şey ele alındıktan sonra) ve "Tanrı Sınıfları" yeni bir dile dönüştürülmeden önce ayrıştırılır, çünkü bir "Tanrı Sınıfını" Java'ya dönüştürmek, Java'da bir "Tanrı Sınıfı" üretir.
Kod Kokularını Ele Alma: Bir Önceliklendirme Çerçevesi
Her kod hatası acil yeniden düzenlemeyi gerektirmez. Doğru yaklaşım, riske dayalı önceliklendirmedir:
Öncelik 1, Yüksek değişiklik oranına sahip bileşenlerdeki kod hataları. Sık sık değişen ve yüksek karmaşıklığa veya bağımlılığa sahip kodlar en fazla hatayı üretir. Bu bileşenler, değişiklik başına en yüksek maliyeti oluşturur ve en fazla üretim olayına neden olur. Bunları önce düzeltin.
Öncelik 2, Mimari sınırlardaki kokular. Her şeyin bağlı olduğu "tanrı sınıfları" ve yüksek bağımlılık gösteren bileşenler, değiştirilmesi en tehlikeli olanlardır, ancak düzeltilmeden bırakılması da en pahalı olanlardır. Bunlar, yeniden düzenlemeden önce en dikkatli etki analizini gerektirir.
Öncelik 3, Sistem sınırları boyunca yinelenen kod. Aynı iş mantığı birden fazla sistemde mevcut olduğunda, değişikliklerin tüm kopyalar arasında eş zamanlı olarak koordine edilmesi gerekir. Bu yinelemenin birleştirilmesi, koordinasyon yükünü azaltır ve sapmaları önler.
Öncelik 4, Ölü kodun kaldırılması. Ölü kod, ele alınması en güvenli kategoridir: kaldırılması davranışı bozamaz, yalnızca daha önce gizli olan bağımlılıkları ortaya çıkarır. Hiçbir zaman çağrılmayacak kodu dönüştürmek için harcanacak çabayı önlemek amacıyla, herhangi bir geçiş veya dönüştürme işleminden önce kaldırılmalıdır.
Öncelik 5, Düşük riskli alanlardaki stil ve yapısal kusurlar. Kararlı, düşük değişiklik oranına sahip kodlardaki uzun metotlar ve parametre listeleri, yakındaki kodun başka nedenlerle değişmesi gerektiğinde fırsatçı bir şekilde ele alınabilir; bu sırada çevredeki kusurlar da aynı anda yeniden düzenlenebilir.
Kod hatalarını reaktif bir şekilde değil, sistematik olarak tespit etme, ölçme ve ele alma disiplini, sistemleri büyüdükçe giderek yavaşlayan geliştirme ekiplerinden, zaman içinde teslimat hızını koruyan ekipleri ayıran şeydir.
