Bir yazılım projesinde aynı mantığın birden fazla yerde tekrarlanması, ilk bakışta zararsız bir alışkanlık gibi görünebilir. Ancak kod tabanı büyüdükçe bu tekrarlar, bakım maliyetini artıran ve hataların gizlice çoğalmasına yol açan bir kaynağa dönüşür. Kod tekrarı (duplicate code) tespit araçları tam da bu noktada devreye girer ve genellikle daha geniş statik analiz süreçlerinin bir parçası olarak çalışır. Bu yazıda, bu araçların arka planda hangi tekniklere dayandığını ve bulgularının nasıl yorumlanması gerektiğini ele alıyoruz.
Bir bakışta
- Kod tekrarı, bakım maliyetini artırır ve hataların fark edilmeden çoğalmasına neden olabilir.
- Tespit araçları metin, token ve AST düzeyinde karşılaştırma yaparak farklı kopya türlerini bulur.
- Benzerlik eşiği doğru ayarlanmazsa yanlış pozitif veya yanlış negatif sonuçlar ortaya çıkabilir.
Kod Tekrarı Neden Bir Sorun Sayılır
Aynı iş mantığının kod tabanında birden fazla yerde bulunması, doğrudan bir bakım yükü anlamına gelir. Bir hata tespit edildiğinde, geliştiricinin o mantığın geçtiği tüm kopyaları bulup düzeltmesi gerekir. Kopyalardan biri unutulursa, aynı hata sistemin farklı bir noktasında varlığını sürdürmeye devam eder.
Küçük projelerde bu tekrarları elle takip etmek mümkün olabilir. Fakat kod tabanı büyüdükçe, aynı fonksiyonun veya mantık bloğunun kaç farklı dosyada tekrarlandığını insan gözüyle fark etmek giderek zorlaşır. Bu nedenle kod kalitesi raporlarında tekrar oranı, genellikle karmaşıklık ve test kapsamı gibi metriklerle birlikte önemli bir gösterge olarak yer alır: yüksek bir tekrar oranı, kod tabanının uzun vadede bakımının zorlaşacağına işaret eden bir erken uyarı sinyali olarak okunur.
Tekrar Tespitinde Temel Yaklaşımlar
Kod tekrarı tespit araçları, kopyaları bulmak için farklı düzeylerde soyutlama kullanır. Bu yaklaşımlar genellikle üç ana kategoride toplanır.
Metin/satır bazlı karşılaştırma, en basit yöntemdir. Kod dosyalarındaki satırlar veya karakter dizileri birebir karşılaştırılır. Uygulaması kolaydır ama sınırları da bellidir: bir değişken adı değiştirildiğinde ya da bir satıra boşluk eklendiğinde, aslında aynı olan iki kod bloğu farklı gibi görünebilir.
Token bazlı normalizasyon, bu sınırlamayı aşmak için kodu önce anlamlı parçalara (token) ayırır ve değişken isimleri, sabitler gibi ayrıntıları normalleştirir. Böylece toplam = a + b ile sonuc = x + y gibi yapısal olarak aynı ama isimlendirmesi farklı iki kod parçası, token düzeyinde karşılaştırıldığında benzer olarak işaretlenebilir. Bu yaklaşım, satır bazlı yöntemden daha esnektir çünkü biçimsel farklılıklara daha az duyarlıdır.
Soyut sözdizimi ağacı (AST) karşılaştırması ise daha derin bir analiz sunar. Kod, önce bir ağaç yapısına dönüştürülür; bu ağaç, kodun ne yaptığını değil nasıl bir yapıya sahip olduğunu temsil eder. İki kod bloğunun AST'leri karşılaştırılarak, satır sıralaması veya küçük sözdizimsel farklılıklar olsa bile yapısal olarak benzer olup olmadıkları anlaşılabilir.
Genel eğilim olarak, metin bazlı yöntemler basit ve hızlı tam kopya taramalarında yeterli olurken, token ve AST bazlı yaklaşımlar isimlendirme ya da küçük yapısal farklardan etkilenmeyen daha güvenilir sonuçlar verme eğilimindedir.
Tam Kopya ile Yapısal Olarak Benzer Kopyalar Arasındaki Fark
Kod tekrarı literatüründe genellikle kopyalar birkaç türe ayrılır. En basit tür, tam kopya (exact clone) olarak adlandırılır: bir kod bloğunun, boşluk ve yorum farklılıkları dışında birebir aynı şekilde başka bir yerde bulunmasıdır. Örneğin bir doğrulama fonksiyonunun kopyalanıp yapıştırılarak başka bir dosyada aynen kullanılması, tipik bir tam kopya örneğidir.
Ancak gerçek kod tabanlarında tekrarların çoğu bu kadar net değildir. Near-duplicate (yaklaşık kopya) olarak adlandırılan durumlarda, kod parçaları yapısal olarak büyük ölçüde benzer olsa da değişken isimleri, sabit değerler ya da küçük ek/çıkarma işlemleri gibi noktalarda farklılık gösterir. Bu tür kopyalar literatürde genellikle tip 2 (isimlendirme ve sabit farklılıkları) ve tip 3 (birkaç satır ekleme/çıkarma içeren yapısal varyasyonlar) gibi sınıflandırmalarla ele alınır.
Sadece birebir eşleşmeyi arayan bir araç, projedeki tekrarların önemli bir kısmını gözden kaçırır. Çünkü pratikte geliştiriciler nadiren kodu değiştirmeden kopyalar; genellikle değişken adını günceller, bir parametre ekler ya da küçük bir mantık değişikliği yapar. Bu yüzden token ve AST bazlı yaklaşımların near-duplicate tespitindeki katkısı, araçların pratik değerini belirleyen önemli bir unsurdur.
Benzerlik Eşiği ve Yanlış Pozitif/Negatif Dengesi
Kod tekrarı araçları, iki kod parçasının "yeterince benzer" olup olmadığına karar vermek için bir benzerlik eşiği (threshold) kullanır. Bu eşik genellikle bir yüzde ya da eşleşen minimum token/satır sayısı şeklinde ifade edilir.
Eşik çok düşük tutulursa, araç aslında birbiriyle ilgisiz olan ama tesadüfen benzer yapıya sahip kod parçalarını da tekrar olarak işaretleyebilir. Bu durum yanlış pozitiflerin artmasına, dolayısıyla geliştiricilerin raporlara olan güveninin azalmasına yol açabilir. Öte yandan eşik çok yüksek tutulursa, gerçekten anlamlı olan ama küçük farklılıklar içeren tekrarlar gözden kaçabilir; bu da yanlış negatif riskini artırır.
Bu denge nedeniyle çoğu araç, varsayılan bir eşik değeriyle gelir fakat ekiplerin bunu kendi projelerinin yapısına göre ayarlamasına imkân tanır. Örneğin test kodlarında belirli bir tekrar seviyesi kabul edilebilir sayılabilirken, üretim mantığını içeren dosyalarda aynı seviyede bir tekrar daha ciddiye alınabilir.
Tekrar Tespitinin Statik Analiz Süreciyle İlişkisi
Kod tekrarı tespiti, tek başına çalışan izole bir işlem değildir; genellikle statik analiz araçlarının sunduğu daha geniş bir kod kalitesi değerlendirmesinin parçasıdır. Bu araçlar kodu çalıştırmadan inceler ve tekrar oranının yanı sıra karmaşıklık, potansiyel hatalar ve stil sorunları gibi başka bulgular da üretir.
Kod kalitesi raporlarında tekrar bulguları genellikle bir yüzde (tekrarlanan satırların toplam satırlara oranı) ya da tekrarlanan blok sayısı şeklinde görselleştirilir. Bazı araçlar ayrıca hangi dosyaların birbirine en çok benzediğini gösteren listeler de sunar.
Bu bulguların tek başına değerlendirilmesi yanıltıcı olabilir. Örneğin yüksek karmaşıklığa sahip ve aynı zamanda çokça tekrarlanan bir kod bloğu, düşük test kapsamına sahipse, bu üçlü bulgu birlikte okunduğunda çok daha öncelikli bir risk alanına işaret eder. Bu yüzden tekrar oranı, tek başına bir karar kriteri değil, diğer metriklerle birlikte yorumlanması gereken bir gösterge olarak ele alınmalıdır.
Araçların Sınırlılıkları
Kod tekrarı tespit araçları güçlü bir yardımcı olsa da mutlak bir çözüm değildir. Öncelikle, değişken ve fonksiyon isimlendirmesindeki farklılıklar, özellikle yalnızca metin bazlı yöntemler kullanan basit araçlarda tespiti zorlaştırabilir. Token ve AST bazlı yaklaşımlar bu sorunu büyük ölçüde azaltsa da tamamen ortadan kaldırmaz.
İkinci bir zorluk, farklı programlama dilleri arasında tekrar aramaktır. Aynı iş mantığı iki farklı dilde yazıldığında (örneğin bir servisin hem backend hem de mobil tarafta benzer bir doğrulama kuralı içermesi), araçların çoğu bunu tespit edemez çünkü her dilin kendi sözdizimi ve AST yapısı vardır.
Üçüncü olarak, semantik olarak aynı işi yapan ama tamamen farklı yazılmış kod parçaları da gözden kaçabilir. Bir toplama işlemi döngüyle yazılabileceği gibi yerleşik bir fonksiyonla da yazılabilir; bu iki yaklaşım yapısal olarak çok farklı görünse de aynı sonucu üretir. Mevcut araçlar genellikle yapısal benzerliğe odaklandığı için bu tür semantik eşleşmeleri yakalamakta zorlanır.
Bu sınırlılıklar, otomatik tespitin insan gözden geçirmesinin yerini tam olarak tutamayacağını gösterir. Araçlar, dikkat edilmesi gereken alanları işaret eden bir ön filtre olarak düşünülmelidir; nihai değerlendirme yine geliştiricinin bağlamsal bilgisine ihtiyaç duyar.
Ekipler Bulguları Nasıl Yorumlamalı
Bir kod tekrarı raporu geldiğinde, her bulgunun otomatik olarak refactor edilmesi gerektiği sonucuna varmak yanlış olur. Bazı tekrarlar kasıtlıdır; örneğin iki modülün birbirinden bağımsız evrilmesi beklendiği için benzer görünen kodun bilinçli olarak ayrı tutulduğu durumlar olabilir. Bazı tekrarlar ise gerçekten ihmalden kaynaklanır ve ortak bir fonksiyona çıkarılarak sadeleştirilebilir.
Bu ayrımı yapabilmek için ekiplerin bulguları önceliklendirirken kod tabanının kritik bölgelerine odaklanması faydalı olur. Sık değişen, hataya açık ya da güvenlik açısından hassas olan dosyalardaki tekrarlar, nadiren dokunulan yardımcı kodlardaki tekrarlara göre daha yüksek öncelik taşır.
Genel bir çerçeve olarak, tekrar bulgusunu izole bir sayı olarak değil, kodun bağlamıyla birlikte okumak önerilir: bu tekrar hangi sıklıkla değişen bir alanda, ne kadar karmaşıklıkla ve ne düzeyde test kapsamıyla bir arada bulunuyor? Bu sorulara verilen yanıtlar, bir tekrar bulgusunun sadece bir istatistik mi yoksa gerçek bir bakım riski mi olduğunu ayırt etmeye yardımcı olur.
