Robert C. Martin’in (Uncle Bob) aynı adlı kitabıyla popülerleşen Clean Code kavramı, yazılım geliştirmenin en temel disiplinlerinden biridir. Temiz kod, yalnızca çalışan değil aynı zamanda okunabilir, anlaşılabilir ve bakımı kolay olan koddur. Bir yazılımcının zamanının %70’ini kod okuyarak geçirdiği düşünüldüğünde, okunabilirliğin önemi daha da belirginleşir.
Temiz Kod Nedir?
Temiz kod, başka bir geliştiricinin (veya gelecekteki kendinizin) minimum çabayla anlayabileceği koddur. Bjarne Stroustrup’un ifadesiyle: “Temiz kod, tek bir şeyi iyi yapan koddur.”
Bu espri, kodun okunabilirliğinin ne kadar kritik olduğunu mükemmel şekilde özetler.
Clean Code Prensipleri
1. Anlamlı İsimlendirme
Değişken, fonksiyon ve sınıf isimleri amacı açıkça ifade etmelidir. İsimlendirme, kodun kendi kendini belgelemesinin ilk adımıdır.
d = 7
lst = get_data()
def calc(a, b): …
# IYI – Anlamli isimler
days_until_deadline = 7
active_customers = get_active_customers()
def calculate_monthly_revenue(sales, expenses): …
2. Tek Sorumluluk Prensibi (SRP)
Her fonksiyon ve sınıf yalnızca tek bir işi yapmalıdır. Bir fonksiyon birden fazla şey yapıyorsa, parçalara bölünmelidir.
3. Küçük Fonksiyonlar
Fonksiyonlar kısa olmalıdır. Bir fonksiyon ideal olarak 20 satırı geçmemelidir. Uzun fonksiyonlar, anlaşılması ve test edilmesi zor yapılardır.
4. DRY (Don’t Repeat Yourself)
Aynı mantığı birden fazla yerde tekrarlamayın. Tekrarlayan kod, hata düzeltme ve güncelleme maliyetini katlar.
5. KISS (Keep It Simple, Stupid)
Basit çözümler her zaman karmaşık çözümlerden üstündür. Gereksiz soyutlamalardan ve aşırı mühendislikten kaçının.
Clean Code Kontrol Listesi
| Kriter | Temiz Kod | Kirli Kod |
|---|---|---|
| İsimlendirme | Amacı açıklar | Kısaltmalar, tek harfler |
| Fonksiyonlar | Kısa, tek sorumlu | Uzun, çok amaçlı |
| Yorumlar | Neden sorusuna yanıt | Ne yaptığını açıklar |
| Hata yönetimi | Exception ile yapılandırılmış | Hata kodları, sessiz hatalar |
| Bağımlılıklar | Gevşek bağlı (loose coupling) | Sıkı bağlı (tight coupling) |
| Testler | Kapsamlı birim testler | Test yok veya yetersiz |
SOLID Prensipleri
- Single Responsibility: Her sınıfın tek bir değişim nedeni olmalı
- Open/Closed: Genişlemeye açık, değişikliğe kapalı
- Liskov Substitution: Alt sınıflar üst sınıfların yerine geçebilmeli
- Interface Segregation: Büyük arayüzler yerine küçük, odaklı arayüzler
- Dependency Inversion: Somut sınıflara değil, soyutlamalara bağımlı olun
Kod Kokuları (Code Smells)
Martin Fowler’ın tanımladığı kod kokuları, refactoring ihtiyacını işaret eden belirtilerdir:
- Uzun metot: 20+ satırlık fonksiyonlar
- Tanrı sınıfı: Her şeyi bilen devasa sınıflar
- Feature envy: Bir sınıfın başka sınıfın verisini aşırı kullanması
- Shotgun surgery: Tek değişiklik için birçok dosyayı düzenleme
- Primitive obsession: Nesneler yerine ilkel tiplerin aşırı kullanımı
- Dead code: Çalışmayan veya erişilmeyen kod blokları
TAGUM’da Kod Kalitesi Kültürü
TAGUM ekibinde Clean Code prensipleri günlük geliştirme pratiklerinin ayrılmaz parçasıdır. PratikEsnaf.Net, DeskTR ve ixir.ai projelerimizde zorunlu kod review süreci, SonarQube ile otomatik kod kalite analizi ve düzenli refactoring sprintleri uyguluyoruz. Kodun okunabilirliği ve sürdürülebilirliği, hız kadar önemli bir metriktir.
Sonuç
Temiz kod yazmak bir disiplin ve sürekli pratik gerektirir. Kısa vadede daha fazla zaman alıyor gibi görünse de uzun vadede geliştirme hızını artırır, hata oranını düşürür ve ekip verimliliğini yükseltir. Her satır kodun bir iletişim aracı olduğunu unutmayın: bugün yazdığınız kod, yarın bir başkasının okuması gereken bir mesajdır.
→ Kaliteli, sürdürülebilir yazılım çözümleri için TAGUM’un uzman ekibiyle çalışın
