17 Mar 2025·8 dk
Robert C. Martin’dan Temiz Kod Dersleri ile Daha Hızlı Takımlar
Robert C. Martin’in Clean Code fikirlerini keşfedin: daha iyi isimlendirme, net sınırlar ve günlük disiplinle sürdürülebilirliği artırıp takım hızını yükseltin.
Robert C. Martin’in Clean Code fikirlerini keşfedin: daha iyi isimlendirme, net sınırlar ve günlük disiplinle sürdürülebilirliği artırıp takım hızını yükseltin.
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, 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.
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.
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:
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.
“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.
Kod anlaşılması zor olduğunda ekip bunun için tekrar tekrar ödeme yapar:
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.
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.
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.
Yararlı bir isim bilgi taşır:
Cents vs Dollars, Utc vs yerel zaman, Bytes vs Kb, string vs parse edilmiş obje.Bu ayrıntılar eksik olduğunda okuyucu soru sormak zorunda kalır—ya da tahminde bulunur.
Belirsiz isimler kararları gizler:
data, info, tmp, value, resultlist, 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.
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.
İ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.
İsim koymadan önce sorun:
data gibi “kapsayıcı kelimeler” kullanılmaktan kaçınıyor mu, yoksa alan net mi?isActive, hasAccess, shouldRetry gibi?İ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.
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.
İsim sürüklenmesi nadiren kasıtlıdır. Genellikle şunlardan gelir:
Bir isim komitesi gerekmiyor. Birkaç basit alışkanlık işe yarar:
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.
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.
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 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ı:
İ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, 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.
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 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.
Küçük başlayın:
calculateTax() veya formatEmail() gibi bir yere taşıyın.applyDiscounts vs doDiscountStuff).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.
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.
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.
Açık girdiler ve çıktılar olan fonksiyonları tercih edin. Bir şey dışarıyı değiştirmek zorundaysa bunu açık yapın:
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.
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?
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.
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.
Birkaç basit davranış hızla birikir:
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.
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.
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.
Size özgürlük kazandıracak kapsama öncelik verin:
Pratik bir kestirim: bir bug maliyetliyse ya da utanç vericiyse, onu yakalayacak bir test yazın.
Temiz testler değişimi hızlandırır. Onları çalıştırılabilir örnekler gibi ele alın:
rejects_expired_token() bir gereksinim gibi okunur.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, 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.
En iyi refaktörler düşük riskli ve kolay incelenendir. Sürekli teknik borcu azaltan birkaç örnek:
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, gerçek işlerle bağlantılıyken en iyi çalışır:
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.
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.
İyi bir inceleme şunları optimize eder:
Tekrar eden bir kontrol listesi onayları hızlandırır ve gereksiz tartışmaları azaltır:
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.
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?”İ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 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.
Stilde tartışmak yerine, yavaşlamayla korelasyon gösteren sinyalleri izleyin:
Haftada bir, ortak bir notta 10 dakika tekrarlayan sorunları kaydedin:
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.
Basit ve uygulanabilir tutun:
data, manager, process gibi belirsiz kelimeleri kapsam belirtilmedikçe yasaklayın.Her haftanın sonunda metrikleri gözden geçirin ve hangi uygulamaları sürdürmeye karar verdiğinize karar verin.
Temiz Kod, gelecekteki değişiklikleri daha güvenli ve daha hızlı hale getirdiği için önemlidir. Kod net olduğunda ekip arkadaşları niyeti çözmek için daha az zaman harcar, incelemeler hızlanır, hataların teşhisi kolaylaşır ve değişiklikler “dalga etkisi” yaratma olasılığı düşer.
Pratikte Temiz Kod, sürdürülebilirliği korumanın bir yoludur ve bu doğrudan haftalar ve aylar içinde istikrarlı takım hızını destekler.
Sürdürülebilirlik, ekibinizin kodu anlayabilme, değiştirebilme ve hataya neden olmadan yayınlayabilme kolaylığıdır.
Kısa bir kontrol: küçük düzenlemeler riskli hissediliyorsa, çok manuel kontrol gerektiriyorsa veya bir bölgeye yalnızca bir kişi “dokunabiliyorsa”, sürdürülebilirlik düşüktür.
Takım hızı, ekibin zaman içinde faydalı iyileştirmeler sunma konusundaki güvenilir yeteneğidir.
Bunlar yazma hızından farklıdır—amaç fikir → çalışma yazılımı arasında sürekli olarak tekrar edilebilen hızlı bir akıştır. Net kod, stabil testler ve iyi sınırlar tereddüt ve yeniden çalışmayı azaltır.
Hızlıca daha iyi isimler seçmek için isimlere, okuyucunun aksi takdirde tahmin etmek zorunda kalacağı bilgileri taşıma sorumluluğu verin:
İsim sürüklenmesi, davranış değiştiği halde ismin değişmemesi durumudur (ör. validateUser() artık provisioning ve loglama da yapıyorsa).
Pratik çözümler:
Sınırlar, sorumlulukları ayıran çizgilerdir (modüller/katmanlar/servisler). Değişikliğin yerel kalmasını sağlarlar.
Yaygın sınır kokuları:
İyi bir sınır, bir değişikliğin nereye ait olduğunu açıkça gösterir ve dosyalar arası yan etkileri azaltır.
Okuyucunun belleğinde tutması gereken bağlamı azalttığı için küçük, odaklı fonksiyonları tercih edin.
Pratik desen:
calculateTax(), applyDiscounts())Eğer bölme niyeti netleştiriyor ve testleri basitleştiriyorsa genelde değerdir.
Yan etki, bir fonksiyonun dönüş değerinin dışında yaptığı her değişikliktir (argümanları değiştirmek, DB yazmak, global durumla oynamak vb.).
Sürpriz yan etkileri azaltmak için:
saveUser() vs getUser())Testler sadece “hataları yakalamak” için değildir; sınırları korurlar: kodunuzun diğerlerine vaat ettiği davranışı.
Zaman kısıtlıysa öncelik verin:
Testleri uygulama örnekleri gibi düşünün: rejects_expired_token() gibi niyeti ifade eden isimler kullanın ve iç adımlardan ziyade sonuçları doğrulayın.
İncelemeleri, ilkeler takım alışkanlığına dönüşsün diye kullanın, kişisel tercih değil.
Hafif bir kontrol listesi:
timeoutMs, totalCents, expiresAtUtcvalidatedEmailAddress, discountPercentEğer bir isim birinin anlamak için üç dosya açmasını gerektiriyorsa, muhtemelen çok belirsizdir.
İncelemede sorulacak soru: “Dönüş değerinin dışında başka ne değişiyor?”
Yazılı standartlar tartışmayı azaltır ve onayları hızlandırır.