Kod, Bilgisayarlar İçin Değil İnsanlar İçindir
Yazılım dünyasının efsanevi ismi Martin Fowler'ın dediği gibi: 'Her aptal bilgisayarın anlayabileceği kodu yazabilir. İyi yazılımcılar, insanların anlayabileceği kodu yazar.' Bir projeye başladığınızda, ilk önceliğiniz genellikle kodu 'çalıştırmak' olur. Ancak proje büyüdükçe, sadece çalışan ama okunmayan kodlar, geliştirme hızını dramatik bir şekilde düşürür. Bu duruma yazılım literatüründe Spagetti Kod denir. Karışık, düğüm olmuş ve bir yerini çektiğinizde bambaşka bir yerin bozulduğu yapılar, projenin ölüm fermanıdır.
Teknik Borç (Technical Debt) Nedir?
Hızlı çıktı üretmek adına kaliteden ödün verdiğiniz her an, geleceğe bir borçlanırsınız. Bu borç, faiziyle birlikte büyür. Başlangıçta 1 saatte geliştirdiğiniz bir özellik, teknik borç biriktiğinde 1 haftada geliştirilemez hale gelir. Clean Code (Temiz Kod), bu borcu minimumda tutma disiplinidir.
Temiz Kodun 5 Temel Direği: SOLID
Nesne Yönelimli Programlamanın (OOP) temelini oluşturan SOLID prensipleri, sürdürülebilir bir mimari için hayati önem taşır. Aşağıdaki tabloda bu prensiplerin ne anlama geldiğini ve ihlal edildiğinde neler olduğunu inceleyelim:
| Prensip | Açıklama | İhlal Sonucu |
|---|---|---|
| S - Single Responsibility | Bir sınıfın veya fonksiyonun değişmek için sadece tek bir nedeni olmalıdır. | Tanrı Nesneler (God Objects) oluşur, bakım zorlaşır. |
| O - Open/Closed | Kod, geliştirmeye açık ancak değişime kapalı olmalıdır. | Mevcut kodu bozmadan yeni özellik eklemek imkansızlaşır. |
| L - Liskov Substitution | Alt sınıflar, türetildikleri üst sınıfların yerine kullanılabilmelidir. | Beklenmedik çalışma zamanı hataları (Runtime Errors) alınır. |
| I - Interface Segregation | İstemciler kullanmadıkları arayüzlere bağımlı olmaya zorlanmamalıdır. | Gereksiz bağımlılıklar ve şişmiş arayüzler oluşur. |
| D - Dependency Inversion | Üst seviye modüller, alt seviye modüllere doğrudan bağımlı olmamalıdır. | Sıkı sıkıya bağlı (Tightly Coupled) ve test edilemez sistemler. |
İsimlendirme Sanatı (Naming Convention)
Kod yazarken en çok zorlandığımız anlardan biri değişken isimlendirmektir. Ancak var d; yerine var daysSinceCreation; yazmak, kodun okunabilirliğini %100 artırır. İyi bir isimlendirme:
- Niyet Belli Etmeli: Değişkenin ne işe yaradığı isminden anlaşılmalı.
- Telaffuz Edilebilir Olmalı: Ekip içi iletişimde rahatça söylenebilmeli.
- Aranabilir Olmalı: CTRL+F yaptığınızda kolayca bulunabilmeli (Tek harfli değişkenlerden kaçının).
Refactoring (Yeniden Düzenleme) Ne Zaman Yapılmalı?
Refactoring, kodun dış davranışını değiştirmeden iç yapısını iyileştirme sürecidir. Bu süreç ayrı bir 'proje' olarak değil, günlük geliştirme rutininin bir parçası olarak ele alınmalıdır. Robert C. Martin'in Boy Scout Kuralı burada geçerlidir: 'Kamp alanını (kodu) bulduğundan daha temiz bırak.' Bir dosyada değişiklik yaparken, gördüğünüz ufak bir isimlendirme hatasını veya gereksiz bir yorum satırını düzeltmek, zamanla kod kalitesini devasa oranda artırır.
DRY ve KISS Prensipleri
Kod tekrarı (Code Duplication), yazılımın en büyük düşmanlarından biridir. Aynı mantığı iki farklı yerde kopyala-yapıştır ile kullandıysanız, bir hata çıktığında iki yeri de düzeltmeniz gerekir. DRY (Don't Repeat Yourself) prensibi bunu yasaklar. Öte yandan, KISS (Keep It Simple, Stupid) prensibi, çözümlerin mümkün olan en basit haliyle uygulanmasını öğütler. Aşırı mühendislik (Over-engineering), basit bir problemi karmaşık bir mimariyle çözmeye çalışmaktır ve genellikle israfla sonuçlanır.
Unutmayın, kod bir kez yazılır ama binlerce kez okunur. Gelecekteki kendinize ve ekip arkadaşlarınıza bir iyilik yapın: Temiz kod yazın.
Sıkça Sorulan Sorular
Modern Web Projenizi Vue.js & Nuxt.js ile Hayata Geçirelim!
Kurumsal siteniz ya da özel projeniz için uzman ekibimizle hemen iletişime geçin, dijital farkınızı ortaya koyalım!
