Büyük kod tabanlarında sözdizimi tercihlerinden çok net soyutlamalar, isimlendirme ve sınırların riskleri azalttığını ve değişiklik hızını artırdığını öğrenin.

İnsanlar programlama dilleri hakkında tartışırken sık sık sözdizimi üzerine tartışırlar: bir fikri ifade etmek için yazdığınız sözcükler ve semboller. Sözdizimi, süslü parantezler mi girinti mi, değişkenleri nasıl bildirdiğiniz veya map() mi yoksa bir for döngüsü mü yazdığınız gibi şeyleri kapsar. Okunabilirliği ve geliştirici rahatlığını etkiler—ama çoğunlukla “cümle yapısı” seviyesinde.
Soyutlama farklıdır. Kodunuzun anlattığı “hikayedir”: seçtiğiniz kavramlar, sorumlulukları nasıl gruplayacağınız ve değişikliklerin her yere yayılmasını engelleyen sınırlar. Soyutlamalar modüller, fonksiyonlar, sınıflar, arayüzler, servisler ve hatta “tüm paralar kuruş cinsinden saklanır” gibi basit usullerde ortaya çıkar.
Küçük bir projede sistemi çoğunlukla kafanızda tutabilirsiniz. Büyük, uzun ömürlü bir kod tabanında bunu yapamazsınız. Yeni ekip arkadaşları katılır, gereksinimler değişir ve özellikler beklenmedik yerlere eklenir. O noktada başarı, dilin “yazması hoş” olup olmadığına değil, kodun net kavramlara ve kararlı dikişlere sahip olup olmadığına bağlıdır.
Diller hâlâ önemlidir: bazıları belirli soyutlamaları ifade etmeyi kolaylaştırır veya yanlış kullanmayı zorlaştırır. Nokta şu değil: “sözdizimi önemsiz.” Asıl olan, sözdizimi genellikle darboğaz değildir bir sistem büyüdüğünde.
Güçlü ve zayıf soyutlamaları nasıl tespit edeceğinizi, neden sınırlar ve isimlendirmenin ağır iş yaptığını, yaygın tuzakları (sızan soyutlamalar gibi) ve korkmadan değişiklik yapmayı sağlayan pratik refaktör yöntemlerini öğreneceksiniz.
Küçük bir proje "güzel sözdizimi" ile ayakta kalabilir çünkü hatanın maliyeti yereldir. Büyük, uzun ömürlü bir kod tabanında her karar çarpılır: daha fazla dosya, daha fazla katkıda bulunan, daha fazla sürüm treni, daha fazla müşteri isteği ve bozulabilecek daha fazla entegrasyon noktası.
Mühendislik zamanının çoğu yeni kod yazmakla geçmez. Şununla uğraşırsınız:
Günlük gerçekliğiniz buysa, dilin bir döngüyü zarifçe ifade edip etmediğinden çok, kod tabanında değişiklik yapabileceğiniz net dikişlerin olup olmadığı umrunuzda olur.
Büyük bir ekipte "yerel" seçimler nadiren yerel kalır. Bir modül farklı bir hata stilini, isimlendirme şemasını veya bağımlılık yönünü kullanıyorsa, bu daha sonra ona dokunan herkes için ekstra zihinsel yük oluşturur. Bunu yüzlerce modül ve yıllar boyunca turnover ile çarpın, kod tabanı gezinmesi pahalı hale gelir.
Soyutlamalar (iyi sınırlar, kararlı arayüzler, tutarlı isimlendirme) koordinasyon araçlarıdır. Farklı insanların paralel çalışmasına daha az sürprizle izin verirler.
"Deneme süresi sonu bildirimleri" eklemeyi hayal edin. Basit gibi görünüyor—ta ki yolu izleyene kadar:
Bu alanlar net arayüzlerle (ör. "trial status"ı tablolarını açığa çıkarmadan veren bir faturalama API'si) bağlıysa, değişikliği sınırlı düzenlemelerle uygulayabilirsiniz. Her şey her şeye erişiyorsa, özellik riskli, çapraz-kesitli bir cerrahiye dönüşür.
Ölçeklendiğinde öncelikler zeki ifadelerden ziyade güvenli, öngörülebilir değişikliğe kayar.
İyi soyutlamalar "karmaşıklığı gizlemek"ten çok niyeti ortaya koymak hakkındadır. İyi tasarlanmış bir modülü okuduğunuzda, sistem ne yapıyoru öğrenmelisiniz; nasıl yaptığını öğrenmek zorunda kalmadan.
İyi bir soyutlama bir dizi adımı tek, anlamlı bir fikre dönüştürür: Invoice.send() "PDF formatla → e-posta şablonu seç → dosya ekle → hatada tekrar dene" demekten daha kolaydır. Detaylar hâlâ vardır, ama bir sınırın arkasında yaşarlar; orada değişebilirler ve geri kalan kodu sürüklemezler.
Büyük kod tabanları her değişiklik için on dosya "sadece emin olmak için" okumak gerektiğinde zorlaşır. Soyutlamalar gerekli okumayı küçültür. Çağıran kod net bir arayüze bağımlıysa—"bu müşteriyi tahsil et", "kullanıcı profili getir", "vergi hesapla"—uygulamayı değiştirirken alakasız davranışları kazara değiştirmeyeceğinizden emin olabilirsiniz.
Gereksinimler sadece özellik eklemez; varsayımları değiştirir. İyi soyutlamalar bu varsayımları güncelleyeceğiniz az sayıda yer yaratır.
Örneğin, ödeme yeniden denemeleri, sahtekârlık kontrolleri veya döviz dönüşüm kuralları değiştiğinde, tüm uygulama yerine tek bir ödeme sınırını güncellemek istersiniz.
Herkes aynı “tutamacı”ları paylaştığında ekip daha hızlı hareket eder. Tutarlı soyutlamalar zihinsel kısayollara dönüşür:
Repository kullanın"HttpClient üzerinden gider"Flags arkasındadır"Bu kısayollar kod incelemelerinde tartışmayı azaltır ve işe almayı kolaylaştırır; çünkü desenler tahmin edilebilir şekilde tekrar eder, her klasörde yeniden keşfedilmez.
Bir dili değiştirmek, yeni bir çerçeve benimsemek veya daha katı bir stil rehberi uygulamanın bir dağınık sistemi “düzelteceğini” düşünmek caziptir. Ama sözdizimini değiştirmek genellikle altta yatan tasarım problemlerini değiştirmez. Bağımlılıklar dolaşık, sorumluluklar belirsiz ve modüller bağımsız değiştirilemiyorsa, daha güzel sözdizimi sadece daha temiz görünen düğümler verir.
İki ekip aynı özellik setini farklı dillerde inşa edebilir ve aynı acıya sahip olabilir: iş kuralları controller'lara dağılmış, veritabanına doğrudan her yerden erişim ve yavaş yavaş çöp haline gelen "yardımcı" modüller.
Bunun sebebi, yapının çoğunlukla sözdiziminden bağımsız olmasıdır. Aynı uzun fonksiyonu herhangi bir dilde yazabilirsiniz; aynı dairesel bağımlılığı farklı import ifadeleriyle oluşturabilirsiniz; aynı "God object"u farklı sınıf sözdizimiyle yazabilirsiniz.
Bir kod tabanı değiştirilemez olduğunda, asıl neden genellikle sınırlar: belirsiz arayüzler, karışık sorumluluklar ve gizli bağlamlardır. Sözdizimi tartışmaları tuzağa dönüşebilir—takımlar saatlerce süslü parantezler, dekoratörler veya isimlendirme stili hakkında tartışırken asıl iş (sorumlulukları ayırmak ve kararlı arayüzler tanımlamak) ertelenir.
Sözdizimi önemsiz değildir; sadece daha dar, taktiksel şekillerde önem taşır.
Okunabilirlik. Tutarlı ve net sözdizimi insanların kodu hızlıca taramasına yardımcı olur. Bu, birçok kişinin dokunduğu çekirdek domain mantığı, paylaşılan kütüphaneler ve entegrasyon noktalarında özellikle değerlidir.
Sıcak noktalar için doğruluk. Bazı sözdizimi tercihleri hataları azaltır: belirsiz önceliklerden kaçınmak, yanlış kullanımı önleyecek yerlerde açık tipleri tercih etmek veya geçersiz durumları temsil etmeyi zorlaştıran dil yapılarını kullanmak.
Yerel ifade gücü. Performans açısından kritik veya güvenlik açısından hassas alanlarda detaylar önemlidir: hataların nasıl ele alındığı, eşzamanlılığın nasıl ifade edildiği veya kaynakların nasıl edinilip bırakıldığı.
Özet: sözdizimi kurallarını sürtünmeyi azaltmak ve yaygın hataları önlemek için kullanın, ama tasarım borcunu iyileştireceklerini beklemeyin. Kod tabanı size karşıysa önce daha iyi soyutlamalar ve sınırlar şekillendirmeye odaklanın—sonra stilin bu yapıya hizmet etmesine izin verin.
Büyük kod tabanları genellikle bir ekip “yanlış” sözdizimi seçtiği için başarısız olmaz. Başarısız olurlar çünkü her şey her şeye dokunabilir. Sınırlar bulanıksa küçük değişiklikler sistem çapında dalgalanır, incelemeler gürültülü olur ve "hızlı düzeltmeler" kalıcı bağlanmalara dönüşür.
Sağlıklı sistemler açık sorumluluklara sahip modüllerden oluşur. Sağlıksız sistemler ise çok fazla bilen ve çok fazla yapan "god object"leri/toplulukları biriktirir: doğrulama, kalıcılık, iş kuralları, önbellekleme, biçimlendirme ve orkestrasyon hepsi bir yerde toplanır.
İyi bir sınır şunu cevaplamanıza izin verir: Bu modül neye sahip? Açıkça neye sahip değil? Bunu cümleyle söyleyemiyorsanız muhtemelen çok geniştir.
Sınırlar, girdiler, çıktılar ve davranış garantileriyle desteklendiğinde gerçeğe dönüşür: bunları sözleşme olarak ele alın. İki sistem parçası konuştuğunda, küçük bir yüzey alanı üzerinden konuşmalı; bu yüzey test edilebilir ve versiyonlanabilir olmalıdır.
Ayrıca ekiplerin ölçeklenme biçimidir: farklı kişiler farklı modüller üzerinde her satırı koordine etmeden çalışabilir; çünkü sözleşme önemlidir.
Katmanlama (UI → domain → data) ayrıntılar yukarı sızmadığında işe yarar.
Ayrıntılar sızdığında, "sadece veritabanı varlığını yukarı geçir" kısayolları oluşur ve bugünkü depolama seçimlerine kilitlenirsiniz.
Basit bir kural sınırları korur: bağımlılıklar domain'e doğru içe işaret etmelidir. Her şeyin her şeye bağımlı olduğu tasarımlardan kaçının; değişiklikler riskli hale gelir.
Nereden başlayacağınızı bilmiyorsanız, bir özellik için bağımlılık grafiği çizin. En sancılı kenar genellikle düzeltmeye değer ilk sınırdır.
İsimler insanların etkileşime geçtiği ilk soyutlamadır. Bir okuyucu bir tip hiyerarşisini, modül sınırını veya veri akışını anlamadan önce tanımlayıcıları çözümleyip zihinsel bir model oluşturur. İsimlendirme netse, o model çabucak oluşur; isimlendirme belirsiz veya "esprili" ise her satır bir bilmece olur.
İyi bir isim şu soruyu cevaplar: bu ne için? değil nasıl uygulanmış? ile ilgili değil. Karşılaştırın:
process() vs applyDiscountRules()data vs activeSubscriptionshandler vs invoiceEmailSender"Zeki" isimler kötü yaşlanır çünkü bağlama dayanır: içerideki espriler, kısaltmalar veya kelime oyunları. Niyet gösteren isimler ekipler, saat dilimleri ve yeni işe alımlar arasında iyi taşınır.
Büyük kod tabanları paylaşılan dile bağlıdır. İş bir şey için "policy" diyorsa kodda bunu contract olarak adlandırmayın—domain uzmanları için bunlar farklı kavramlardır, tablo benzer olsa bile.
Sözcük dağarcığını domain ile hizalamak iki fayda sağlar:
Domain diliniz dağınıksa, bu ürün/operasyon ile işbirliği yapıp bir sözlük üzerinde anlaşmaya dair bir sinyaldir. Kod bunu pekiştirebilir.
İsimlendirme konvansiyonları stilden çok öngörülebilirlik içindir. Okuyucular şekilden amacını çıkarabildiğinde daha hızlı ilerler ve daha az kırarlar.
Yatırım getiren konvansiyon örnekleri:
Repository, Validator, Mapper, Service gibi son ekleri yalnızca gerçek bir sorumluluğa uyduğunda kullanın.is, has, can) ve geçmiş zamanda olay isimleri (PaymentCaptured).users koleksiyon, user tek öğe.Amaç sıkı denetim değil; anlama maliyetini düşürmek. Uzun ömürlü sistemlerde bu bileşen bile birleşen bir avantajdır.
Büyük bir kod tabanı yazılmasından çok daha sık okunur. Her ekip (veya geliştirici) aynı türden problemi farklı bir tarzda çözdüğünde, her yeni dosya küçük bir bilmeceye dönüşür. Bu tutarsızlık okuyucuları her alanın "yerel kurallarını" yeniden öğrenmek zorunda bırakır—burada hatalar nasıl ele alınır, orada veri nasıl doğrulanır, başka bir yerde servis nasıl yapılandırılır gibi.
Tutarlılık sıkıcı kod anlamına gelmez. Öngörülebilir kod demektir. Öngörülebilirlik bilişsel yükü azaltır, inceleme döngülerini kısaltır ve insanlar niyeti yeniden türetmek yerine tanıdık desenlere güvenebildiği için değişiklikleri daha güvenli kılar.
Zeki çözümler genellikle yazara kısa vadeli memnuniyet sağlar: şık bir numara, sıkıştırılmış bir soyutlama, özel mini-çatı. Ama uzun ömürlü sistemlerde maliyet daha sonra ortaya çıkar:
Sonuç: kod tabanı olduğundan daha büyük hissedilir.
Bir ekip API uç noktaları, veritabanı erişimi, arka plan işleri, yeniden denemeler, doğrulama, günlükleme gibi tekrarlayan problem türleri için paylaşılan desenler kullandığında—her yeni örnek daha hızlı anlaşılır. İnceleyenler yapı yerine iş mantığına odaklanabilir.
Küçük ve amaçlı bir set tutun: problem türü başına birkaç onaylı desen; sınırsız seçenek değil. Eğer sayfalandırma için beş yol varsa, pratikte standartınız yoktur.
Standartlar somut olduğunda en iyi çalışır. Kısa bir dahili sayfa şunu göstermeli:
...uzun bir stil rehberinden daha fazlasını yapar. Bu ayrıca kod incelemelerinde tarafsız bir referans noktası oluşturur: tercihleri tartışmıyor, ekip kararını uyguluyorsunuz.
Başlamak için bir yüksek-dönüşümlü alan seçin (en sık değişen kısım), bir desen üzerinde anlaşın ve zaman içinde buna göre refaktör edin. Tutarlılık emrivakiyle değil; istikrarlı, tekrarlanan hizalanmayla elde edilir.
İyi bir soyutlama sadece kodu okumayı kolaylaştırmaz—kodun değiştirilmesini de kolaylaştırır. Doğru sınırı bulduğunuzun en iyi işareti, yeni bir özellik veya hata düzeltmesinin yalnızca küçük bir alanı etkilemesi ve sistemin geri kalanının kesinlikle dokunulmamış kalmasıdır.
Bir soyutlama gerçek olduğunda onu bir sözleşme olarak tanımlayabilirsiniz: bu girdiler verildiğinde bu çıktılar alınır, birkaç açık kural ile. Testleriniz çoğunlukla o sözleşme düzeyinde olmalıdır.
Örneğin bir PaymentGateway arayüzünüz varsa testler, bir ödemenin başarılı olduğunda, başarısız olduğunda veya zaman aşımına uğradığında ne olacağını doğrulamalıdır—hangi yardımcı metodların çağrıldığı veya hangi iç tekrar döngüsünün kullanıldığı değil. Böylece performansı geliştirebilir, sağlayıcı değiştirebilir veya içyapıyı refaktör edebilirsiniz; testlerin yarısını yeniden yazmak zorunda kalmazsınız.
Sözleşmeyi kolayca listeleyemiyorsanız, soyutlama bulanıktır. Bunu daraltmak için şunları cevaplayın:
Bunlar netleşince, test vakaları neredeyse kendiliğinden yazılır: her kural için bir ya da iki, artı birkaç köşe durum.
Testler uygulama tercihlerini değil davranışı kilitlediğinde kırılgan hale gelir. Yaygın kokular şunlardır:
Eğer bir refaktör kullanıcı tarafından görünen davranışı değiştirmeden sizi birçok testi yeniden yazmaya zorluyorsa, genellikle test stratejisi problemidir—refaktör problemi değil. Gözlemlenebilir sonuçlara odaklanın; gerçek ödül budur: hızla ve güvenle değişmek.
İyi soyutlamalar düşünmeniz gerekenleri azaltır. Kötü soyutlamalar ise tam tersini yapar: temiz görünürler ama gerçek gereksinimler geldiğinde iç bilgi veya fazladan tören isterler.
Sızan bir soyutlama, onu doğru kullanmak için çağıranların iç detayları bilmesini gerektirir. İpucu genellikle şu tür yorumlardır: "X'i Y'den önce çağırmalısınız" veya "bu ancak bağlantı zaten ısıtıldıysa çalışır." Bu noktada soyutlama karmaşıklıktan korumuyor—karmaşıklığı yeniden yerleştiriyor.
Tipik sızıntı desenleri:
Eğer çağıranlar rutin olarak aynı koruma kodunu, yeniden denemeleri veya sıralama kurallarını ekliyorsa, o mantık soyutlamanın içine ait olmalıdır.
Çok fazla katman, basit davranışı izlemeyi ve hata ayıklamayı zorlaştırabilir. Bir sarmalayıcı, başka bir sarmalayıcı, sonra bir yardımcı—tek satırlık bir karar hazine avına dönüşebilir. Bu genellikle soyutlamaların "ne olur diye" önceden oluşturulduğu durumlarda olur.
Eğer sık çalışma etrafları, tekrar eden özel durumlar veya kaçış deliklerinin (bayraklar, atlama yöntemleri, "gelişmiş" parametreler) büyüdüğünü görüyorsanız, soyutlamanın şekli sistemin gerçek kullanım şekline uymuyor demektir.
Yaygın yolu iyi kapsayan küçük, görüşlü bir arayüz tercih edin. Yeni yetenekleri yalnızca çok sayıda gerçek çağıran ihtiyaç gösterdiğinde ve yeni davranışı iç detaylara referans etmeden açıklayabildiğinizde ekleyin.
Kaçış deliği gerekiyorsa, onu açık ve nadir yapın; varsayılan yol haline getirmeyin.
Daha iyi soyutlamalara refaktör etmek "temizlemek"ten çok işin şeklini değiştirmekle ilgilidir. Hedef, gelecekteki değişiklikleri ucuzlaştırmaktır: düzenlenecek daha az dosya, anlaşılması gereken daha az bağımlılık, küçük bir dokunuşun alakasız bir şeyi kırabileceği daha az yer.
Büyük yeniden yazımlar netlik vaat eder ama sistemde kazanılmış bilgiyi sıfırlama eğilimindedir: köşe vakaları, performans nüansları ve operasyonel davranış. Küçük, sürekli refaktörler size aynı anda teslim etmeye devam ederken teknik borcu azaltma imkânı verir.
Pratik bir yaklaşım, her dokunduğunuz alana refaktörü iliştirmektir: her seferinde alanı biraz daha kolay dokunulur hale getirin. Aylar içinde bu bileşikleşir.
Mantığı taşımadan önce bir dikiş oluşturun: arayüz, sarmalayıcı, adaptör veya fasad—değişiklikleri caller'ları değiştirmeden yeniden yönlendirmenizi sağlar. Dikişler, her şeyi bir anda yeniden yazmadan davranışı yönlendirmenize izin verir.
Örneğin doğrudan veritabanı çağrılarını bir repository-benzeri arayüzün arkasına sarın. Sonra sorguları, önbellekleme veya depolama teknolojisini değiştirebilirsiniz; kalan kod aynı sınır ile konuşmaya devam eder.
Bu, AI destekli araçlarla hızla inşa ederken de faydalı bir zihinsel modeldir: en hızlı yol yine önce sınırı kurmak, sonra arkasını yinelemektir.
İyi bir soyutlama, tipik bir değişiklik için kod tabanında kaç yeri değiştirmeniz gerektiğini azaltır. Bunu gayri resmi olarak izleyin:
Eğer değişiklikler sürekli olarak daha az dokunma noktası gerektiriyorsa, soyutlamalarınız iyileşiyor demektir.
Önemli bir soyutlamayı değiştirirken, dilimleri halinde taşıyın. Eski + yeni paralel yolları bir dikişin arkasında kullanın; sonra trafiği veya kullanım durumlarını yavaşça yeni yola yönlendirin. Kademeli göçler riski azaltır, kesintiyi önler ve sürprizler çıktığında geri almayı gerçekçi kılar.
Pratikte ekipler geri alma maliyetini düşük tutan araçlardan fayda görür. Koder.ai gibi platformlar iş akışına anlık görüntüler ve geri alma özelliklerini dahil eder, böylece özellikle sınır refaktörleri üzerinde iterasyon yaparken mimari değişikliklerde tüm sürümü tek bir geri dönüşü olmayan hamleye bağlamadan çalışabilirsiniz.
Uzun ömürlü bir kod tabanında kodu incelerken hedef "en güzel" sözdizimini bulmak değildir. Hedef gelecekteki maliyeti azaltmaktır: daha az sürpriz, daha kolay değişiklikler, daha güvenli sürümler. Pratik bir inceleme, sınırlar, isimler, bağlanırlık ve testlere odaklanır—sonra biçimlendirmeyi araçlara bırakır.
Bu değişiklik neye bağımlı ve şimdi neye bağımlı olacak sorun.
Bir arada olması gereken kod ile dolaşık olan kodu arayın.
İsimlendirmeyi soyutlamanın bir parçası olarak ele alın.
Basit bir soru birçok kararı yönlendirir: bu değişiklik gelecekteki esnekliği artırıyor mu yoksa azaltıyor mu?
Mekanik stili otomatikleştirin (formatlayıcılar, linters). Tartışma süresini tasarım soruları—sınırlar, isimlendirme ve bağlanırlık—için ayırın.
Büyük, uzun ömürlü kod tabanları genellikle bir dil özelliği eksik olduğu için başarısız olmaz. Başarısız olurlar çünkü insanlar değişikliğin nerede yapılacağını, neyi kırabileceğini ve nasıl güvenle yapılacağını söyleyemezler. Bu bir soyutlama problemidir.
Dil tartışmaları yerine açık sınırlar ve niyete öncelik verin. Küçük bir genel yüzeye ve net bir sözleşmeye sahip iyi çizilmiş bir modül sınırı, dağınık bir bağımlılık grafiği içindeki "temiz" sözdiziminden daha değerlidir.
Bir tartışmanın "sekme vs boşluk" veya "dil X vs dil Y" haline geldiğini hissettiğinizde, bunu şu sorulara yönlendirin:
Domain kavramları ve mimari terimler için bir paylaşılan sözlük oluşturun. İki kişi aynı fikirde değilse—aynı kelimeyi farklı şeyler için kullanıyorlarsa veya aynı şey için farklı kelimeler kullanıyorlarsa—soyutlamalarınız zaten sızıyor demektir.
Herkesin tanıdığı küçük bir desen seti tutun (ör. “service + interface,” “repository,” “adapter,” “command”). Az sayıda, tutarlı kullanılan desenler, düzinelerce zekice tasarımdan daha hızlı gezinilir yapar.
Testleri sadece modüllerin içinde değil, modül sınırlarında de koyun. Sınır testleri içyapıyı agresifçe refaktör etmenize izin verirken dışarıya olan davranışı sabit tutar—soyutlamaların zaman içinde "dürüst" kalmasının yolu budur.
Hızla yeni sistemler inşa ediyorsanız—özellikle vibe-coding iş akışlarıyla—sınırları ilk kilitlediğiniz artefakt olarak ele alın. Örneğin Koder.ai'de planlama modunda React UI → Go services → PostgreSQL data gibi sözleşmeleri çizebilir, sonra bu sözleşmelerin arkasında uygulamayı üretebilir ve ihtiyaç duyduğunuzda kaynak kodunu dışa aktarabilirsiniz.
Bir yüksek-dönüşümlü alan seçin ve:
Bu adımları norm haline getirin—dokunurken refaktör edin, genel yüzeyleri küçük tutun ve isimlendirmeyi arayüzün bir parçası olarak değerlendirin.
Sözdizim, yüzey formudur: anahtar kelimeler, noktalama ve düzen (parantez mi girinti mi, map() mi döngü mü). Soyutlama ise kavramsal yapıdır: modüller, sınırlar, sözleşmeler ve isimlendirme—okuyanlara sistemin ne yaptığını ve değişikliklerin nerede yapılması gerektiğini söyler.
Büyük kod tabanlarında soyutlama genellikle daha baskındır çünkü çoğu iş güvenli şekilde kodu okumak ve değiştirmektir, sıfırdan yeni kod yazmak değil.
Çünkü ölçek maliyet modelini değiştirir: kararlar birçok dosya, ekip ve yıl boyunca çarpılır. Küçük bir sözdizimi tercihi yerel kalır; zayıf bir sınır ise her yere dalga etkileri yaratır.
Pratikte ekipler yeni satırlar yazmaktan çok davranışı bulmaya, anlamaya ve güvenle değiştirmeye zaman harcarlar; bu yüzden temiz dikişler ve sözleşmeler "yazması hoş" yapılarından daha önemlidir.
Bir davranışı, alakasız parçaları anlamaya gerek duymadan değiştirebildiğiniz yerleri arayın. Güçlü soyutlamalar genellikle şunlara sahiptir:
Bir dikiş, uygulamayı çağıranları değiştirmeden uygulamayı değiştirmenizi sağlayan kararlı bir sınırdır—genellikle bir arayüz, adaptör, fasad veya sarmalayıcıdır.
Güvenli bir şekilde yeniden düzenlemek veya taşımak gerektiğinde dikiş ekleyin: önce kararlı bir API oluşturun (eski koda delege eden bile olsa), sonra mantığı kademeli olarak arkasına taşıyın.
Sızan soyutlama, çağıranların doğru kullanmak için gizli kuralları bilmesini zorunlu kılar (sıralama kısıtları, yaşam döngüsü nüansları, sihirli varsayılanlar).
Yaygın düzeltmeler:
Aşırı mühendislik, tören ekleyen katmanlar şeklinde ortaya çıkar—basit davranışı izlemeyi zorlaştırır. Bir sarmalayıcı, başka bir sarmalayıcıyla çevrildiğinde bir satırlık karar define-arama avına dönüşebilir.
Pratik kural: Yeni bir katman yalnızca birden çok gerçek çağıranın aynı ihtiyacı olduğu ve sözleşmeyi iç detayları referans etmeden tanımlayabildiğiniz zaman eklenmelidir. Her şeyi yapmaya çalışan geniş arayüz yerine küçük, görüşlü bir arayüz tercih edin.
İsimlendirme, insanların ilk etkileşime geçtiği arayüzdür. Niyet gösteren isimler, bir kişinin davranışı anlamak için incelemesi gereken kod miktarını azaltır.
İyi uygulamalar:
applyDiscountRules yerine process değil)Sınırlar, girdiler/çıktılar, garanti edilen davranışlar ve tanımlı hata yönetimi ile birlikte geldiğinde gerçektir. Bu, ekiplerin bağımsız çalışmasını sağlar.
Eğer UI veritabanı tablalarını biliyorsa ya da domain kodu HTTP kavramlarına bağımlıysa, ayrıntılar katmanlar arasında sızıyor demektir. Bağımlılıklar domain kavramlarına doğru içe işaret etmeli ve kenarlarda adaptörler olmalıdır.
Sınır seviyesinde davranışı test edin: girdiler verildiğinde çıktıları, hataları ve yan etkileri doğrulayın. İç adımları kilitleyen testlerden kaçının.
Kırılgan test kokuları şunlardır:
Sınır odaklı testler, içyapıyı yeniden düzenlerken testleri yeniden yazma ihtiyacını azaltır.
Gelecekteki maliyeti azaltmaya odaklanın; estetiğe değil. Faydalı sorular:
Biçimlendirmeyi linters/formatters ile otomatikleştirerek inceleme süresini tasarım ve bağımlılıklara ayırın.
Repository, is/has/can önekli booleanlar, geçmiş zamanlı olay isimleri)