Senior Engineer’lardan Öğrendiğim 6 Kodlama Pattern’i

Kariyerimin başında senior engineer’ların daha iyi olmasının sebebinin daha fazla framework, daha fazla design pattern ve daha fazla teknik detay bilmeleri olduğunu düşünüyordum.

Zamanla asıl farkın bu olmadığını anladım.

En iyi senior engineer’lar çoğu zaman gösterişli kod yazmaz. Kodları basit, okunabilir ve bazen sıkıcı görünür. Ama bu kod daha kolay test edilir, daha kolay debug edilir ve daha sonra daha güvenli değiştirilir.

İyi kod değerini sadece bugün çalışarak göstermez. Gereksinimler değiştiğinde, production’da bug çıktığında veya yeni bir geliştirici kodu anlamaya çalıştığında gösterir.

İşte senior engineer’lardan öğrendiğim altı kodlama pattern’i.

1. Happy Path’i görünür yaparlar

Zayıf kod genellikle validation, error handling, database logic ve response oluşturmayı tek bir fonksiyonun içine karıştırır.

Senior engineer’lar ana akışı görünür yapar.

Önce geçersiz durumları ele alırlar. Sonra ana akış yukarıdan aşağıya kolayca okunur.

if (!user) {
  throw new Error("User is required");
}

if (!items.length) {
  throw new Error("Order must contain items");
}

const order = createOrder(user, items);
return order;

Bu yaklaşım iç içe koşulları azaltır ve kodu daha okunabilir hale getirir.

2. İsimleri teknik detaya göre değil, iş anlamına göre verirler

processData, handleItems, updateRecord gibi isimler çok şey anlatmaz.

Daha iyi isimler şunlardır:

calculateInvoiceTotal()
markInvoiceAsPaid()
syncCustomerSubscriptions()

İyi isim kodun niyetini açıklar.

Kural:

Fonksiyonları ve değişkenleri sadece teknik işleme göre değil, domain anlamına göre adlandırın.

3. Önemli kuralları atlanamayacak yere koyarlar

Bazı kurallar sadece application code içinde korunmamalıdır.

Örneğin bir kullanıcının aynı plana iki kez abone olmaması gerekiyorsa, insert öncesi yapılan basit bir query her zaman yeterli değildir. Concurrent request durumunda iki istek aynı anda kontrolden geçebilir.

Daha güçlü çözüm database constraint kullanmaktır:

$table->unique(['user_id', 'plan_id']);

Sonra uygulama bu hatayı temiz bir validation response’a çevirebilir.

Kural:

Kritik kuralları en güçlü boundary’de koruyun.

4. “Belki lazım olur” mimarisinden kaçınırlar

Birçok sistem, henüz var olmayan gelecek ihtiyaçlar için gereğinden fazla karmaşık hale gelir.

Küçük bir özellik bir anda interface, factory, strategy, event ve config dosyalarıyla büyür.

Senior engineer’lar geleceği düşünür, ama henüz gerçek olmayan problemler için büyük mimari kurmaz.

Kural:

Kod gerçekten ihtiyaç duymadan abstraction eklemeyin.

Esnek kod çok katmanlı kod değildir. Esnek kod, gerektiğinde güvenle değiştirilebilen açık koddur.

5. Side effect’leri görünür yaparlar

Şu fonksiyon basit görünebilir:

updateUserProfile(user);

Ama arka planda database update, cache temizleme, email gönderme, audit log veya event dispatch yapıyor olabilir.

Bu etkiler gizliyse debug zorlaşır.

Daha açık versiyon:

updateUserProfile(user);
clearUserCache(user.id);
recordAuditLog(user);
dispatchProfileUpdatedEvent(user);

Kural:

Önemli dış etkileri masum görünen isimlerin arkasına saklamayın.

6. Kodu daha kolay değiştirilebilir bırakırlar

Junior developer genellikle şunu sorar: Çalışıyor mu?

Senior engineer ise şunu da sorar: Bu kod daha sonra güvenle değiştirilebilir mi?

Bu fark önemlidir.

İyi kod sadece testleri geçen kod değildir. Başka bir geliştiricinin anlayabileceği ve değiştirebileceği koddur.

Bu şunları gerektirir:

• gereksiz clever one-liner’lardan kaçınmak;

• sorumlulukları ayırmak;

• business logic ile presentation detaylarını karıştırmamak;

• yorum gerekiyorsa nedenini açıklamak;

• bir sonraki değişikliği düşünmek.

Sonuç

Senior engineer’lardan öğrendiğim en iyi pattern’ler gösterişli değildi.

Basitti:

• Happy path’i görünür yapmak.

• İsimleri anlama göre vermek.

• Kuralları güçlü boundary’lerde korumak.

• Gereksiz mimariden kaçınmak.

• Side effect’leri açık göstermek.

• Kodu daha kolay değiştirilebilir bırakmak.