Robert C. Martin’dan Temiz Kod Dersleri ile Daha Hızlı Takımlar

Neden Temiz Kod modern ekipler için hâlâ önemli

Robert C. Martin—daha çok “Uncle Bob” olarak bilinir—Temiz Kod hareketini basit bir önermeyle popülerleştirdi: kod, onu değiştirmek zorunda kalacak bir sonraki kişi için yazılmalıdır (çoğu zaman o kişi üç hafta sonra siz olursunuz).

Sürdürülebilirlik ve takım hızı (sade dille)

Sürdürülebilirlik, ekibinizin kodu ne kadar kolay anlayabildiği, güvenle değiştirebildiği ve bu değişiklikleri başka parçaları bozmeden yayına alabildiğidir. Her küçük düzenleme riskli hissettiriyorsa, sürdürülebilirlik düşüktür.

Takım hızı, ekibin zaman içinde istikrarlı olarak faydalı iyileştirmeler sunabilme yeteneğidir. Bu “daha hızlı yazmak” değil—fikri tekrar tekrar çalışır yazılıma çevirebilme hızıdır, sonraki süreçleri yavaşlatan birikim olmadan.

Neden kod kalitesi bir ekip meselesidir

Temiz Kod bir geliştiricinin stil tercihi değildir. Bu ortak bir çalışma ortamıdır. Dağınık bir modül sadece onu yazan kişiyi sinirlendirmez; inceleme süresini uzatır, oryantasyonu zorlaştırır, hataların teşhisini geciktirir ve herkesi temkinli hareket etmeye zorlar.

Birden fazla kişi aynı kod tabanına katkıda bulunduğunda netlik bir koordinasyon aracıdır. Amaç “güzel kod” değil, öngörülebilir değişikliktir: ekipten herhangi bir kişi bir güncelleme yapabilmeli, neyi etkilediğini anlayabilmeli ve rahatça birleştirebilmelidir.

Pratik alışkanlıklar, mükemmeliyet değil

Temiz Kod bir saflık sınavına dönüşürse aşırıya kaçılabilir. Modern ekiplerin gerçek son teslim tarihlerinde işe yarayan yönergelere ihtiyacı var. Buna sürtünmeyi azaltan bir dizi alışkanlık olarak bakın—küçük seçimler zaman içinde daha hızlı teslimata dönüşür.

Makalenin geri kalanında sürdürülebilirliği ve hızı en doğrudan artıran üç alana odaklanacağız:

• İsimlendirme: niyeti anlaşılır kılmak, böylece insanlar niyeti çözmek için daha az zaman harcar.
• Sınırlar: sorumlulukları ayırmak, böylece değişiklikler dalga etkisi yaratmasın.
• Disiplin: kod incelemeleri, testler, refaktör gibi tutarlı uygulamalar kod tabanının tekrar kaosa sürüklenmesini engeller.

Temiz Kod’un temel fikri: değişiklik için optimize edin

Temiz Kod öncelikle estetik ya da kişisel tercih meselesi değildir. Temel hedef pratiktir: kodu okumayı, üzerinde muhakeme yapmayı ve böylece değiştirmeyi kolaylaştırmak.

Ekipler nadiren yeni kod yazamadıkları için zorlanır. Zorlandıkları şey mevcut kodu güvenle değiştiremektir. Gereksinimler değişir, uç durumlar ortaya çıkar ve son teslim tarihleri mühendislerin sistemi “yeniden öğrenmesini” beklemez.

Açık, zekiden üstündür

“Zeki” kod genellikle yazara anlık tatmin sağlar: sıkıştırılmış mantık, beklenmedik kestirmeler veya başkası düzenlemesi gerektiğinde sıkıntı çıkaran karmaşık soyutlamalar.

“Açık” kod bir sonraki değişikliğe göre optimize eder. Düzgün kontrol akışını, açık niyeti ve bir şeyin neden var olduğunu açıklayan isimleri tercih eder. Amaç tüm karmaşıklığı ortadan kaldırmak değil (yazılım bunu kaldıramaz), karmaşıklığı olması gereken yere koymak ve görünür tutmaktır.

Kafa karışıklığının maliyeti ölçülebilir

Kod anlaşılması zor olduğunda ekip bunun için tekrar tekrar ödeme yapar:

• Daha yavaş teslimat: daha fazla zaman okuma, iz sürme ve çift kontrol yapma ile geçer.
• Daha fazla hata: yanlış anlamalar hatalı düzeltmelere veya eksik değişikliklere yol açar.
• Daha fazla yeniden iş: mühendisler “o alanı dokunmak riskli” diye geçici çözümler uygular, bu teknik borcu artırır.

Bu yüzden Temiz Kod doğrudan takım hızına bağlıdır: kafa karışıklığını azaltmak tereddütü azaltır.

İlkeler, buyruk değil

Temiz Kod katı kurallar değil, bir dizi takas demektir. Bazen biraz daha uzun bir fonksiyonu bölmektense açık bırakmak daha anlaşılırdır. Bazen performans kısıtları daha az “güzel” bir yaklaşımı haklı çıkarır. İlke aynıdır: gelecekteki değişiklikleri güvenli, yerel ve anlaşılır tutacak tercihleri seçin—çünkü gerçek yazılımda değişim varsayılandır.

İsimlendirme: okunaklı, sürdürülebilir koda giden en hızlı yol

Kodu değiştirmeyi kolaylaştırmak istiyorsanız isimlerle başlayın. İyi bir isim, okuyucunun yapması gereken “zihinsel çeviriyi” azaltır—böylece davranışa odaklanabilirler, şeylerin ne anlama geldiğini çözmeye değil.

İyi bir isim ne iletmelidir

Yararlı bir isim bilgi taşır:

• Niyet: şeyin neyi temsil ettiği veya ne yaptığı (nasıl yapıldığı değil).
• Kapsam: tek bir değer mi, koleksiyon mu, önbellek mi, istek mi, taslak mı?
• Birimler ve format: Cents vs Dollars, Utc vs yerel zaman, Bytes vs Kb, string vs parse edilmiş obje.
• Kısıtlar: vergi dahil mi, indirimli mi, doğrulanmış mı, maksimum mu?

Bu ayrıntılar eksik olduğunda okuyucu soru sormak zorunda kalır—ya da tahminde bulunur.

Belirsiz vs açık isimler (örnekler)

Belirsiz isimler kararları gizler:

• data, info, tmp, value, result
• list, items, map (bağlam olmadan)

Açık isimler bağlam taşır ve takip sorularını azaltır:

• invoiceTotalCents (birim + domain)
• discountPercent (format + anlam)
• validatedEmailAddress (kısıtlama)
• customerIdsToDeactivate (kapsam + niyet)
• expiresAtUtc (zaman dilimi)

Küçük yeniden adlandırmalar bile hataları önleyebilir: timeout belirsizdir; timeoutMs belirsizliği kaldırır.

Tutarlılık: ürün diliyle eşleşin

Kod, ticket’larda, UI metinlerinde ve müşteri destek konuşmalarında kullanılan aynı kelimeleri kullandığında ekipler daha hızlı hareket eder. Ürün “subscription” diyorsa bir modülde onu plan, diğerinde membership diye çağırmayın—bunlar gerçekten farklı kavramlar değilse.

Tutarlılık ayrıca bir terimi seçip ona sadık kalmayı da içerir: customer vs client, invoice vs bill, cancel vs deactivate. Kelimeler sürüklenirse anlam da sürüklenir.

İsimlendirme koordinasyondur, stil değil

İyi isimler küçük belgeler gibidir. Slack sorularını azaltırlar (“tmp ne tutuyordu yine?”), inceleme sürtüşmesini düşürürler ve mühendis, QA ve product arasındaki yanlış anlamaları önlerler.

Hızlı isim kontrol listesi

İsim koymadan önce sorun:

• Yeni bir ekip üyesi bunu diğer dosyalar açmadan tahmin edebilir mi?
• Gerekli yerde birimler/zaman dilimi/format belirtilmiş mi?
• Ürün terminolojisi ile uyumlu mu?
• data gibi “kapsayıcı kelimeler” kullanılmaktan kaçınıyor mu, yoksa alan net mi?
• Boolean ise okunması açık mı: isActive, hasAccess, shouldRetry gibi?

İsimleri doğru tutmak: zaman içinde “isim sürüklenmesini” önleme

İyi bir isim bir vaattir: bir sonraki okuyucuya kodun ne yaptığını söyler. Sorun şu ki kod, isimlerden daha hızlı değişir. Hızlı değişiklikler ve “yalnızca yayınla” anlarıyla geçen aylarda validateUser() adlı fonksiyon doğrulama ve provisioning ve analiz yapmaya başlar. İsim hâlâ düzenli görünür, ama yanıltıcıdır—ve yanıltıcı isimler zaman kaybettirir.

İsimler bugünün yaptığı şeyi yansıtmalı

Temiz Kod mükemmel isimleri bir kez seçmekle ilgili değildir. İsimleri gerçekle hizalı tutmakla ilgilidir. Eğer bir isim kodun eski yaptığı şeyi tanımlıyorsa, her okuyucu gerçeği uygulamadan tersine mühendislik yapmak zorunda kalır. Bu bilişsel yükü arttırır, incelemeleri yavaşlatır ve küçük değişiklikleri riskli kılar.

Gerçek ekiplerde isim sürüklenmesi nasıl olur

İsim sürüklenmesi nadiren kasıtlıdır. Genellikle şunlardan gelir:

• Hızlı düzeltmeler: zaman baskısı altında davranışı yamamak ama niyeti güncellememek.
• Özellik genişlemesi: bir fonksiyona “bir sorumluluk daha” eklemek çünkü pratik.
• Kopyala-yapıştır: kod kopyalanıp mantık değiştirildi ama orijinal isimler korundu.

İsimleri doğru tutmanın hafif yolları

Bir isim komitesi gerekmiyor. Birkaç basit alışkanlık işe yarar:

• Bir fonksiyon yeni bir sorumluluk kazandığında ya yeniden adlandırın ya da bölün.
• İncelemeye bir kontrol maddesi ekleyin: “İsimler hâlâ davranışı tanımlıyor mu?” (Hızlı bir kontrol, birçok şeyi yakalar.)
• “Bu aslında…” gibi bir yorum yazmak zorunda kalırsanız, bu genellikle yeniden adlandırma sinyalidir.

“Dokunduğun yerde yeniden adlandır” kuralı

Her küçük düzenlemede—bug fix, refaktör veya özellik değişikliğinde—en yakın yanıltıcı adı düzeltmek için 30 saniye ayırın. Bu “dokunduğun yerde yeniden adlandır” alışkanlığı sürüklenmenin birikmesini önler ve günlük çalışmayla okunabilirliğin artmasını sağlar.

Sınırlar: sorumlulukları ayırmak ve dalga etkilerini azaltmak

Temiz Kod sadece düzenli metotlar değil—değişikliğin yerel kalmasını sağlayacak net sınırlar çizmektir. Sınırlar modüllerde, katmanlarda, servislerde, API’lerde ve hatta tek bir sınıf içindeki “kimin ne sorumluluğu”nda ortaya çıkar.

Sorumluluk ayrımı (mutfak benzetmesiyle)

Bir mutfağı düşünün: hazırlık, ızgara, servis (tabaklama) ve bulaşık yıkama istasyonları. Her istasyonun belirgin işi, araçları ve girdileri/çıktıları vardır. Eğer ızgara istasyonu “sadece bu sefer” bulaşıkları yıkamaya başlarsa, her şey yavaşlar: araçlar kaybolur, kuyruklar oluşur ve bir şey bozulduğunda kimin sorumlu olduğu belirsizleşir.

Yazılım da aynı şekilde çalışır. Sınırlar net olduğunda “ızgara istasyonunu” (iş mantığı) değiştirirken “bulaşık yıkamayı” (veri erişimi) veya “servisi” (UI/API formatlama) yeniden düzenlemeniz gerekmez.

Belirsiz sınırlar ekipleri nasıl yavaşlatır

Belirsiz sınırlar dalga etkileri yaratır: küçük bir değişiklik birden fazla alanı düzenlemeyi zorunlu kılar, ekstra test, daha fazla kod inceleme trafiği ve istenmeyen hatalar riskini artırır. Ekip tereddüt etmeye başlar—her değişiklik her şeyi bozacakmış gibi hissedilir.

Yaygın sınır kokuları:

• Karışık sorumluluklar: bir modül hem fiyat hesaplıyor hem veritabanına yazıyor.
• Katmanlar arası kestirmeler: UI doğrudan veritabanını sorguluyor “performans” için.
• Sızan soyutlamalar: bir servis iç tablolarını veya ORM objelerini kamu API’si olarak açıyor.
• Zamanla ilgisiz davranışlar biriktiren “yardımcı” util’ler.

İyi sınırlar günlük işleyişte nasıl hissedilir

İyi sınırlarla ticket’lar öngörülebilir olur. Bir fiyat kuralı değişikliği çoğunlukla fiyat bileşenini dokunur ve testler sınırı aşıp aşmadığınızı çabucak söyler. Kod incelemeleri sadeleşir (“bu alan domain katmanına ait, controller’a değil”), ve hata ayıklama hızlanır çünkü her parçanın bakılacak tek bir yeri ve değişmesi için tek bir nedeni vardır.

Küçük fonksiyonlar ve net niyet: değişikliği güvenli kılmak

Küçük, odaklı fonksiyonlar kodu değiştirmeyi kolaylaştırır çünkü tutulması gereken bağlamı küçültürler. Bir fonksiyonun tek bir işi olduğunda, birkaç girdiye karşı test etmek, yeniden kullanmak ve hataları bir labirentte gezinmeden anlamak mümkündür.

“Bir iş yap” (somut örnekle)

processOrder() adlı bir fonksiyonun: adres doğrulaması, vergi hesaplama, indirim uygulama, kart çekme, e-posta gönderme ve denetim logu yazma gibi işleri yaptığını düşünün. Bu “bir siparişi işlemek” değil—beş karar ve üç yan etkinin bir arada paketlenmesidir.

Daha temiz bir yaklaşım niyeti ayırmaktır:

function processOrder(order) {
  validate(order)
  const priced = price(order)
  const receipt = charge(priced)
  sendConfirmation(receipt)
  return receipt
}

Her yardımcı bağımsız olarak test edilebilir ve yeniden kullanılabilir, üst seviye fonksiyon kısa bir hikâye gibi okunur.

Uzun fonksiyonlar neden risklidir

Uzun fonksiyonlar karar noktalarını ve uç durumları saklar çünkü “ne olur?” mantığını ilgisiz işlerin ortasına gömerler. “Uluslararası adres” için konulmuş tek bir if vergi, kargo ve e-posta metnini etkileyebilir—ancak bağlantı 80 satır ötede gömülü olduğunda bunu görmek zordur.

Pratik refaktör adımları

Küçük başlayın:

• Fonksiyon çıkar (extract function): tutarlı bir bloğu seçip calculateTax() veya formatEmail() gibi bir yere taşıyın.
• Yeniden adlandır: isimleri sonuçları açıklayacak şekilde güncelleyin (applyDiscounts vs doDiscountStuff).
• Tekrarı kaldır: iki dal aynı adımları tekrarlıyorsa ortak bir yardımcıya alın.

Sınırlar (aşırı parçalanmadan kaçının)

Küçük, “her şeye küçük olmak” demek değildir. Bir satırlık sarma fonksiyonlar veya tek bir eylemi anlamak için beş dosyaya zıplatan yapı, açıklığı dolaylılığa çevirmiş olur. Amacınız kısa, anlamlı ve yerel olarak anlaşılır fonksiyonlardır.

Yan etkileri yönetmek: daha az sürpriz, daha kolay hata ayıklama

Bir yan etki, bir fonksiyonun dönüş değerinin dışında yaptığı her değişikliktir. Basitçe: bir yardımcıyı cevabı için çağırırsınız ve o gizlice başka bir şeyi değiştirir—dosya yazar, veritabanı satırını günceller, paylaşılan bir objeyi mutasyona uğratır veya global bir bayrağı çevirir.

Yan etkiler otomatik olarak “kötü” değildir. Problem gizli yan etkilerdir. Bunlar çağıranları şaşırtır ve şaşkınlıklar basit değişiklikleri uzun hata ayıklama oturumlarına dönüştürür.

Yan etkiler ekipleri neden yavaşlatır

Gizli değişiklikler davranışı öngörülemez hale getirir. Bir hata uygulamanın bir bölümünde görünür, ama nedeni “rahatsız edici” bir yardımcıda olabilir. Bu belirsizlik hızı öldürür: mühendisler hatayı çoğaltmak, geçici log eklemek ve sorumluluğun nerede olması gerektiği konusunda tartışmak için zaman harcar.

Ayrıca kodu test etmeyi zorlaştırırlar. Gizlice veritabanına yazan veya global durumu değiştiren bir fonksiyon için setup/cleanup gerekir ve testler geliştirdiğiniz özelle ilgili olmayan sebeplerle kırılmaya başlar.

Sürprizleri azaltan desenler

Açık girdiler ve çıktılar olan fonksiyonları tercih edin. Bir şey dışarıyı değiştirmek zorundaysa bunu açık yapın:

• Bağımlılıkları içeri geçirin (logger, repository, clock) global kullanmayın.
• “Hesapla” ile “yap”ı ayırın: biri hesaplar, diğeri yazma işlemini yapar.
• Yan etkileri dürüstçe isimlendirin (ör. saveUser() vs getUser()).

Yaygın tuzaklar: düşük seviye yardımcıların içinde loglama, paylaşılan konfigürasyon objelerini mutasyona uğratma ve formatlama/doğrulama gibi görünen bir adımda veritabanı yazma.

Hızlı inceleme kontrolü

Kodu incelerken basit bir soru sorun: “Dönüş değerinin dışında ne değişiyor?”

Takipler: Argümanları mı mutasyona uğratıyor? Global duruma mı dokunuyor? Disk/ağa yazıyor mu? Arka plan işleri tetikliyor mu? Eğer evet ise, bu etkiyi açık hale getirebilir miyiz—veya daha iyi bir sınır koyabilir miyiz?

Disiplin: teslimat hızına bileşik etkisi

Temiz Kod sadece bir stil tercihi değildir—disiplin: kod tabanını öngörülebilir tutan tekrarlanan alışkanlıklardır. Bunu “güzel kod yazmak”tan ziyade varyansı azaltan rutinler olarak görün: riskli değişiklikler öncesi test, dokunduğun yerde küçük refaktör, kafa karışıklığını önleyen hafif dokümantasyon ve sorunları erken yakalayan incelemeler.

Şimdi hız vs önümüzdeki ay içindeki hız

Ekipler bazen bugün “hızlı gitmek” için bu alışkanlıkları atlayabilir. Ama bu hız genellikle gelecekten borç alınmıştır. Fatura, kırılgan sürümler, sürpriz regresyonlar ve tek bir küçük değişikliğin zincirleme reaksiyon başlatmasıyla gelir.

Disiplin küçük, sürekli bir maliyeti güvenilirliğe çevirir: daha az acil durum, daha az son dakika düzeltmesi ve ekibin bir sürümü stabil hale getirmek için her şeyi durdurmak zorunda kaldığı durumların azalması. Bir ay içinde bu güvenilirlik gerçek üretkenliğe dönüşür.

Günlük uygulamalar bileşik etki yapar

Birkaç basit davranış hızla birikir:

• Bir bug düzeltirken test ekleyin veya güncelleyin (böylece tekrar kırılmaz).
• Zaten aklınızda olan alanda refaktör yapın (yeniden adlandır, fonksiyon çıkar, tekrarları kaldır).
• Değişiklikleri küçük ve kolay incelenir tutun (kısa ömürlü branchler, net PR açıklamaları).
• Kod incelemesini ortak sahiplik olarak ele alın: “sonraki kişi bunu anlayacak mı?” diye sorun, sadece “çalışıyor mu?” demeyin.

“Temizliğe vaktimiz yok” itirazı

Bu itiraz anlık olarak doğru olabilir—ve zaman içinde maliyetlidir. Pratik uzlaşma kapsamdır: büyük bir temizlik programlamayın; günlük işin kenarlarında disiplin uygulayın. Haftalar içinde küçük yatırımlar teknik borcu azaltır ve teslimat hızını büyük bir yeniden yazım olmadan artırır.

Test etme: sınırları koruyan ve refaktörü güvenli kılan ağ

Testler sadece hataları yakalamakla kalmaz; Temiz Kod bağlamında sınırları korurlar: kodunuzun diğerlerine vaat ettiği halka açık davranışları. İç yapıyı değiştirdiğinizde—modülü ayırma, metodları yeniden adlandırma, mantığı taşıma—iyi testler sözleşmeyi bozmadan geçtiğinizi doğrular.

Hızlı geri bildirim geç kalmış düzeltiden iyidir

Değişiklikten saniyeler sonra kırılan bir test, teşhis için ucuzdur: hâlâ neyi dokunduğunuzu hatırlarsınız. Buna karşılık QA veya prod’da günler sonra bulunan bir hata, iz soğudukça onarması daha riskli ve birçok değişiklik iç içe geçmiştir. Hızlı geri bildirim refaktörü kumardan rutine çevirir.

Zaman kısıtlıysa önce neyi test etmeli

Size özgürlük kazandıracak kapsama öncelik verin:

• Kritik davranışlar: para kazandıran, veriyi koruyan veya kullanıcıyı engelleyen akışlar
• Zor mantık: uç durumlar, parsing, zaman dilimleri, yuvarlama, izinler
• Yaygın hatalar: kirli entegrasyonlar, flaky bağlantılar, retry kuralları

Pratik bir kestirim: bir bug maliyetliyse ya da utanç vericiyse, onu yakalayacak bir test yazın.

Testleri okunaklı tutun—belgeler gibi

Temiz testler değişimi hızlandırır. Onları çalıştırılabilir örnekler gibi ele alın:

• Test isimleri niyeti ifade etmeli: rejects_expired_token() bir gereksinim gibi okunur.
• Gizli yardımcılar yerine açık kurulum tercih edin. Bir yardımcı anlamı saklıyorsa yardımcı fayda sağlamıyor demektir.
• İç adımları assert etmek yerine sonuçları assert edin. Böylece implementasyonu yeniden yazma özgürlüğünüz olur.

Değişimi yavaşlatan kırılgan testlerden kaçının

Testler bugünkü yapıya bağımlı olduğunda vergi haline gelir—aşırı mocklama, özel detayları assert etme veya sadece davranışı umursarken spesifik UI metnine/HTML’e dayanmaya başlamak gibi. Kırılgan testler “gürültü” yüzünden başarısız olur ve ekip kırmızı build’leri görmezden gelmeyi öğrenir. Testlerin sadece anlamlı bir şey bozulduğunda kırıldığından emin olun.

Refaktör alışkanlıkları: borcu kontrol altında tutan küçük adımlar

Refaktör, davranışı koruyan ama kodun yapısını iyileştiren değişikliktir. Yazılımın ne yaptığını değiştirmiyorsunuz; onu bir dahaki değişiklik için daha net ve güvenli hale getiriyorsunuz. Basit bir zihin yapısı İzciler Kuralıdır: kodu bulduğunuzdan biraz daha temiz bırakın. Bu her şeyi parlatmak zorunda değil; bir sonraki kişi (çoğu zaman gelecekteki siz) için sürtünmeyi azaltan küçük iyileştirmeler yapmak yeterlidir.

Hızlı getirisi olan güvenli, küçük refaktörler

En iyi refaktörler düşük riskli ve kolay incelenendir. Sürekli teknik borcu azaltan birkaç örnek:

• Gereksinimler evrildikten sonra değişkenleri, fonksiyonları ve sınıfları doğru ifadeye yeniden adlandırma.
• Uzun bir fonksiyon içinde tek amaçlı bir blok gördüğünüzde extract method uygulama.
• Negasyonları kaldırma, tekrarlanmış dalları birleştirme veya iyi isimli yardımcılar ekleyerek koşulları sadeleştirme.

Bu değişiklikler küçük ama niyeti görünür kılar—bu da hata ayıklamayı kısaltır ve gelecekteki düzenlemeleri hızlandırır.

Refaktör ne zaman yapılmalı (teslimatı durdurmadan)

Refaktör, gerçek işlerle bağlantılıyken en iyi çalışır:

• Yeni özellik eklemeden önce: yolu temizleyin ki yeni kod doğallıkla uysun, zorlayıcı çözümler yapmak zorunda kalmayın.
• Bir hatayı düzelttikten sonra: zayıf noktayı bulduktan sonra aynı sınıf hatanın geri gelmesini zorlaştıracak şekilde düzenleyin.

Ne zaman durmalı

Refaktör, amaçsız bir “yeniden yazma” bahanesi olmamalı. Eğer değişiklik küçük, incelenebilir adılar serisiyle ifade edilemiyorsa ve her adım güvenle merge edilemiyorsa, onu daha küçük kilometre taşlarına bölün—yoksa şimdi yapmayın.

Kod incelemeleri ve standartlar: ilkeleri takım alışkanlığına çevirme

Temiz Kod hız getiriyorsa ancak bu bir takım refleksi haline gelirse gerçek fayda sağlar—kişisel tercih değil. Kod incelemeleri isimlendirme, sınırlar ve küçük fonksiyon gibi ilkelerin takım beklentilerine dönüştiği yerdir.

İncelemenin amacı nedir

İyi bir inceleme şunları optimize eder:

• Ortak anlayış: sadece “LGTM” değil—ekip ne değiştiğini ve nedenini anlamalı.
• Tutarlılık: isimlendirme, yapı ve konvansiyonlar kodu tanıdık kılar.
• Sınır kontrolü: sorumluluklar ayrılmış mı, yoksa katmanlar arası kaçak var mı?
• Risk yönetimi: yan etkiler, uç durumlar ve rollout kaygıları erken tespit edilir.

Hafif bir inceleme şablonu

Tekrar eden bir kontrol listesi onayları hızlandırır ve gereksiz tartışmaları azaltır:

1. Niyet: Bu değişiklik hangi problemi çözüyor? Tasarım basit mi?
2. Okunabilirlik: İsimler spesifik ve dürüst mü? Aşırı zekâcılık var mı?
3. Sınırlar: Sorumluluklar doğru yerde mi (UI/service/domain/data)?
4. Testler: Ne kanıtlıyor? Kırılırsa ne başarısız olur?
5. Riskler: Performans, güvenlik, migrations, geriye dönük uyumluluk
6. Takipler: Bilerek ertelenen borç nedir (bilet)?

Tartışmayı azaltan standartlar

Yazılı standartlar (isimlendirme kuralları, klasör yapısı, hata işleme desenleri) öznel tartışmaları azaltır. “Ben tercih ederim…” yerine “Biz bunu böyle yapıyoruz” demek incelemeleri hızlı ve daha az kişisel yapar.

Naziklik ve netlik

Kod yerine kişiyi eleştirin. Yargılayıcı söylemler yerine soru ve gözlemler tercih edin:

• “process()'u calculateInvoiceTotals() olarak yeniden adlandırabilir miyiz, döndürdüğü şeyi daha iyi anlatır?”
• “Bu fonksiyon persistence sınırını geçiyor—bunun repository’de olması gerekmez mi?”

Yorumlar: faydalı vs gürültü

İyi yorum:

// Why: rounding must match the payment provider’s rules (see PAY-142).

Gereksiz yorum:

// increment i

Yorumlar neden açıklamalı; kodun ne dediğini tekrarlamamalıdır.

Temiz Kodu dayatmadan hızı artırmak için nasıl uygularsınız

Temiz Kod ancak değişikliği kolaylaştırıyorsa yardımcı olur. Bunu uygulamanın pratik yolu onu bir deney gibi ele almaktır: birkaç davranışta anlaşın, sonuçları takip edin ve sürtünmeyi ölçülebilir şekilde azaltanları sürdürün.

Bu, ekiplerin giderek daha fazla AI destekli geliştirmeye dayandığı zamanlarda daha da önem kazanır. İster bir LLM ile iskelet üretin ister Koder.ai gibi bir vibe-coding akışında yineleyin, aynı ilkeler geçerlidir: net isimler, açık sınırlar ve disiplinli refaktör hızlı yinelemeyi zor değişen spagettiden korur. Araçlar çıktıyı hızlandırır; Temiz Kod alışkanlıkları kontrolü korur.

Hızı sürtünme ölçerek ölçün

Stilde tartışmak yerine, yavaşlamayla korelasyon gösteren sinyalleri izleyin:

• PR süreleri: PR açılmasından merge’e kadar geçen süre (ve "inceleme bekliyor" süresi).
• Hata oranı: her sürümde QA/prod’da bulunan hata sayısı.
• Oryantasyon süresi: yeni bir ekip üyesinin güvenli bir değişiklik göndermesi ne kadar sürüyor?
• Yeniden iş: geri alma, yeniden açılan ticket’lar, “düzelt düzelt” oranı.

Tekrarlayan sorunları hafifçe kaydeden bir “sürtünme günlüğü” tutun

Haftada bir, ortak bir notta 10 dakika tekrarlayan sorunları kaydedin:

• “X’in nerede uygulandığını bulmak zor.”
• “İlgisiz değişiklikler için testler kırılıyor.”
• “Bu modül çok fazla değişme nedeni tutuyor.”

Zamanla örüntüler ortaya çıkar. Bu örüntüler hangi Temiz Kod alışkanlığının sıradaki yatırım olması gerektiğini gösterir.

Küçük bir takım anlaşması oluşturun

Basit ve uygulanabilir tutun:

• İsimlendirme kuralları: niyet gösteren isimleri tercih edin; data, manager, process gibi belirsiz kelimeleri kapsam belirtilmedikçe yasaklayın.
• Sınır kuralları: bir modül = net bir sorumluluk; persistense, iş kurallarına ve formatlamaya karışmayın.
• Test asgari şartları: her bug fix bir test ekler; yeni davranış uygun seviyede bir testle gelir.

30 günlük uygulama planı (her hafta bir alışkanlık)

• 1. Hafta — İsimlendirme: dokunduğunuz en kötü isimleri yeniden adlandırın; PR’larda “isim hâlâ uyuyor mu?” sorusunu zorunlu kılın.
• 2. Hafta — Sınırlar: bir bağımlılık dikişini çıkarın (ör. harici API’yı bir arayüzle sarmalayın).
• 3. Hafta — Yan etkiler: bir akışı daha öngörülebilir yapın (gizli mutasyon yerine dönüş değeri; kenarda loglama).
• 4. Hafta — Test ile refaktör: bir hotspot dosya seçin ve küçük PR’larla iyileştirin.

Her haftanın sonunda metrikleri gözden geçirin ve hangi uygulamaları sürdürmeye karar verdiğinize karar verin.

Hızlı kontrol listesi

• Yeni biri değişiklik yerini 2 dakikadan kısa sürede bulabiliyor mu?
• Son düzenlemeden sonra isimler hâlâ davranışı yansıtıyor mu?
• İş mantığı ile IO arasında net bir sınır var mı?
• Bir kısmı değiştirmek için beş yeri aynı anda değiştirmek gerekiyor mu?
• Bu PR gelecekteki işi azalttı mı (veya artırdı mı)?