Giriş
Modern yazılım geliştirmede, kodun sürdürülebilir, esnek ve okunabilir olması için üç temel prensip asla ihmal edilmemelidir: DRY, KISS ve YAGNI. Bir projeye yeni başlarken veya büyük bir sistemde refactoring yaparken bu üç altın kural hayat kurtarır. Gelin bu prensipleri en temel seviyeden en karmaşık örneklerine kadar detaylı şekilde inceleyelim.
1. DRY Prensibi – Don’t Repeat Yourself
Tanım ve Temel Felsefe
DRY, yani “Kendini Tekrar Etme”, yazılımda aynı bilginin, mantığın ya da işin birden fazla yerde bulunmamasını önerir.
Bunun temel sebebi şudur: Bir bilgi birden fazla yerde varsa, onu güncellemek, hataları önlemek ve sistemi yönetmek giderek zorlaşır.
DRY Neden Hayati?
- Bakım Kolaylığı: Kodun herhangi bir kısmında değişiklik gerektiğinde, tek bir yeri güncellemek yeterli olur.
- Hata Azaltma: Aynı kodun birden fazla kopyası varsa, biri güncellenmediğinde beklenmeyen hatalar oluşabilir.
- Kod Kısalığı ve Temizliği: Kod tabanı daha sade, fonksiyonlar ise daha kısa ve amaca uygun olur.
2. DRY – Kapsamlı Açıklama ve C# Kod Örnekleri
Yanlış Kullanım (Kendini Tekrar)
decimal totalPrice = itemPrice + tax + 15;
decimal invoiceTotal = itemPrice + tax + 15;
decimal cartTotal = itemPrice + tax + 15;Doğru Kullanım (DRY Uygulaması)
const decimal ShippingCost = 15m;
decimal CalculateTotal(decimal itemPrice, decimal tax)
{
return itemPrice + tax + ShippingCost;
}
decimal totalPrice = CalculateTotal(itemPrice, tax);
decimal invoiceTotal = CalculateTotal(itemPrice, tax);
decimal cartTotal = CalculateTotal(itemPrice, tax);DRY Prensibinde Dikkat Edilecekler
- Sabitler için “const”, “static readonly” kullan.
- Utility/Helper metotlarını ortaklaştır.
- Kodun farklı yerlerinde aynı ifadeyi, sorguyu veya algoritmayı tekrar tekrar kullanma.
- DRY aşırıya kaçarsa, bazen soyutlamalar çok karmaşık olabilir. Her tekrar DRY uygulanacak diye zorlamamalı, “mantıksal tekrar” olmasına dikkat edilmeli.
3. DRY ile İlgili Ek Avantajlar ve Sıkça Sorulanlar
Soru: Her tekrar DRY ihlali midir?
Cevap: Hayır. Bazen aynı kod iki yerde “geçici olarak” kullanılabilir; ama güncelleme ihtiyacı doğduysa veya tekrarlar artıyorsa ortaklaştırmak gerekir.
Avantajlar:
- Kodun kapsamı büyüdükçe yönetim kolaylaşır.
- Takımda herkes nerede hangi işin yapıldığını hızlıca bulur.
- Test yazmak, mocklamak ve hata ayıklamak kolaylaşır.
4. KISS Prensibi – Keep It Simple, Stupid
Tanım ve Temel Felsefe
KISS, “basit tut” anlamına gelir. Karmaşık, gereksiz katmanlar, interface’ler, over-engineering projeyi yavaşlatır. KISS, çözümleri sade ve anlaşılır tutmayı önerir.
Neden Basitlik Önemli?
- Hızlı Anlaşılabilirlik: Her ekip üyesi kodun mantığını kolayca çözebilir.
- Daha Az Hata: Karmaşık kodda bug bulmak, debug yapmak daha zordur.
- Bakım Kolaylığı: Zaman geçtikçe, projeyi ilk yazan kişi bile kodu kolayca okuyup geliştirebilir.
5. KISS – Kapsamlı Açıklama ve C# Kod Örnekleri
Yanlış Kullanım (Aşırı Karmaşıklık)
public interface IMultiplier
{
int Multiply(int num, int factor);
}
public class Multiplier : IMultiplier
{
public int Multiply(int num, int factor) => num * factor;
}
IMultiplier multiplier = new Multiplier();
Console.WriteLine(multiplier.Multiply(5, 2));Doğru Kullanım (KISS Uygulaması)
Console.WriteLine(5 * 2);KISS Uygulamasında Dikkat Edilecekler
- Gerekmedikçe soyutlama ve tasarım desenlerinden kaçın.
- Okunabilirliği, performanstan veya “ileride lazım olur” düşüncesinden önde tut.
- Her fonksiyonun tek ve net bir amacı olmalı.
6. KISS’in Dezavantajları ve Sık Sorulan Sorular
Soru: Her şeyi basit yazarsak kod büyüdüğünde zorlanmaz mıyız?
Cevap: Basitliği korurken, modülerliği ve tekrar kullanılabilirliği de göz önünde bulundur. Ancak, erken optimize etmek veya gereksiz abstraction çoğu zaman faydadan çok zarar verir.
Avantajlar:
- Kod tabanı kolay büyür, refactoring gerektiğinde korkulmaz.
- Yeni başlayanlar, stajyerler veya dış ekipler daha hızlı katkı verir.
7. YAGNI Prensibi – You Aren’t Gonna Need It
Tanım ve Temel Felsefe
YAGNI, “Gereksiz işlev ekleme!” prensibidir. Gelecekte lazım olur diye kodu şişirme, her ihtimali önceden çözmeye çalışma.
YAGNI Neden Gereklidir?
- Zaman Kazandırır: Gereksiz kod yazmayarak projeni hızlı teslim edersin.
- Bakım Kolaylığı: Kullanılmayan fonksiyonlar hata riski ve kafa karışıklığı yaratmaz.
- Kod Kısa ve Sade Kalır: Gerçekten ihtiyaç olduğunda eklemek, baştan gereksiz kod yazmaktan daha iyidir.
8. YAGNI – Kapsamlı Açıklama ve C# Kod Örnekleri
Yanlış Kullanım (Gereksiz Fonksiyonlar)
public class Payment
{
public void PayCreditCard() { /* ... */ }
public void PayBitcoin() { /* ... */ }
public void PayWithGold() { /* ... */ } // Kimse sormadı, ihtiyaç yok
}Doğru Kullanım (YAGNI Uygulaması)
public class Payment
{
public void PayCreditCard() { /* ... */ }
public void PayBitcoin() { /* ... */ }
// "Gold" ile ödeme isteği gelirse, o zaman eklenir!
}YAGNI Uygulamasında Dikkat Edilecekler
- Proje başlarken yalnızca ihtiyaç olan özellikleri yaz.
- Fazla generic veya reusable kod yazma hevesine kapılma.
- Her parametre, method veya class gerçekten kullanılacak mı diye düşün.
9. YAGNI’nin Sınırları ve İstisnalar
Bazen, projenin mimari gereksinimleri için küçük bir öngörü eklemek mantıklı olabilir (örn. loglama altyapısı, exception yönetimi), ancak asla gereksiz detaya kaçılmamalı.
10. Pratik Uygulama ve Kod Refactoring
DRY – Pratik Refactoring
// Yanlış (Tekrar)
decimal CalculateNet(decimal price)
{
return price * 0.82m;
}
decimal CalculateTaxed(decimal price)
{
return price * 1.18m;
}// Doğru (Tek bir method)
decimal CalculateWithRate(decimal price, decimal rate)
{
return price * rate;
}KISS – Pratik Refactoring
// Yanlış (Gereksiz class)
public class Printer
{
public void Print(string text)
{
Console.WriteLine(text);
}
}
Printer p = new Printer();
p.Print("Merhaba");// Doğru (Sade)
Console.WriteLine("Merhaba");YAGNI – Pratik Refactoring
// Yanlış (Ekstra parametreler ve methodlar)
public void Log(string message, int level, bool async, string context = null)
{
// Sadece message loglanacaksa fazlasına gerek yok
}// Doğru (Kısa ve yeterli)
public void Log(string message)
{
// ...
}11. Kod İncelemesinde Dikkat Edilecekler
- Kodda tekrar var mı? (DRY)
- Fonksiyonlar gereğinden fazla soyutlanmış mı? (KISS)
- Kullanılmayan method/class/parametre var mı? (YAGNI)
- Kod yeni başlayan için anlaşılır mı?
- Her fonksiyonun amacı açıkça belli mi?
12. En Sık Yapılan Hatalar
- Farklı modüllerde aynı işin tekrar tekrar yapılması.
- Her özelliğe ayrı interface, class ve abstraction yazılması.
- Hiçbir zaman kullanılmayacak kodun projeye dahil edilmesi.
- “Burası büyür” diye, gereksiz esneklik ve generic yapı kurmak.
13. Sıkça Sorulan Sorular
DRY, KISS ve YAGNI birbiriyle çelişir mi?
Hayır. Birlikte uygulandığında en sade ve sürdürülebilir kod tabanı elde edilir.
Bu prensipler küçük projede de uygulanmalı mı?
Evet. Küçük projede başlamak, büyüyünce işini çok kolaylaştırır.
Fazla sadeleştirmek riskli mi?
Kodun amacını bozmadıkça sadeleştirmek avantaj sağlar.
Her kod satırının bir amacı olmalı.
14. Sonuç ve Pratik İpuçları
- Her tekrar, hata riskidir: Kodunu her zaman gözden geçir, tekrarı ayıkla.
- Karmaşıklıktan kaç: Sade, açık ve doğrudan çözümleri tercih et.
- Sadece ihtiyacın olanı kodla: Projende olmayan, müşteri tarafından istenmeyen hiçbir özelliğe zaman harcama.
