Blog
Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.
Clean Code'da Fonksiyonlar: Küçük Method, Tek Soyutlama Seviyesi ve Guard Clause
Bir method tek bir iş yapmalı ve tek bir soyutlama seviyesinde kalmalı: legacy OrderService'teki 136 satırlık ProcessData guard clause, step-down rule, parameter object ve CQS (Command-Query Separation) ile bölününce Cognitive Complexity 92'den en yüksek 5'e iniyor ve dokuz senaryoda davranış aynı kalıyor. Yazı flag argument'ları, out yerine record dönmeyi, ThrowIfNull gibi guard helper'ları ve aşırı bölmenin bedelini (Ousterhout'un shallow method eleştirisi) gerçek çıktılarla anlatıyor.
Clean Code'da Naming: Niyet Anlatan İsimler, .NET Naming Guideline'ları ve Türkçe-İngilizce Karışımı
İyi isim, okuyucunun kodu açmadan soracağı soruları cevaplar: legacy OrderService'teki d, tmp2, k ve int t isimlerini domain diliyle ve sabitlerle değiştirmek davranışı değiştirmeden (beş senaryoda aynı toplam) fiyat hesabını okunur kılıyor. Yazı .NET naming kurallarını, Hungarian notation'ı, Türkçe-İngilizce karışık isimleri ve ToLower()'ın tr-TR'de Id'yi ıd yapan Turkish-I tuzağını gerçek çıktılarla anlatıyor.
Clean Code Nedir? Okunabilirlik, Değişim Maliyeti ve 2025'teki İkinci Baskı
Clean Code, çalışan kodun ucuza değiştirilebilir ve okunabilir olmasıdır: Bookstore'un legacy OrderService'inde aynı sepet Türkçe I tuzağı, kopyalanıp ayrışmış fiyat hesabı ve DateTime.Now yüzünden dört farklı tutar üretiyor. 2025'te çıkan ikinci baskı kitabı Code, Design, Architecture ve Craftsmanship kısımlarıyla yeniden yazdı; seri bu 609 satırlık dosyayı adım adım temizleyecek.
Prensiplerin Eleştirisi: CUPID, Over-Engineering ve SOLID'in Gerçekten Gerektiği Yer
SOLID'in değeri bağlama bağlı: çok ekipli, uzun ömürlü ve sık değişen kodda değişim maliyetini düşürür, script, prototip ve küçük CRUD uygulamalarında ise çoğu zaman yalnız katman ekler. Aynı bildirim özelliğinin minimum, dengeli ve aşırı üç tasarımında push kanalı eklemenin ölçülen maliyeti, Dan North'un CUPID önerisi ve Ousterhout'un deep module uyarısı.
Component Prensipleri: .NET Solution'ını Project'lere Bölmek (REP, CCP, CRP, ADP, SDP, SAP)
Bir solution'ı project'lere bölerken birlikte değişen class'lar aynı project'te durmalı, bağımlılıklar döngüsüz ve stabil olana doğru akmalı, stabil project'ler de abstract olmalı. Herkesin bağımlı olduğu Common project'inin bedelini ölçmek, instability ve abstractness metriklerini gerçek bir solution'da hesaplamak ve main sequence'i doğru okumak.
Daha Az Bilinen Prensipler: Separation of Concerns, Least Astonishment, Fail Fast, CQS ve GRASP
SOLID dışındaki prensipler günlük kararların çoğunu verir: Fail Fast hatayı açılışta yakalar, CQS sorunun cevabı değiştirmesini engeller, GRASP de bir sorumluluğun hangi class'a ait olduğunu sorar. Options validation ile yazım hatasını yakalamak, Math.Round sürprizi, getter'da yan etki, Explicit Dependencies, Persistence Ignorance ve prensipler çatışınca karar vermek.
Composition over Inheritance: Fragile Base Class, Delegation ve Davranışı Takmak
Inheritance, subclass'ı base class'ın implementation detaylarına bağlar; base class'taki zararsız bir değişiklik subclass'ı sessizce bozabilir, composition ve delegation ise yalnız sözleşmeye bağımlı kalır. Fragile base class'ı gerçek çıktıyla göstermek, iki eksende büyüyen davranışlarda class patlaması ve inheritance'ın doğru olduğu yerler: Collection<T> hook'ları ve sealed.
DRY, KISS ve YAGNI: Tekrar, Basitlik ve "Şimdilik Gerekmiyor"
DRY kodun değil bilginin tek kaynağı olmasıdır; farklı nedenlerle değişen iki kuralı aynı göründükleri için birleştirmek DRY değil, yanlış bir abstraction'dır. Metz'in wrong abstraction'dan geri dönüşü, rule of three, KISS'i CA1502 ile ölçmek ve Fowler'ın YAGNI için saydığı dört maliyet.
Dependency Inversion Principle: DIP, DI ve IoC Arasındaki Fark ve Composition Root
DIP, compile-time bağımlılığın detaydan abstraction'a doğru akmasını ve abstraction'ın onu kullanan tarafa ait olmasını ister; DI yalnızca bağımlılığı dışarıdan verme tekniğidir, IoC ise akışın framework'e geçmesidir. Interface'in hangi project'te durduğu, Program.cs'in composition root olarak kullanılması ve service locator'ın neden DIP'i boşa çıkardığı.
Interface Segregation Principle: Şişman Interface'ler ve Role Interface'ler
ISP, hiçbir client'ın kullanmadığı method'lara bağımlı olmaya zorlanmaması, interface'in class'a göre değil client'a göre (role interface) kesilmesidir. 14 method'luk IOrderRepository'ye eklenen tek method'un üç dosyayı kırması, okuma/yazma/rapor rollerine bölmek ve DI'da forwarding, .NET 10'da hâlâ ayrı duran IReadOnlyList<T> ile IList<T>, tek method'luk interface enflasyonu ve default interface method ile ISP'yi delmenin bedeli.
Liskov Substitution Principle: Behavioral Subtyping ve .NET'teki NotSupportedException'lar
LSP, bir subtype'ın derleyiciyi değil base type'ın contract'ını da karşılamasını ister: precondition güçlenmez, postcondition zayıflamaz, invariant ve history constraint korunur. Bookstore stok modülünde üç gerçek ihlal, T[] ve ReadOnlyCollection'ın IList<T>.Add'de fırlattığı NotSupportedException, Stream.CanSeek ile capability query ve contract'ı abstract bir xUnit test class'ıyla bütün implementation'lara karşı doğrulamak.
Open/Closed Principle: Değiştirmeden Genişletmek ve Spekülatif Genellik Tuzağı
OCP, yeni bir davranışı mevcut ve çalışan kodu açmadan, yeni bir implementation olarak ekleyebilmektir; ama her kod yalnızca belirli bir değişim eksenine karşı kapatılabilir. Büyüyen bildirim switch'ini INotificationChannel ve .NET 8 keyed services ile kapatmak, HttpClient'ın DelegatingHandler zinciri, Func ile hafif extension point'ler ve spekülatif genelliğin bedeli.