Mert Özen Her Satırda Daha İleri

Blog

Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.

Seriler
48 yazı bulundu
Clean Code'da Naming: Niyet Anlatan İsimler, .NET Naming Guideline'ları ve Türkçe-İngilizce Karışımı
Yazılım Tasarımı SERİ 02

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.

7 Kas 2026 14 dk 0
Clean Code Nedir? Okunabilirlik, Değişim Maliyeti ve 2025'teki İkinci Baskı
Yazılım Tasarımı SERİ 01

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.

7 Kas 2026 16 dk 0
Prensiplerin Eleştirisi: CUPID, Over-Engineering ve SOLID'in Gerçekten Gerektiği Yer
Yazılım Tasarımı SERİ 12

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ı.

7 Kas 2026 11 dk 3
Component Prensipleri: .NET Solution'ını Project'lere Bölmek (REP, CCP, CRP, ADP, SDP, SAP)
Yazılım Tasarımı SERİ 11

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.

7 Kas 2026 12 dk 2
Daha Az Bilinen Prensipler: Separation of Concerns, Least Astonishment, Fail Fast, CQS ve GRASP
Yazılım Tasarımı SERİ 10

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.

7 Kas 2026 12 dk 2
Composition over Inheritance: Fragile Base Class, Delegation ve Davranışı Takmak
Yazılım Tasarımı SERİ 09

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.

7 Kas 2026 13 dk 2
DRY, KISS ve YAGNI: Tekrar, Basitlik ve "Şimdilik Gerekmiyor"
Yazılım Tasarımı SERİ 08

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.

7 Kas 2026 12 dk 1
Dependency Inversion Principle: DIP, DI ve IoC Arasındaki Fark ve Composition Root
Yazılım Tasarımı SERİ 07

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ığı.

7 Kas 2026 12 dk 3
Interface Segregation Principle: Şişman Interface'ler ve Role Interface'ler
Yazılım Tasarımı SERİ 06

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.

7 Kas 2026 12 dk 2
Liskov Substitution Principle: Behavioral Subtyping ve .NET'teki NotSupportedException'lar
Yazılım Tasarımı SERİ 05

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.

7 Kas 2026 15 dk 1
Open/Closed Principle: Değiştirmeden Genişletmek ve Spekülatif Genellik Tuzağı
Yazılım Tasarımı SERİ 04

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.

7 Kas 2026 12 dk 1
Single Responsibility Principle: "Tek İş" Değil, Tek Actor
Yazılım Tasarımı SERİ 03

Single Responsibility Principle: "Tek İş" Değil, Tek Actor

SRP "bir class tek şey yapar" demek değildir; Martin'in tanımıyla bir module tek bir actor'a, yani aynı değişikliği isteyen tek bir kişi ya da gruba karşı sorumlu olmalıdır. Muhasebenin bir değişikliğinin İK raporunu bozduğu Employee örneği, veriyi paylaşıp davranışı ayırmak, Facade, .NET'teki Stream/StreamWriter/Encoding ayrımı ve fragmentation tuzağı.

7 Kas 2026 13 dk 1
Blog Haritası