Kod Yazarken Keşke Daha Önce Öğrenseydim Dediğim 7 Pattern

Yeni başladığımızda kodun çalışması çoğu zaman yeterli görünür.

Bir endpoint cevap veriyor, test geçiyor, ekran açılıyor. Tamamdır.

Sonra proje büyüyor. Aynı kodu başka biri okumaya çalışıyor. Bir değişiklik yapıyorsun ve üç farklı yerde başka bir şey bozuluyor. İşte o noktada "çalışan kod" ile "iyi kod" arasındaki fark ortaya çıkıyor.

Kıdemli geliştiricilerden öğrenilebilecek en değerli şeylerden biri de kullandıkları küçük ama etkili kodlama alışkanlıkları.

Aşağıdaki 7 yaklaşım, belirli bir framework'e bağlı değil. .NET, JavaScript, Python veya başka bir dil kullanıyor olsan da işine yarayabilir.

1. Önce isimlendir, sonra yorumla

Kötü isimlendirilmiş bir değişkeni açıklamak için yorum yazmak kolaydır.

Ama daha iyi çözüm çoğu zaman değişkenin veya metodun adını düzeltmektir.

var x = users.Where(u => u.IsActive).ToList();

Bunun yerine:

var activeUsers = users
    .Where(user => user.IsActive)
    .ToList();

İkinci örnekte kod zaten kendisini anlatıyor.

Bu, yorumların gereksiz olduğu anlamına gelmez. Özellikle neden belirli bir kararın alındığını anlatan yorumlar değerlidir.

Örneğin:

// Dış sistem UTC kabul ettiği için burada local time kullanılmıyor.

Pratik öneri: Bir kod bloğuna yorum yazmadan önce kendine şunu sor:

"Bu yoruma gerçekten ihtiyacım var mı, yoksa kodu daha iyi isimlendirerek kendini açıklamasını sağlayabilir miyim?"

2. Metotları tek bir sorumluluğa yaklaştır

Bir metodun içinde doğrulama, veritabanı işlemi, hesaplama, e-posta gönderimi ve loglama varsa orada bir şeyler fazla büyümüş olabilir.

Örneğin:

CreateUser()

adında bir metodun aynı anda kullanıcı oluşturup, şifre üretip, e-posta gönderip, audit kaydı oluşturması zamanla yönetilmesi zor bir yapıya dönüşür.

Kıdemli geliştiricilerin sık yaptığı şeylerden biri, büyük problemi küçük ve anlamlı parçalara ayırmaktır.

CreateUser
 ├── ValidateUser
 ├── CreateAccount
 ├── SaveUser
 └── SendWelcomeEmail

Her şeyi onlarca küçük metoda bölmek de doğru değil. Ama bir metodun ne yaptığını anlamak için 100 satır okumak gerekiyorsa, bölmeyi düşünmek iyi bir başlangıçtır.

Uygulanabilir öneri: Bir metodun adını okuduğunda "ve" kelimesini kullanmak zorunda kalıyorsan sorumluluklarını tekrar gözden geçir.

3. Erken dönemde hata üret

Bir değerin yanlış olması ileride daha büyük bir hataya dönüşecekse, problemi mümkün olduğunca erken yakalamak daha iyidir.

Örneğin:

if (user == null)
    return;

yerine, metodun gerçekten kullanıcı olmadan çalışması mümkün değilse bunu açıkça belirtmek daha doğru olabilir:

if (user is null)
    throw new ArgumentNullException(nameof(user));

Buradaki fikir sadece exception kullanmak değil. Geçersiz durumu sistemin daha erken aşamasında fark etmek.

API katmanında validation, domain tarafında business rule kontrolü veya constructor içerisinde gerekli alanların zorunlu tutulması aynı düşüncenin farklı örnekleridir.

Bir problemi ne kadar geç fark edersen, kaynağını bulmak genellikle o kadar zorlaşır.

4. Kopyala-yapıştır yerine davranışı düşün

İlk başta iki yerde aynı kodu görmek sorun gibi görünmeyebilir.

Sonra üçüncü, dördüncü ve beşinci kopya gelir.

Bir yerde değişiklik yaparsın, diğerlerini unutursun.

Burada önemli olan her tekrar gördüğünde hemen bir utility veya abstraction oluşturmak değil. Önce tekrar eden kodların gerçekten aynı davranışın parçası olup olmadığını anlamaktır.

Örneğin aynı tarih hesaplama mantığı farklı servislerde tekrar ediyorsa ortak bir yapı mantıklı olabilir.

Ama sadece iki metodun şu an tesadüfen benzer olması, onları hemen ortaklaştırmak için yeterli değildir.

Pratik kural: Aynı kodu gördüğünde önce "Bunlar neden aynı?" diye sor. Cevap gerçekten aynı iş kuralıysa abstraction düşün.

5. Gereğinden fazla akıllı kod yazma

Kıdemli geliştiricilerden öğrenilen en önemli şeylerden biri de bazen en basit çözümün en iyi çözüm olduğudur.

Tek satırda yazılabilen her kod daha iyi değildir.

Örneğin:

var result = users?.Where(x => x.IsActive).Select(x => x.Name).ToList() ?? [];

tek satırda oldukça fazla şey anlatıyor.

Bazen bunu daha okunabilir hale getirmek daha değerlidir:

if (users is null)
    return [];

var activeUsers = users
    .Where(user => user.IsActive)
    .Select(user => user.Name)
    .ToList();

return activeUsers;

Elbette her durumda ikinci yaklaşım kullanılmalı demiyorum. Ama kodu kısa tutmak ile kodu anlaşılır tutmak aynı şey değildir.

Kodun amacı yazarı etkilemek değil, bir sonraki geliştiricinin hızlıca anlayabilmesini sağlamaktır.

6. Değişikliği küçük tut

Bir bug düzeltirken aynı dosyada 15 farklı şeyi yeniden düzenlemek cazip gelebilir.

"Burayı da temizleyeyim."

"Şunu da daha güzel yapayım."

"Bu sınıfı da refactor edeyim."

Sonunda küçük bir bug fix, devasa bir değişikliğe dönüşür.

Küçük ve odaklı değişiklikler incelemeyi, test etmeyi ve gerektiğinde geri almayı kolaylaştırır.

Bu yaklaşımı Git commit'lerinde de uygulayabilirsin:

Fix user login validation

ayrı,

Refactor authentication service

ayrı bir değişiklik olabilir.

Uygulanabilir öneri: Bir task'a başlamadan önce "Bu değişikliğin amacı ne?" sorusunu tek cümleyle yaz. Sonrasında yaptığın değişiklikleri bu cümleyle karşılaştır.

7. Kodu başkasının gözünden oku

Belki de en değerli pattern bu.

Kodu yazdıktan sonra sadece "çalışıyor mu?" diye bakma.

"Ben bu kodu ilk defa görsem anlayabilir miydim?" diye bak.

Bir başka geliştiricinin pull request'ini incelerken de aynı şeyi yap.

İsimler açık mı?

Akış anlaşılır mı?

Hata durumları düşünülmüş mü?

Gereksiz abstraction var mı?

Bir fonksiyonun ne yaptığını anlamak için başka beş dosyaya gitmek gerekiyor mu?

Bu bakış açısı zamanla kod yazma şeklini değiştiriyor. Çünkü artık sadece bilgisayara değil, insanlara da kod yazdığını fark ediyorsun.

Sonuç: Pattern'leri ezberleme, nedenlerini öğren

Bu 7 yaklaşım birer kural kitabı değil.

Her projede aynı şekilde uygulanmaları da gerekmiyor.

Asıl değer, arkasındaki düşünce biçiminde:

• Kodu kendini anlatacak şekilde yaz.

• Sorumlulukları gerektiğinde ayır.

• Hataları erken yakala.

• Gerçek tekrarları azalt.

• Basitliği okunabilirliğin önüne koyma.

• Değişiklikleri küçük ve odaklı tut.

• Kodu başka birinin gözünden okuyabil.

Ve en önemlisi, bunları sadece okuyarak öğrenmeye çalışma.

Bir yazıyı oku. Kendi kodunda dene. Bir başkasının yaklaşımını incele. Sonra kendi deneyimini yaz.

Çünkü yazılım geliştirmede en iyi öğrenme yollarından biri hâlâ aynı: Yaz, yayınla, keşfet ve insanlardan öğren.