Uzun ömürlü sis­tem­ler için API tasarımı

Bir API'nin arkasındaki kod her an yeniden yapılandırılabilir, değiştirilebilir, çöpe atılabilir — o kod sizindir. API'nin kendisi ise yalnızca yarı yarıya sizindir. Diğer yarısı, onun biçimine güvenen her harici sisteme aittir ve bu yarıya, başkalarının production ortamına müdahale etmeden dokunamazsınız. API tasarımını yazılım mühendisliğinin en affetmez kararlarından biri yapan da tam olarak budur: İçerideki neredeyse her şey geri alınabilir, dışarıdan görünen biçim ise neredeyse hiç.

Bu doküman arayüz tasarımını tam da bu açıdan ele alıyor — bir API'nin nasıl inşa edileceğini değil, kullanıcılarını bozmadan on yıl boyunca geliştirilebilecek şekilde nasıl tasarlanacağını. Bilinçli olarak framework'ten, protokolden ve üreticiden bağımsızdır: Arayüzün REST tarzında, RPC olarak ya da sorgu tabanlı bir protokolle kurulmuş olması ilkeleri değiştirmez. Sürümlemenin somut mekaniği için ayrı ve daha derin bir metin var; burada konu, ondan önce gelen tasarım kararlarıdır.

1. API'ler sözleşmedir

Bir API'nin sözleşmesi, çağıranın güvenebileceği her şeydir: yanıtın yapısı, alanların anlamı, hataların semantiği, sınır durumlardaki davranış. Bunların çoğu dokümantasyonun hiçbir yerinde yazmaz — belirli bir yanıt biçimini gözlemleyip ona göre inşa eden kullanıcıların kodunda yazar. Bu yüzden gerçek sözleşme, taahhüt edilenden daha büyüktür: Yalnızca belgelenmiş olanı değil, gözlemlenebilen her şeyi kapsar.

Şema: Taahhüt ettiğiniz şey yalnızca uçtur. Kullanıcıların güvendiği şey çok daha derine iner — gözlemlenebilen her özellik birileri için sözleşmenin parçası hâline gelir.

Dokümanın tamamına yön veren temel tutum buradan çıkar: Bir API'yi değiştirmek, kendi kodunuzu değiştirmek değil, hiç tanımadığınız insanların sistemlerine müdahale etmek demektir. Bu nedenle her tasarım kararı, bugün sağlayıcıya ne kazandırdığıyla değil, çağıranlardan yıllar boyunca ne talep ettiğiyle sınanmalıdır.

Bunun için yalın bir pratik kural var: Bir arayüzün yeterince kullanıcısı olduğunda, gözlemlenebilen her özellik — taahhüt edilmiş olsun ya da olmasın — birileri tarafından ön koşul hâline getirilir. Bu yüzden taahhüt etmek istemediğiniz şeyi hiç gözlemlenebilir kılmamalısınız. Dışarı sızan her ayrıntı — dahili bir alan, rastlantısal bir sıralama, teknik iç yapıyı ele veren bir hata mesajı — sözleşmenin sessiz bir parçasıdır ve daha sonra ancak kırılmaya yol açarak geri alınabilir. Sözleşme yüzeyinde tutumlu olmak bu yüzden cimrilik değil, ileriyi görmektir: Ne kadar az şey görünürse, o kadar çok şey değiştirilebilir kalır.

Avantajlar ve sınırlamalar. API sözleşmesini dar tutmak, bazı iç özelliklerin doğrudan dışarıya açılmasını sınırlar. Karşılığında iç yapıyı değiştirme özgürlüğü korunur.

Maliyet. Her yanıtı bir taahhüt olarak ele alma disiplini, tasarımda özen ve dahili ayrıntıları açığa vermekte ölçülülük gerektirir — kendini ancak ürünün ömrü boyunca gösteren bir emek.

Ne zaman farklı karar veririz. Her iki tarafını da aynı ekibin birlikte ve eşzamanlı olarak devreye aldığı tamamen dahili bir arayüzde sıkı sözleşme bağlılığı abartıdır; orada daha serbest değişiklik yapılabilir, çünkü şaşırtılacak yabancı bir kod yoktur.

2. Kolaylıktan önce istikrar

En yaygın tasarım hatası anlaşılır bir motivasyondan doğar: API'yi, o an sağlayıcıya en kolay gelen şekilde biçimlendirmek. Dahili veri yapılarını doğrudan dışarıya yansıtmak, her yeni yeteneği bir alan daha olarak eklemek, davranışı mevcut implementasyona göre ayarlamak. Bu kolaylıkların her biri bugün ucuzdur ve yarın bir prangaya dönüşür, çünkü bir kullanıcı onu gözlemlediği anda sözleşmenin parçası olur.

Bu yüzden yol gösterici ilke şudur: Bir API üretici için değil, tüketici için tasarlanır. Dahili uygulamayı değil, iş alanını (domain) ifade etmelidir — çünkü uygulama değişecektir, iş alanı ise daha istikrarlıdır. Dahili ayrıntıları dışarı sızdıran bir arayüz, harici sistemleri aslında serbestçe değiştirebilmek istediğiniz kararlara bağlar. Dışarıya karşı istikrarın bedeli, içeride çeviri yapmaya razı olmaktır.

Avantajlar ve sınırlamalar. API sözleşmesini iç uygulamadan ayırmak bir dönüşüm katmanı gerektirir. Karşılığında iç yapı, istemcilerin kullandığı sözleşme değiştirilmeden geliştirilebilir.

Maliyet. Bu çeviri kalıcı bir iştir: Her dahili değişikliğin sınırda yansıyıp yansımadığı ve nasıl yansıdığı kontrol edilmelidir.

Ne zaman farklı karar veririz. Bir prototip ya da kısa ömürlü bir arayüz için dahili yapıları doğrudan yansıtmak daha hızlı ve doğru seçimdir; ayrıştırma ancak API uzun yaşadığında ve bağımsız harici istemciler taşıdığında karşılığını verir.

3. Değişim için tasarım

Uzun ömürlü bir API kesinlikle değişecektir — yalnızca nasıl değişeceğini bilemezsiniz. Bu belirsizlikle başa çıkmanın tek güvenilir yolu, arayüzü değişimi yasaklayan değil, değişimi kaldırabilen bir şekilde tasarlamaktır. Somut olarak bu, mevcut olanı bozmadan ekleme yoluyla büyüyebilen biçimler seçmek demektir.

Pratikte bu, yanıtları ve girdileri genişletilebilir kurgulamak anlamına gelir. Enum'ları, bilinmeyen bir değer bir istemciyi çökertmeyecek şekilde ele almak. Nesneleri, sonradan yeni ve opsiyonel bir alan eklenebilecek ve bu, mevcut alanların anlamını kaydırmayacak şekilde biçimlendirmek. Gerekenden fazlasını taahhüt etmemek — gerekli olanın ötesinde sabitlenen her özellik, daha sonra değiştiremeyeceğiniz bir özelliktir. İkinci yarı ise her iki taraftaki toleranslı okuyucudur: taahhüt ettiğinizde katı, kabul ettiğinizde cömert olmak. Bilinmeyen alanları görmezden gelen bir istemci sunucunun büyümesine izin verir; bilinmeyen girdileri hemen reddetmeyen bir sunucu ise istemcilerin ileriye dönük geliştirme yapmasına olanak tanır.

Değişim için tasarımın bir parçası da operasyonların kesimidir. Dahili veri biçimine sıkıca yapışan bir arayüz, kullanıcıları tek bir iş eylemi için birçok küçük çağrıyı bir araya getirmeye zorlar — ve böylece onları bugünkü yapıya bağlar. Bir tabloyu değil, bir iş niyetini yansıtan operasyonlar dahili yeniden yapılandırmaları daha iyi atlatır, çünkü niyet aynı kaldığı sürece içerisi değişebilir. İş alanına göre kesim bu yüzden bir üslup meselesi değil, ömre dair bir karardır: Niyeti ifade eden kalır; yapıyı yansıtan onunla birlikte eskir.

Avantajlar ve sınırlamalar. Genişletilebilir API tasarımı, bazı alanların ve davranışların baştan kesin olarak sabitlenmemesini gerektirir. Bu esneklik, gelecekteki değişiklikleri kolaylaştırır.

Maliyet. Toleranslı okuyucular ve genişletilebilir biçimler doğrulama ve testlerde daha fazla özen gerektirir, çünkü bilinmeyen karşısındaki davranışı da bilinçli olarak belirlemeniz gerekir.

Ne zaman farklı karar veririz. Azami katılığın bir iş gereksinimi olduğu yerlerde — örneğin her sapmayı reddetmek zorunda olan sıkı regüle edilmiş arayüzlerde — bilinçli olarak dar, az esneyebilen biçim seçilir ve değişikliklerin daha pahalı hâle geleceği kabul edilir.

4. Geriye dönük uyumluluk

Yabancı kullanıcıları olan bir arayüzde geriye dönük uyumluluk bir nezaket değil, varsayılan ayardır. Belirleyici sınır, küçük ve büyük değişiklikler arasında değil, mevcut bir çağıranın fark ettiği ve fark etmediği değişiklikler arasından geçer.

İşin rahatsız edici kısmı: Bazı kullanıcılar hiç taahhüt edilmemiş davranışlara güvenir — alanların sırasına, rastlantısal bir zamanlamaya, tanımlanmamış bir sınıra. Bu yüzden en güvenli varsayım, aksi kanıtlanana kadar gözlemlenebilen her değişikliğin birileri için kırıcı olduğudur. Uyumluluk böylece bir kuraldan çok bir ihtiyat tutumudur.

Avantajlar ve sınırlamalar. Geriye dönük uyumluluk, eski alanların ve formatların daha uzun süre desteklenmesini gerektirir. Karşılığında mevcut istemcilerin çalışması korunur.

Maliyet. Uyumlu çözüm nadiren en zarif olanıdır; opsiyonel alanlar biriktirir ve pişman olduğunuz isimlerle yaşarsınız — kimseyi kırmamanın bedeli.

Ne zaman farklı karar veririz. Model temelden yanlış hâle geldiyse ve her uyumlu eğip bükme sözleşmeyi yalnızca daha da bulanıklaştırıyorsa, bilinçli ve düzgün sürümlenmiş uyumsuz bir değişiklik, bir dizi tavizden daha dürüsttür.

5. Sürümleme stratejisi

Yeni bir sürüm pahalıdır — iki sözleşme işleten sağlayıcı için de, geçiş yapmak zorunda kalan kullanıcılar için de. Bu yüzden ilk refleks değil, son çaredir: API baştan değişime göre tasarlandıysa çoğu şey uyumlu evrimle çözülebilir. Bir sürüm, artık uyumlu biçimde ilerleyemediğinizin itirafıdır — nadiren ve bilinçli olarak seçilmelidir. Bunun arkasındaki mekanik — paralel sürümler, deprecation, düzgün çıkış — İstemci sistemlerini bozmadan API sürümleme yazısında ayrıntılı olarak ele alınıyor; burada konu yalnızca sürümün nerede taşınacağına dair tasarım kararıdır.

Bu seçeneklerin hiçbiri üstün değildir; her biri görünürlüğü ince tanelilikle farklı biçimde takas eder. Seçim genel bir sıralamadan değil, kullanıcıların kim olduğundan ve nasıl geliştirdiklerinden çıkar.

Avantajlar ve sınırlamalar. URL, header ve media type ile sürümlemenin görünürlük, önbellekleme ve ayrıntılı kontrol açısından farklı avantajları ve sınırlamaları vardır.

Maliyet. Yeri ne olursa olsun, ek olarak işletilen her sürüm çifte bakım demektir: iki sözleşme, iki test zinciri, iki geçiş yolu.

Ne zaman farklı karar veririz. Doğrudan eşlik edebileceğiniz küçük ve kontrollü bir kullanıcı kitlesi için path'teki görünür sürüm çoğu zaman yeterlidir; ince evrim adımları olan büyük ve heterojen bir kullanıcı kitlesi için ise metadata'daki sürüm daha az sarsıcı bir seçim olabilir.

6. Hata yönetimi

Hatalar sözleşmenin bir parçasıdır, yanında duran bir kenar durum değil. Bir çağıran yalnızca başarılı yanıta değil, hata durumunda neyin döndüğüne — ve buna nasıl tepki vermesi gerektiğine — da güvenerek inşa eder. Hataları belirsiz, tutarsız ya da değişken olan bir API, başarılı durum kusursuz olsa bile kullanılması zor bir API'dir.

Pratik bir mihenk taşı: Bir istemci, bir hatanın metnini okumadan ona tepki verebilmelidir. Metin insanlar içindir ve değişebilir — örneğin başka bir dilde; kod ise makineler içindir ve istikrarlı kalmalıdır. İkisini karıştırıp kullanıcıları ifadeleri kontrol etmeye zorlayan, mesajın kendisini sözleşmeye dönüştürür ve onu bir daha yeniden ifade etme özgürlüğünü kaybeder.

Tasarımı üç ilke taşır. Birincisi: Hatalar ayırt edilebilir ve makine tarafından işlenebilir olmalıdır — değişken bir serbest metin değil, bir istemcinin güvenilir şekilde tepki verebileceği istikrarlı, sınıflandırılmış bir kod. İkincisi: Çağıranın hatası ile sağlayıcının hatası arasındaki ayrım net olmalıdır, çünkü çağıranın isteği yeniden denemesinin mi yoksa düzeltmesinin mi gerektiğini bu ayrım belirler. Üçüncüsü: Bir hata dahili ayrıntıları açığa vermemelidir — sözleşmeye dönüşecek ve sonradan geri alınamayacak bir iç yapı, teknik iz olmamalıdır. Hata semantiği zaman içinde başarı semantiği kadar istikrarlı kalmalıdır; bir hata kodunun anlamını değiştirmek, diğerleri gibi bir kırılmadır.

Avantajlar ve sınırlamalar. Kararlı bir hata modeli, önceden tasarım ve düzenli bakım gerektirir. Karşılığında istemciler hataları güvenilir biçimde sınıflandırıp uygun işlemi yapabilir.

Maliyet. İstikrarlı, sınıflandırılmış hatalar, bakımı yapılacak bir sözleşme yüzeyi daha ve değiştirirken başarılı yanıtlardaki ihtiyatın aynısını göstermek demektir.

Ne zaman farklı karar veririz. Tek bir, birlikte büyüyen kullanıcısı olan dahili bir arayüzde hata modeli daha yalın ve daha az biçimsel kalabilir; tam katılık ancak koordine etmediğiniz bağımsız harici istemciler olduğunda karşılığını verir.

7. Idempotency

Bir API ağ üzerinden erişilebilir olduğu anda, eninde sonunda aynı isteği iki kez alacaktır — bir yeniden deneme, belirsiz bir zaman aşımı, tekrar bir teslimat yüzünden. Bu bir hata değil, dağıtık iletişimin bir özelliğidir. Uzun ömürlü bir API tasarımı bunu yok saymak yerine kabul eder.

Tasarımın cevabı idempotency'dir: Operasyonları, birden çok kez çalıştırılmaları tek seferlik çalıştırmayla aynı etkiyi yaratacak şekilde biçimlendirmek. Okuma işlemleri doğası gereği böyledir; bir değeri set etmek ya da kimliğe göre silmek de öyle. Durum ve para değiştiren operasyonlar ise kendiliğinden böyle değildir — onlar için bir mekanizma gerekir; örneğin çağıranın gönderdiği, sağlayıcının bir tekrarı tanıyıp yeniden etki üretmemesini sağlayan bir idempotency anahtarı. Bu özelliği sözleşmede öngörmeyen, her kullanıcıyı bu eksikliği sonradan dolanmaya zorlar. Bu konunun derinliği — anahtarlar, eşzamanlılık, teslimat — Dağıtık sistemlerde idempotency yazısında ele alınıyor; tasarım açısından önemli olan, onu baştan planlamaktır.

Avantajlar ve sınırlamalar. Idempotent işleme için anahtar, kontrol ve saklama mekanizmaları gerekir. Karşılığında aynı istek, mükerrer etki yaratmadan güvenle tekrarlanabilir.

Maliyet. Tekrarların tanınması durum (state) ve eşzamanlılıkta özen gerektirir; bu, yazma yapan her operasyon için ortaya çıkan gerçek bir emektir.

Ne zaman farklı karar veririz. Salt okuma işlemleri ve doğası gereği idempotent operasyonlar için bir anahtar mekanizması kurulmaz; bu emek yalnızca kendiliğinden tekrarlanabilir olmayan operasyonlar için harcanır.

8. İstemci sistemlerini bozmadan geliştirme

Hedef, yıllarca büyüyen ve hiçbir kullanıcıyı hiçbir zaman şaşırtmayan bir API'dir. Bu, değişiklikler ağırlıklı olarak ekleme yoluyla gerçekleştiğinde ve nadir uyumsuz adımlar bir olay olarak değil, düzenli bir süreç olarak işlediğinde başarılır. Bir arayüz, eskiler kaybolmadan yenilerin eklendiği bir yer gibi hissettirmelidir.

Şema: Bir sözleşme, kontrol etmediğiniz çok sayıda kullanıcı. Kırıcı bir değişiklik hepsini aynı anda vurur — bu yüzden düzenli çıkış bir lüks değil, zorunluluktur.

Uyumsuz bir adım kaçınılmaz hâle gelirse, yol deprecation'dır: eski biçimi kullanımdan kalkmış olarak işaretlemek, yenisini paralel olarak sunmak, net bir kapatma tarihi belirlemek ve o tarih gelmeden önce duyurmak. Çıkış kimseyi şaşırtmamalıdır. İki sürümü bir süre paralel işletmek, geçişin kullanıcılarda zorla değil, kendi temposunda gerçekleşebilmesinin bedelidir.

Avantajlar ve sınırlamalar. Uyumlu geçişler, eski ve yeni sürümlerin bir süre birlikte çalışmasını ve düzenli iletişimi gerektirir. Bu ek iş yükü, istemcilerin güvenli geçişini destekler.

Maliyet. Paralel sürümler ve düzgün bir deprecation süreci kalıcı olarak kapasite bağlar — iletişim için, paralel işletim için, geçişe eşlik etmek için.

Ne zaman farklı karar veririz. Doğrudan ulaşabildiğiniz küçük ve bilinen bir kullanıcı kitlesinde, kısa ve yakından eşlik edilen bir geçiş uzun bir paralel işletimden daha ucuz olabilir; kullanıcı kitlesi ne kadar büyük ve anonimse, süreç o kadar uzun ve resmî olmalıdır.

9. Tipik hatalar

Uzun ömürlü API tasarımının başarısız olduğu tekrarlayan kalıplar — neredeyse hepsi aynı hatanın varyasyonlarıdır: API'yi kullanıcı için değil, sağlayıcı için tasarlamak:

• Dahili veri yapılarını doğrudan dışarıya yansıtmak ve böylece harici sistemleri kendi iç yapınıza bağlamak.
• Gerekenden fazlasını taahhüt etmek — alan sırası, zamanlama, tanımlanmamış sınırlar —; bunlar sonradan feshedilemez bir sözleşmeye dönüşür.
• Enum'ları ve nesneleri katı tasarlamak; öyle ki hiçbir yeni değer ve yeni alan ekleme yoluyla eklenemez.
• Hataları, kullanıcıların güvenilir şekilde tepki verebileceği istikrarlı, sınıflandırılmış kodlar yerine biçimsiz metin olarak kurgulamak.
• Hata mesajlarına dahili ayrıntılar sızdırmak ve böylece onları istemeden sözleşmenin parçası yapmak.
• Idempotency'yi sözleşmede öngörmek yerine, ilk çift kayıtlar ortaya çıktıktan sonra sonradan eklemek.
• Çok erken ve çok cömertçe sürümlemek ve böylece ince evrimin yerine pahalı tam sürümler koymak.
• Eski sürümü önceden duyurulan bir takvim olmadan kapatmak ve istemcilerin çalışmasını bozmak.
• Gözlemlenebilir davranışı, belgelenmediği için sözleşmenin parçası olmadığı varsayımıyla değiştirmek.

10. Karar kontrol listesi

Uzun ömürlü bir API tasarlamadan önce ve tasarlarken sırayla netleştirilecekler:

• Kimin için tasarlandı? Arayüz iş alanını tüketici için mi ifade ediyor — yoksa üreticinin dahili uygulamasını mı yansıtıyor?
• Sözleşme yüzeyi bilinçli mi? Neyin taahhüt edildiği net mi ve bunun ötesinde mümkün olduğunca az şey gözlemlenebilir biçimde sabitlenmiş mi?
• Ekleme yoluyla büyüyebilir mi? Yeni alanlar, değerler ve operasyonlar mevcut olanı bozmadan eklenebiliyor mu?
• Toleranslı okuyucu mu? Her iki taraf da tanımadığı şeyi bilinmeyen karşısında kırılmak yerine görmezden geliyor mu?
• Sözleşme olarak hatalar? Hatalar istikrarlı, sınıflandırılmış, makine tarafından işlenebilir ve dahili ayrıntılardan arındırılmış mı?
• İstemci ve sunucu hataları ayrılmış mı? Bir çağıran yeniden deneyebileceğini mi yoksa düzeltmesi gerektiğini mi anlayabiliyor mu?
• Idempotency öngörülmüş mü? Durum ve para değiştiren operasyonlar, bir tekrar zarar vermeyecek şekilde tasarlanmış mı?
• Son çare olarak sürümleme mi? Mümkün olduğunca çok şeyin uyumlu biçimde çözülmesine — ve gerekirse sürümün nerede taşınacağına — karar verildi mi?
• Düzenli çıkış? Herhangi bir şey kapatılmadan önce paralel işletim ve duyurulmuş tarih içeren bir deprecation süreci var mı?

Bu sorulara cevap veremeyen, uzun ömürlü bir arayüz değil, ileride bozulacak bir söz tasarlıyordur.

Sıkça Sorulan Sorular

API tasarımında en yaygın hata nedir? API'yi kullanıcı için değil, sağlayıcı için tasarlamak — çoğunlukla dahili veri yapılarını doğrudan dışarıya yansıtarak. Bu o an en rahat yoldur ve harici sistemleri, aslında serbestçe değiştirebilmek istediğiniz kendi iç yapınıza bağlar. Diğer hataların neredeyse tamamı bunun varyasyonlarıdır.

Geriye dönük uyumluluk bir noktada ayağa bağlı bir pranga olmaz mı? Bir maliyeti var, evet — eskimiş biçimleri taşımaya devam edersiniz. Ama alternatifi, yani istemcilerin çalışmasını bozmak daha pahalıdır: kaybedilen güven ve harici sistemlerde sessiz kesintiler. Uyumlu çözüm nadiren en zarif olanıdır, ama neredeyse her zaman daha ucuz olanıdır. Model temelden yanlış hâle gelirse, düzgün sürümlenmiş uyumsuz bir değişiklik dürüst çıkış yoludur.

Hangi sürümleme doğrudur — path, header mı yoksa medya tipi mi? Hiçbiri üstün değildir. Path görünürdür ve yönlendirmesi kolaydır, ama komple yeni sürümlere ayartır; header ve medya tipi daha ince tanelidir, ama daha görünmez ve daha karmaşıktır. Seçim bir sıralamadan değil, kullanıcıların kim olduğundan ve nasıl geliştirdiklerinden çıkar.

Hatalar neden sözleşmeye dahildir? Çünkü kullanıcılar onlara tepki vermek zorundadır. Bir istemci hataya göre dallanır — yeniden dene ya da düzelt. Hatalar belirsiz veya değişkense, başarılı durum kusursuz olsa bile API'yi kullanmak zordur. Bu yüzden hata kodları başarılı yanıtlar kadar istikrarlı olmalıdır ve anlamlarının değiştirilmesi, diğerleri gibi bir kırılmadır.

Gerçekten her API'nin idempotency'ye ihtiyacı var mı? Hayır. Salt okuma işlemleri ve doğası gereği idempotent operasyonlar bunu zaten içlerinde taşır. Emek, kendiliğinden tekrarlanabilir olmayan, durum ve para değiştiren operasyonlar içindir — ama orada karşılığını verir, çünkü ağ er ya da geç tekrarları zorunlu kılar.

Önce API'yi mi tasarlamalıyız, yoksa implementasyonu mu? Önce sözleşmeyi. Önce implementasyonu kurup API'yi ondan türeten, neredeyse kaçınılmaz olarak dahili iç yapıyı dışarıya yansıtır. Uygulamadan bağımsız olarak iş alanı şeklinde tasarlanmış sözleşme daha uzun dayanır — çünkü uygulama, sözleşmeye dokunmadan değişebilir.

İleri okuma

• İstemci sistemlerini bozmadan API sürümleme — uyumluluk, sürümleme ve deprecation'ın derin mekaniği.
• Dağıtık sistemlerde idempotency ve sözlükte idempotency — erişilebilir her API'nin neden tekrarlara dayanmak zorunda olduğu.
• Herkese açık bir API tasarlamak — pratik yaklaşım için uygulama kılavuzu.
• On yıl sonra hâlâ çalışan yazılım — sözleşme yüzeyinin neden sistemin en uzun ömürlü parçası olduğu.

Temelinde Batunet Engineering Method yatar: sözleşmeyi uygulamadan önce tasarlamak, değişim için inşa etmek, kimseyi şaşırtmamak.

Bir API'nin arkasındaki kod sizindir — onu istediğiniz zaman değiştirebilirsiniz. API'nin kendisini ise ödünç verdiniz. İyi tasarım, başkalarının güvendiği şeyi asla geri istemeden onu geliştirmeye devam etme sanatıdır.