Dev Log: Bilerek Kod Silmek ve Build’ı Bozmak
Bir yazılım geliştirme projesinde ilerlerken bazen beklenmedik durumlarla karşılaşırız. Kod tabanını güncel tutmak, yeni özellikler eklemek veya mevcutları iyileştirmek rutinimizin bir parçasıdır. Ancak ya bilerek kod silersek? Ya da daha da kötüsü, bilerek build’ı (derleme sürecini) bozarsak? Bu ilk bakışta çılgınca gelebilir, ancak bu “kontrollü kaos” yaklaşımının, özellikle karmaşık ve uzun soluklu projelerde, beklenmedik faydalar sağlayabileceğini biliyor muydunuz? Bu makalede, bu sıra dışı ama etkili yöntemin ardındaki mantığı, nasıl uygulandığını ve sağladığı avantajları derinlemesine inceleyeceğiz.
Neden Bilerek Kod Silip Build’ı Bozmalıyız?
Bu sorunun cevabı, yazılım geliştirmenin temelinde yatan bazı zorluklara ve bu zorlukların üstesinden gelme stratejilerine dayanır. Projeler büyüdükçe ve ekip üyeleri arttıkça, kod tabanı kontrolsüz bir şekilde genişleyebilir. Bu durum, zamanla şu sorunlara yol açabilir:
- Kod Tekrarı (Code Duplication): Farklı yerlerde aynı veya çok benzer kod bloklarının oluşması.
- Teknik Borç (Technical Debt): Hızlı çözümler veya ertelenmiş refaktöring (yeniden düzenleme) nedeniyle biriken, gelecekteki geliştirmeleri yavaşlatan ve maliyetini artıran sorunlar.
- Anlaşılmayan Kodlar: Zamanla unutulan veya belgelenmeyen, okunması ve üzerinde çalışılması zor kod parçaları.
- Kullanılmayan Kod (Dead Code): Artık işe yaramayan, ancak hala kod tabanında yer kaplayan ve potansiyel olarak karmaşıklığı artıran kodlar.
- Zayıf Test Kapsamı: Mevcut kodun yeterince test edilmemesi, yapılan değişikliklerin yeni hatalara yol açma riskini artırır.
İşte tam bu noktada, bilerek kod silme ve build’ı bozma pratiği devreye girer. Bu, bir tür “kasıtlı temizlik”tir. Amacımız, kod tabanındaki gereksiz, eski, yanlış veya tehlikeli olabilecek parçaları ortaya çıkarmaktır. Bu süreci bir cerrahi müdahale gibi düşünebilirsiniz; bazen en iyi iyileşme, hastalıklı dokunun tamamen çıkarılmasıyla başlar. Bu yöntem, proaktif bir hata bulma ve kod kalitesini artırma tekniğidir. Başlangıçta garip gelse de, bu stratejinin uzun vadede daha temiz, daha sürdürülebilir ve daha güvenilir bir kod tabanı oluşturmaya nasıl yardımcı olabileceğini zamanla göreceğiz. Bu süreç, sadece kodu temizlemekle kalmaz, aynı zamanda ekibin kodun yapısı, bağımlılıkları ve test stratejileri hakkındaki anlayışını da derinleştirir.
Temel Kavramlar: Refaktöring, Dead Code ve Build Süreci
Bu konuyu daha iyi anlamak için bazı temel kavramlara göz atalım.
Refaktöring: Kodun Yeniden Düzenlenmesi
Refaktöring, bir yazılımın dış davranışını değiştirmeden iç yapısını iyileştirme sürecidir. Amaç, kodu daha okunabilir, daha anlaşılır, daha sürdürülebilir ve daha az karmaşık hale getirmektir. Bu, genellikle mevcut kod bloklarını yeniden yazarak, fonksiyonları ayırarak, değişken isimlerini daha açıklayıcı hale getirerek veya kod tekrarını ortadan kaldırarak yapılır. Refaktöring, teknik borcu azaltmanın en etkili yollarından biridir ve sürekli yapılması gereken bir faaliyettir. Bilerek kod silme ve build’ı bozma pratiği, aslında bir tür agresif refaktöring biçimi olarak görülebilir. Bu süreçte, silinen kodun yerine daha temiz ve daha iyi tasarlanmış bir çözüm getirilmesi hedeflenir.
Dead Code: Kullanılmayan Kod Kalıntıları
Dead code, yani kullanılmayan kod, bir yazılım projesinde artık çalıştırılmayan veya hiçbir yerden çağrılmayan kod parçacıklarıdır. Bunlar, projenin geliştirilmesi sırasında eklenen ancak daha sonra kaldırılmayan özelliklerden, eski işlevselliklerden veya hatalı denemelerden kaynaklanabilir. Dead code, kod tabanını gereksiz yere büyütür, okunabilirliği azaltır ve bakım maliyetini artırır. Ayrıca, bu kodlar gelecekteki geliştiriciler için kafa karıştırıcı olabilir ve yanlışlıkla kullanılabilir. Bu nedenle, dead code’u tespit edip temizlemek, kod tabanının sağlığı için önemlidir. Otomatik kod analizi araçları bu konuda yardımcı olabilir, ancak bazen manuel müdahale ve deneme yanılma da gerekebilir.
Build Süreci: Kodu Çalıştırılabilir Hale Getirme
Build süreci (derleme süreci), yazılım geliştirmenin kritik bir aşamasıdır. Bu süreçte, geliştiricilerin yazdığı kaynak kodları (source code), bilgisayarın anlayabileceği makine koduna veya çalıştırılabilir bir formata dönüştürülür. Bu işlem genellikle bir derleyici (compiler) ve bağlayıcı (linker) gibi araçlar kullanılarak yapılır. Modern yazılım projelerinde build süreci, sadece kodu derlemekle kalmaz, aynı zamanda bağımlılıkları yönetme, testleri çalıştırma, kodu paketleme ve dağıtıma hazırlama gibi birçok adımı da içerir. Bir projenin build’ının “bozulması”, bu sürecin herhangi bir aşamasında bir hata oluştuğu ve projenin başarıyla derlenip çalıştırılamadığı anlamına gelir. Build’ın sürekli olarak başarılı olması, ekibin kod tabanının kararlı ve çalışır durumda olduğunun bir göstergesidir.
Uygulamalı Kısım: Kontrollü Kaos Nasıl Uygulanır?
Bu yöntemi uygulamak, dikkatli planlama ve kontrollü bir yaklaşım gerektirir. İşte adım adım nasıl ilerleyebileceğinize dair bir rehber:
Adım 1: Hedef Belirleme ve Risk Değerlendirmesi
Öncelikle, bu “bilerek bozma” eyleminin amacını net bir şekilde belirlemelisiniz. Belirli bir modül mü, bir özellik mi yoksa genel bir kod tabanı temizliği mi? Ardından, potansiyel riskleri değerlendirin. Hangi kod parçalarını siliyorsunuz? Bu silme işlemi, projenin kritik işlevlerini etkiler mi? Ekibin diğer üyeleri bu durumdan nasıl etkilenecek? Bu soruların cevapları, uygulamanın kapsamını ve aciliyetini belirlemenize yardımcı olacaktır.
Adım 2: Yedek Alma ve Sürüm Kontrolü
Herhangi bir önemli değişikliğe başlamadan önce, mevcut kodunuzun tam bir yedeğini aldığınızdan emin olun. Git gibi bir sürüm kontrol sistemi (version control system) kullanıyorsanız, yeni bir branch (dal) oluşturarak bu çalışmaları izole etmeniz şiddetle tavsiye edilir. Bu, herhangi bir olumsuzluk durumunda kolayca önceki duruma dönebilmenizi sağlar.
Örneğin, Git kullanıyorsanız şu komutları çalıştırabilirsiniz:
# Mevcut dalınızda olduğunuzdan emin olun (örneğin main veya master)
git checkout main
# Yeni bir dal oluşturun ve ona geçin
git checkout -b intentional-breakage-experiment
Bu yeni dal, üzerinde gönül rahatlığıyla deneyler yapabileceğiniz güvenli bir alan sağlar.
Adım 3: Kasıtlı Olarak Kod Silme
Şimdi sıra geldi “işin” en can alıcı kısmına: kod silmeye. Bu aşamada iki ana yaklaşım izlenebilir:
- Kullanılmayan Kodları Hedefleme: Kod analiz araçları (örneğin, JavaScript için ESLint’in unused-vars kuralı veya Java için FindBugs) tarafından işaretlenen veya sizin manuel olarak tespit ettiğiniz kullanılmayan fonksiyonları, değişkenleri veya sınıfları silin.
- Şüpheli Kod Bloklarını Çıkarma: Özellikle karmaşık, anlaşılması zor veya uzun süredir değiştirilmemiş kod bloklarını geçici olarak silin veya yorum satırı haline getirin. Bu, kodun gerçekten ne kadar kritik olduğunu ve hangi diğer parçalara bağlı olduğunu anlamanıza yardımcı olur.
Örnek olarak, bir JavaScript projesinde artık kullanılmayan bir fonksiyonu kaldırdığınızı düşünelim:
// Eski ve kullanılmayan fonksiyon
function oldAndUnusedFunction(data) {
console.log("Bu fonksiyon artık kullanılmıyor.");
// ... karmaşık işlemler
return data * 2;
}
// Yeni ve daha temiz bir fonksiyon (varsa)
function processData(data) {
return data * 1.5; // Daha basit bir işlem
}
// ... kodun geri kalanı
Bu oldAndUnusedFunction‘ı silmek, kod tabanını hafifletecektir. Ancak, eğer bu fonksiyon hala bir yerlerden çağrılıyorsa, silme işlemi hemen build hatasına yol açacaktır.
Adım 4: Build Sürecini Bozma ve Hataları Analiz Etme
Kodunuzu sildikten sonra, projenizin build (derleme) komutunu çalıştırın. Büyük olasılıkla bir veya daha fazla hata alacaksınız. İşte bu noktada, “bilerek bozma”nın asıl amacı ortaya çıkıyor:
- Hata Mesajlarını Anlama: Aldığınız hata mesajlarını dikkatlice inceleyin. Hangi dosyalarda, hangi satırlarda sorunlar yaşanıyor? Bu hatalar, sildiğiniz kodun hangi diğer kısımlarla etkileşimde olduğunu gösterir.
- Bağımlılıkları Keşfetme: Build hatası, genellikle bir kod parçasının, siz farkında olmasanız bile başka yerlerde kullanıldığını gösterir. Bu, kodunuzdaki gizli bağımlılıkları ortaya çıkarır.
- Testlerin Gücünü Görme: Eğer projenizde kapsamlı birim testleri (unit tests) veya entegrasyon testleri (integration tests) varsa, bu testler muhtemelen sildiğiniz kodun etkilediği yerlerde başarısız olacaktır. Bu, testlerinizin ne kadar önemli olduğunu ve hangi senaryoların test edilmediğini anlamanıza yardımcı olur.
Örneğin, bir Node.js projesinde fs modülünden bir fonksiyonu yanlışlıkla silerseniz, build aşamasında veya çalışma zamanında dosya okuma/yazma ile ilgili hatalar alırsınız.
// Yanlışlıkla silinen bir satır örneği
// const fs = require('fs'); // Bu satır eksikse veya yorumlandıysa...
// const fileContent = fs.readFileSync('config.json', 'utf8'); // Hata burada patlayacaktır
Bu hata, fs modülünün nerede kullanıldığını ve hangi işlevler için kritik olduğunu anlamanızı sağlar.
Adım 5: Hataları Düzeltme ve Kodu İyileştirme
Build hatalarını analiz ettikten sonra, şimdi düzeltme zamanı. Bu düzeltme aşaması, genellikle kodunuzu daha iyi hale getirme fırsatıdır:
- Gereksiz Bağımlılıkları Kaldırma: Eğer bir kod parçası silindiğinde, onunla birlikte gelen gereksiz kütüphane veya modül bağımlılıkları da varsa, bunları da kaldırın.
- Kod Tekrarını Giderme: Silinen kodun işlevselliği başka bir yerde zaten varsa, o kodu silmek yerine, her iki yeri de daha temiz ve tekrar etmeyen bir yapıya kavuşturun.
- Yeni Fonksiyonlar Tanımlama: Eğer silinen kodun yerine daha iyi bir çözüm gerekiyorsa, şimdi bunu tasarlayıp uygulamanın tam zamanı.
- Testleri Güncelleme: Silinen veya değiştirilen kodla ilgili testleri güncelleyin veya yeni testler ekleyin.
Bu düzeltme süreci, sadece hataları gidermekle kalmaz, aynı zamanda kod tabanının genel kalitesini artırır. Bu, “kendi kendini iyileştiren” bir sistem oluşturma sürecinin bir parçasıdır.
Adım 6: Tekrarlama ve Otomasyon
Bu süreci bir kerelik bir olay olarak değil, düzenli bir pratik olarak düşünün. Belirli aralıklarla (örneğin, her sprint sonunda veya belirli modüller tamamlandığında) bu “kontrollü kaos” yöntemini uygulayarak kod tabanınızın temiz kalmasını sağlayabilirsiniz. Zamanla, bu süreci otomatikleştirecek araçlar geliştirebilirsiniz. Örneğin, belirli kullanılmayan kodları otomatik olarak tespit edip raporlayan veya hatta bazı basit silme işlemlerini güvenli bir şekilde gerçekleştiren script’ler yazabilirsiniz.
Vaka Analizi: Gerçek Dünya Senaryoları
Bu yöntemin teoriden pratiğe nasıl döküldüğünü daha iyi anlamak için birkaç gerçek dünya senaryosuna bakalım.
Vaka 1: Büyük Bir E-Ticaret Platformunda Eski Modüllerin Temizlenmesi
Bir e-ticaret platformu üzerinde çalışan bir ekip, yıllar içinde birçok farklı geliştirme döngüsünden geçmiş ve eski, artık kullanılmayan veya modası geçmiş modüllerin kod tabanında biriktiğini fark etmişti. Bu modüller, hem bakım zorluğu yaratıyor hem de yeni özelliklerin entegrasyonunu yavaşlatıyordu. Ekip, bu modülleri “bilerek bozma” yöntemiyle temizlemeye karar verdi.
Uygulama:
- Öncelikle, hangi modüllerin gerçekten kullanılmadığına dair bir analiz yapıldı.
- Bu modüllere ait tüm kodlar, ilgili API çağrıları ve veritabanı tabloları geçici olarak devre dışı bırakıldı.
- Build süreci çalıştırıldı ve oluşan tüm hatalar (API çağrıları, veritabanı sorguları, kullanıcı arayüzü bileşenleri vb. ile ilgili) kaydedildi.
- Bu hatalar, hangi modüllerin aslında hala bir yerlerden çağrıldığını veya hangi sistemlerin bu eski modüllere bağımlı olduğunu ortaya çıkardı.
- Sonrasında, gerçekten kullanılmayan kodlar kalıcı olarak silindi. Kullanılmaya devam eden ancak artık modası geçmiş kodlar ise refaktöring sürecine tabi tutularak modern teknolojilerle yeniden yazıldı.
Sonuç: Bu yaklaşım sayesinde, kod tabanı %20 oranında küçültüldü. Bakım maliyetleri düştü ve yeni özelliklerin geliştirme hızı önemli ölçüde arttı. Ayrıca, ekibin hangi modüllerin kritik olduğunu ve hangilerinin artık gereksiz olduğunu daha net anlaması sağlandı.
Vaka 2: Mobil Uygulamada Performans Optimizasyonu
Bir mobil uygulama geliştirme ekibi, uygulamalarının belirli ekranlarda yavaş çalıştığını fark etti. Detaylı analizler sonucunda, bu yavaşlığın büyük ölçüde gereksiz yere yüklenen kütüphanelerden ve arka planda çalışan, artık ihtiyaç duyulmayan servislerden kaynaklandığı anlaşıldı.
Uygulama:
- Ekip, uygulamada kullanılan tüm harici kütüphaneleri ve dahili servisleri listeledi.
- Bu listeden, performans darboğazına neden olduğu düşünülen veya artık kullanılmadığına emin olunan kütüphaneler ve servisler, koddan bilerek çıkarıldı.
- Uygulamanın build’ı tekrar çalıştırıldı ve oluşan hatalar analiz edildi. Örneğin, bir kütüphane çıkarıldığında, o kütüphaneyi kullanan tüm kod parçaları hata verecektir.
- Bu hatalar, hangi kütüphanelerin gerçekten kritik olduğunu ve hangilerinin gereksiz olduğunu gösterdi.
- Gereksiz kütüphaneler kalıcı olarak kaldırıldı. Kritik ancak artık daha az kullanılan kütüphaneler için daha hafif alternatifler araştırıldı veya kodun o kısımları optimize edildi.
Sonuç: Bu “kontrollü kesme” yöntemi, uygulamanın boyutunu %15 azalttı ve özellikle yavaş çalışan ekranlardaki performansı %30’a kadar iyileştirdi. Ekip, hangi kütüphanelerin performansa etkisinin ne kadar büyük olduğunu somut olarak görmüş oldu.
İleri Düzey: İpuçları ve Püf Noktaları
Bu yöntemi daha etkili kullanmak için bazı ileri düzey ipuçları ve püf noktaları şunlardır:
1. Otomatik Kod Analiz Araçlarından Maksimum Faydalanma
ESLint, SonarQube, FindBugs, PMD gibi statik kod analiz araçları, kullanılmayan değişkenleri, fonksiyonları, sınıfları ve potansiyel olarak tehlikeli kod yapılarını tespit etmede harikadır. Bu araçları projenize entegre edin ve düzenli olarak çalıştırın. Bu araçların raporlarını “bilerek kod silme” operasyonlarınız için bir başlangıç noktası olarak kullanın.
2. Test Odaklı Geliştirme (TDD) ile Kombinasyon
Eğer projenizde Test Odaklı Geliştirme (Test-Driven Development – TDD) prensiplerini uyguluyorsanız, bu yöntem daha da güçlü hale gelir. TDD’de, önce test yazılır, sonra bu testin geçmesini sağlayacak kadar kod yazılır. Bu yaklaşım, her zaman çalışır durumda olan bir kod tabanı sağlar. “Bilerek kod silme” pratiği, TDD’nin üzerine eklenen bir “temizlik katmanı” gibi düşünülebilir. Eğer bir kod parçasını silip build’ı bozuyorsanız ve testleriniz bu değişikliği yakalıyorsa, bu hem silme işleminin doğru olduğunu hem de testlerinizin etkinliğini kanıtlar.
3. “Feature Flags” (Özellik Bayrakları) Kullanımı
Özellik bayrakları, belirli özelliklerin çalışma zamanında açılıp kapatılmasına olanak tanır. Bu, “bilerek kod silme” yerine, bir özelliği geçici olarak devre dışı bırakmak için kullanılabilir. Eğer bir özelliğin performansını veya etkisini test etmek istiyorsanız, onu bir özellik bayrağı arkasına gizleyip, build’ı bozmadan deneyler yapabilirsiniz. Daha sonra, eğer özellik gereksizse, bayrağı kaldırıp ilgili kodu temizleyebilirsiniz.
4. Ekip İletişimi ve Şeffaflık
Bu tür “riskli” görünen operasyonları yaparken ekip üyeleriyle açık iletişim halinde olmak çok önemlidir. Birisi kod silip build’ı bozduğunda, bunun kasıtlı bir eylem olduğunu ve amacın ne olduğunu ekibin bilmesi gerekir. Bu, gereksiz paniği önler ve herkesin sürece dahil olmasını sağlar. Düzenli stand-up toplantılarında veya sprint planlama toplantılarında bu tür temizlik operasyonlarından bahsetmek faydalı olacaktır.
5. Kodun “Yaşam Döngüsü”nü Anlamak
Her kod parçasının bir yaşam döngüsü vardır. Başlangıçta gerekli olan bir kod, zamanla gereksiz hale gelebilir. Bu yöntemin amacı, bu gereksizleşen kodları erken tespit edip temizlemektir. Bu, bir nevi “kod bahçıvanlığı”dır; sürekli olarak budama yaparak bahçenin sağlıklı kalmasını sağlamak.
Sonuç
“Dev Log: Bilerek Kod Silmek ve Build’ı Bozmak” başlığı altında ele aldığımız bu yöntem, ilk duyulduğunda alışılmadık gelse de, aslında yazılım projelerinin sağlığını ve sürdürülebilirliğini artırmak için güçlü bir stratejidir. Bu, sadece gereksiz kodu temizlemekle kalmaz, aynı zamanda kod tabanındaki gizli bağımlılıkları ortaya çıkarır, testlerin etkinliğini gösterir ve ekibin kodun yapısı hakkındaki anlayışını derinleştirir. Kontrollü bir şekilde uygulandığında, bu “kaos”, daha temiz, daha verimli ve daha güvenilir bir yazılım geliştirme süreciyle sonuçlanabilir. Bu yaklaşımı benimseyerek, projelerinizin zamanla daha yönetilebilir ve daha az karmaşık hale gelmesini sağlayabilirsiniz. Unutmayın, bazen en iyi ilerleme, geriye dönüp gereksiz yüklerden kurtularak elde edilir.
Sıkça Sorulan Sorular (SSS)
-
S: Bu yöntemin en büyük riski nedir?
C: En büyük risk, kritik bir kod parçasını yanlışlıkla silmek ve bunun sonucunda projenin kararlılığını bozmaktır. Bu nedenle, her zaman yedek almak, sürüm kontrolü kullanmak ve ekip ile iletişim halinde olmak hayati önem taşır. -
S: Hangi tür projelerde bu yöntem daha etkilidir?
C: Özellikle büyük, uzun soluklu ve zamanla karmaşıklaşmış projelerde bu yöntem daha etkilidir. Ayrıca, teknik borcun yüksek olduğu veya kod tabanının anlaşılmasının zorlaştığı durumlarda da faydalı olabilir. -
S: Build’ı bozmak yerine daha güvenli bir yol var mı?
C: Evet, statik kod analiz araçları ve kod incelemeleri (code reviews) gibi yöntemler, kodu silmeden de sorunları tespit etmeye yardımcı olur. Ancak “bilerek bozma” yöntemi, özellikle gizli bağımlılıkları ve beklenmedik etkileşimleri ortaya çıkarmada daha etkilidir. Özellik bayrakları da daha kontrollü bir deneyim sunar. -
S: Bu yöntemi ne sıklıkla uygulamalıyız?
C: Bu, projenin büyüklüğüne, ekibin hızına ve kod tabanının karmaşıklığına bağlıdır. Düzenli olarak, örneğin her sprint sonunda veya belirli bir modül tamamlandığında, küçük adımlarla uygulamak en iyisidir.
#Teknoloji #WebGeliştirme #YazılımMühendisliği #KodOptimizasyonu #DevOps