Neredeyse Hiç İşlemeyen Cazip Sistem Fikirleri
(hardcoresoftware.learningbyshipping.com)- “let’s just” diye başlayan sistem tasarımı önerileri çoğu zaman beklenenden daha karmaşık hale gelir; iyi mimari yargılar büyük ölçüde pratik kurallara ve bağlamı anlamaya dayanır
- Eklenti mimarisi, API eklemek ve soyutlama katmanları kulağa makul gelse de gerçekte davranış uyumluluğu, bakım, güvenlik, performans ve ekosistem gereksinimlerini birlikte taşımak zorundadır
- Asenkron işleme, erişim denetimi ve veri senkronizasyonu tanıdık konular gibi görünür; ancak ürün ortamında yeniden üretilmesi zor hatalara, güvenlik modelinin yeniden tasarlanmasına ve senkronizasyon açmazlarına kolayca dönüşebilir
- Çapraz platform ve native escape, basit erken aşama ürünlerde işe yarayabilir; ancak platform özellikleriyle iç durum birbirinden ayrıştığında kalite ve tutarlılığı korumak zorlaşır
- Bu kalıplar her zaman yanlış değildir; ancak çoğu ya gerekli değildir ya da alternatifleri vardır ve başarısız olma olasılığı yüksek yaklaşımlar yerine problemi ilk ilkelerden (first principles) yeniden çözmek gerekir
“let’s just” neden tehlikeli?
- “let’s just” ifadesinden sonra gelen öneriler, 10 seferin 9’unda toplantı odasında tahmin edilenden çok daha karmaşık bir işe dönüşür
- Mühendisliğin sosyal bilimlere benzeyen bir yönü de vardır; neyin işe yaradığı bağlama bağlıdır
- Bir yaklaşımın işe yaramayacağını söylediğinizde, mühendisler bunu çoğu zaman hemen bir karşı örnek kanıtlama meydan okuması olarak algılar
- Mühendislik yönetimi ve yazılım mimarisinin önemli bir bölümü, deneyimden gelen pratik kurallar (rule of thumb) ile zor yoldan öğrenilmiş derslerin birleşimidir
“Sadece eklentiyle genişletilebilir yapalım”
- Tek bir uygulama yetersiz göründüğünde aynı mimariye yeni bir uygulama takarsanız, API çağıran tarafları değiştirmeden iyileştirme veya yeni özellik elde edecekmişsiniz gibi görünür
- Ancak “API bir header dosyası ya da doküman değil, davranışın kendisidir”; bu yüzden sadece çalışır görünen eklentiler neredeyse hiç yoktur
- Modern yazılımda eklentiye en yakın bileşenler aygıt sürücüleridir
- Geçmişte sürücülerin davranış kalitesi iyi değildi; artık buna izin verilmiyor ya da modern işletim sistemleri kendi sürücülerini oluşturma yönüne kayıyor
- Gerçekten eklenti takılabilir bir yapı kurmak için, temel uygulamayla aynı anda ikinci bir uygulamayı da tasarlamak gerekir; böylece en azından bir kez çalıştığına dair kanıtınız olur
“Sadece bir API ekleyelim”
- Bir ürün ya da şirket belli ölçüde başarı kazandıktan sonra “platform olmalı ve geliştiricileri çekmeliyiz” diyerek API eklenmesi sık görülür
- API sağlayıcıları, özellik ekleme ile uyumluluk ve birlikte çalışabilirlik arasında sürekli ödünleşim yapmak zorunda kalır; mevcut davranış ve performans özellikleri nedeniyle değişiklik özgürlüğü ciddi biçimde azalır
- Bir API’nin var olması, birilerinin onu mutlaka kullanmak isteyeceği anlamına gelmez
- Yeni API’ler çoğunlukla ürünün bir özelliği istemesi, ancak bunu içeride yeterince yüksek önceliğe koymaması sonucunda ortaya çıkar
- Hedef pazarın küçük, dikey olarak özelleşmiş ya da belirli bir alanla sınırlı olduğu durumlarda, dış iş ortaklarının API ile boşluğu doldurmasının beklendiği bir tablo oluşur
- Bu iş ortaklarının da kendi işleri ve müşterileri vardır; bu yüzden başka bir ürünü ek olarak devreye alıp sorunu çözmek istemeyebilirler
- Platform olmak, gerçek talebi büyük olan bir iştir; birkaç API sunmakla üçüncü taraflar için ekonomik bir zemin oluşması nadirdir
“Bir soyutlama katmanı daha ekleyelim”
- Butler Lampson’ın “Bilgisayar bilimindeki tüm problemler bir başka dolaylılık katmanıyla çözülebilir” sözünde gerçek bir doğruluk payı vardır
- Başarısızlık çoğunlukla iki şekilde ortaya çıkar
- Çok erken eklenen soyutlama, gerçek kullanım planı olmadan aşırı soyutlama olarak mimaride kalır
- Sonradan eklenen soyutlama ise bakım, güvenlik ve performans optimizasyonunu çok karmaşık hale getirebilir
- Windows NT’de baştan itibaren yer alan, ancak gerçekte kullanılmayan pek çok aşırı soyutlama vardı
- Mac OS’nin evriminde, başlangıçta garip görünen bir soyutlamanın iki sürüm sonra faydalı hale geldiği örnekler vardı; fark, bir planın varlığıydı
- Sonradan eklenen soyutlama yalnızca bazı kodlarda kullanılırsa, yeni soyutlamayı kullanmayan kod miktarı artar ve bakım yükü büyür
“Asenkron yapalım”
- Bilgisayar biliminin ilk 25 yılının kayda değer bir bölümü, asenkron davranışı anlama ve uygulama sorununa harcandı
- 1980’lerde lisansüstü derslerde yemek yiyen filozoflar, üretici-tüketici ve uyuyan berber gibi konular uzun uzun ele alınırdı
- Günümüzde birçok mühendis, veri katmanı kuralları ve web framework’leri sayesinde asenkron problemleri büyük ölçüde soyutlanmış biçimde ele alıyor
- Framework veya veri katmanı dışında asenkronluğu doğrudan yönetirseniz, başlangıçta iyi çalışıyor gibi görünüp bir yıl sonra yeniden üretilmesi zor hatalar ortaya çıkarabilir
- Tek umudunuz, bu hataların veri bozulması sorunu olmamasıdır
“Erişim denetimini sonra ekleriz”
- Erişim denetiminin nerede konumlanacağı teorik tartışma konusu olmuştur; ancak günümüz sistemleri sürekli saldırı altında olduğundan çok daha karmaşık bir ortamda bulunur
- Herkes en baştan güvenliğin gerekli olduğunu bilir; ama pazara çıkış hızı nedeniyle erişim denetimini ve güvenlik modelini baştan eksiksiz tasarlayan sistem sayısı çok azdır
- Müşterilerin ve saldırganların bakış açısından başlamazsanız ürüne uygun bir erişim denetimi tasarımı oluşturmak zordur
- Erişim denetimini sonradan ekleme yaklaşımı başarısız olabilir ya da ileride ürünü yeniden yazmak zorunda bırakabilir
- Bu yeniden yazım, müşteriler dahil herkes için kötü bir deneyim olur
“Verileri senkronize edelim”
- Birden fazla cihazın, SaaS uygulamasının ve veri deposunun bulunduğu ortamlarda “sadece verileri senkronize edelim” önerisi sıkça ortaya çıkar
- Client/server ve veri senkronizasyonunun öncülerinden Ray Ozzie’nin vurguladığı gibi, senkronizasyon zor bir problemdir
- Bilgisayar biliminde zor problem, yalnızca deneyimle öğrenilebilecek çok sayıda meydan okuma içeren ve son derece çetrefilli problem demektir
- Tam anlamsal yapıya ve transaction’lara sahip veri depolarında bile senkronizasyon zordur; blob’lar, yapılandırılmamış veri ve veri dönüşümü devreye girdiğinde zorluk hızla artar
- Bir çözümün temelini veri senkronizasyonuna dayandırmak neredeyse hiç istenmeyen bir tercihtir; yalnızca senkronizasyon üzerine milyarlarca dolarlık şirketlerin var olmasının nedeni de budur
“Çapraz platform yapalım”
- Çapraz platform uzun süredir tekrar eden bir tartışmadır; birileri kendi yazdığı kodun iyi çalıştığını söyleyebilir ya da Unity ve oyunları örnek gösterebilir
- Bir şeyi çapraz platform yapacağınızı söylediğinizde, aslında bir işletim sistemi, bulut sağlayıcısı ya da tarayıcıdan birini yapmayı vaat etmiş olmaya yaklaşırsınız
- Çapraz platform iki durumda iyi çalışır
- Platform yeni ve basit olduğunda; örneğin bulutun compute ve basit storage düzeyinde olduğu zamanlarda
- Uygulama ya da ürün yeni ve basit olduğunda
- Temel platformdan ayrıştığınızda ya da her hedef platformda bambaşka şekilde ifade edilen özellikler geliştirmeye başladığınızda bu koşullar bozulur
- Microsoft, Mac için Office ile Windows için Office’i aynı kodla geliştirmekte zorlanınca 1998’de Office kodunu fork etti ve sonrasında geri dönmedi
- Microsoft aslında çapraz platform uygulamalar yapan bir iş olarak var olmuştu; ancak bu, işletim sistemi API dokümantasyonunun 100 sayfa civarında olduğu ve her işletim sisteminin CP/M’den türediği dönemlerde iyi çalışan bir yaklaşımdı
- İlgili yazı: Divergent Thoughts on Cross Platform
“Gerekirse native’e kaçış yolu bırakalım”
- Çapraz platform yalnızca kısa süreliğine iyi çalıştığı için framework’ler ve API soyutlamaları çoğu zaman native escape sağlar
- Bu fikrin amacı, platform geliştikçe framework’ün henüz açmadığı özellikleri doğrudan native platformdan çağırabilmektir
- Ancak soyutlama sunan framework veya API, iç durum ya da cache tutar
- Native platformu doğrudan çağırdığınızda, framework’ün bilmediği veri yapıları ve durum değişir
- Bazı framework’ler, kaçış yolu kodu ile framework arasında veri ya da durum alışverişi için mekanizmalar sunar; ancak bu, otomatik bellek yönetimi çağında malloc/free benzeri bir mimariyi yeniden devreye sokmaya yakın bir çözümdür
Seçilebilir ama varsayılan değildir
- Bu yaklaşımlara her zaman “hayır” demek gerekmez
- Belirli bağlamlarda bu yöntemler işe yarayabilir
- Ancak çoğu durumda bu kalıplar gerekli değildir ya da daha iyi bir yol vardır
- Başarısız olma olasılığı yüksek yazılım kalıplarını önce elinize almak yerine problemi ilk ilkelerle çözmek gerekir
2 yorum
Plug söz konusu olduğunda, yalnızca gerekli davranışları olabildiğince ayıklayarak arayüz tasarlamak en önemli şey.60; Arayüzü sadece mevcut koddaki yapıyı kabaca alıp yaparsanız, doğal olarak bu, o uygulamaya hapsolan gereksiz bir arayüz olur ama gerçekten çok sık karşılaşılıyor...
Hacker News yorumları
Bu tür fikirlerin sorunu, fikrin kendisinden çok önüne eklenen “bir deneyelim gitsin” yaklaşımı ya da beklentilerde yatıyor
Örneğin “bir API ekleyiverelim” diye bakıp API’yi ürünün “sadece bir özelliği” gibi görmek, başarı ihtimali açısından “bir UI ekleyiverelim” demekten pek farklı değil
İyi bir UI yapmak dikkatli ve titiz olmayı gerektirir; ayrıca o alanda uzman kişiler de gerekir
Ürünün başka bir arayüzü olan API’nin de farklı olması için bir neden yok; mesele fikrin kötü ya da iyi olması değil, öylece yapılamayacak bir iş olması
“Sadece” ya da “bir” diyebilen kişiler, gerçekten onu çalışır hale getirme sorumluluğunu üstlenen geliştiricilerdi; başka bir geliştirici bunu söylerse, o işi bizzat üstlenmek için gönüllü olmuş sayılırdı
Bizim için iyi işleyen bir kuraldı
Bir API’yi düzgün yapmak için ciddi miktarda tasarım ve karmaşıklık yönetimi gerekir
İyi tasarlanmazsa istemcinin tek seferde yapılabilecek bir iş için birden fazla çağrı yapması gerekebilir; ya da API kafa karıştırıcı olduğu için yanlış çağrılır veya hiç kullanılamaz
Kimlik doğrulama ve yetkilendirme de gerekir; yani OAuth2 kurmanız ya da en azından güvenli API token’ları üretme, saklama ve doğrulama mekanizmasına sahip olmanız gerekir
Veriler de güvenli şekilde ele alınmalıdır; performans kötüyse veritabanı yük altında ezilebilir
Caching eklerseniz cache invalidation ve cache’i destekleyecek sunucu/süreç karmaşıklığı da eklenir
Rate limiting yoksa özensiz istemciler API’ye abanabilir; dokümantasyon zayıfsa da fiilen işe yaramaz
Duruma göre birden fazla dil için SDK da sunmanız gerekebilir; iyi hata mesajları yoksa ilk kez kullanan biri çağrının neden başarısız olduğunu anlayamaz
İnsanlar kendilerinde ters giden şeyleri genelliyor ama çok benzer durumdaki aynı kişi değilseniz neredeyse doğrudan uygulanamıyor
Sürekli doğru çıkan tavsiyeler ise “dikkatlice düşün, doğru olanı yapmaya çalış ve sonucu gözden geçir” gibi o kadar genel oluyor ki neredeyse işe yaramaz hale geliyor
Böyle sözlerle ne blog yazısı ne de kitap iyi satar
Çünkü müşterinin, buzdağının geri kalanını suyun üstüne çıkarmaya başladığınızda korkup kaçmamasını sağlamak gerekiyor
Böylece yazı mümkün/imkânsız meselesinden çıkıp başarı ve başarısızlığın nasıl ortaya çıktığına dair bir yazıya dönüşürdü
Gereken ayrıntıları öğrenince, ne bilmediğini bilmeden “öylece” demek de zorlaşıyor
Yalnız DSL konusunda neredeyse %100 katılıyorum
Bu, gereksiz ve sevimli görünmeye çalışan bir karmaşıklaştırmaya çok yakın; bunu yapmaya ehil sayılabilecek kişi, başarılı bir programlama dili yapmış, hatalarından ders çıkarıp ikinci baskısını ya da ikinci dilini bile geliştirmiş ama yine de pek çok şeyi yanlış yapmış biri olmalı
(1) DSL bazen gerçekten çok iyi çalışır. https://www.jooq.org/ bkz.
(2) Elastic Load Balancer, iş yüküne tepki veren bir kontrol döngüsüdür ve bu tür şeyler zaten genelleşmiş bir teknolojidir
(3) Çoğu sektörde yetersiz provizyon yaygındır. https://erikbern.com/2018/03/27/waiting-time-load-factor-and... ve https://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0... bkz.
(4) Anomali tespiti, diğer maddeler gibi özünde bir dağıtık sistem problemi değil ama bir kez ciddi şekilde canı yanan biri bunun gerekli olduğunu düşünebilir
Entelektüel olarak da zor bir alan
Bana ilk kez bir ölçüde akıllı gelmiş algoritma https://scikit-learn.org/1.5/modules/outlier_detection.html#... olmuştu ve bazen mucize gibi çalışıyor
2018'de kullandığım CNN tabanlı embedding'lerle metne uygulandığında iyi uyuyordu ama SBERT ile hiç şansım olmadı
Sorunu çözdüler ve kimse söylenmedi
En önemli etkenin ikisinin de küçük olması olduğunu sanıyorum
İkisi de çok benzerdi ve kodu da yeniden kullandık
Biri devasa bir formu doğrulamak için kural yazmaya, diğeri de form yanıtlarına göre karar kuralları yazmaya yarıyordu
İyi bir DSL, daha önce yapamayan insanların yapabilmesini sağlar
Zamandan tasarruf için yapılan bir DSL'nin faydalı olma ihtimali çok daha düşüktür, çünkü pratikte zaman kazandırmama olasılığı büyüktür
Her iki durumda da karmaşık alan davranışlarını programın içine taşımamız gerekiyordu
Bu yüzden ya programcılara alanı öğretmeniz, ya programcıları alan uzmanlarıyla eşleştirmeniz ya da alan uzmanlarına programlamayı öğretmeniz gerekir
Çok iş varsa, yetkiyi alan uzmanlarının eline vermek caziptir
Programcılar başka iş yapabilir ve geri bildirim döngüsü de kısalır
Alan derinse, programcıları okula gönderip bunu öğrenmelerini istemezsiniz; sığsa da bunu daha düşük maliyetli biri yapabilir
DSL'ler büyük bir bilişsel yük getirir
Ama alternatif tam teşekküllü bir programlama dili öğrenmekse daha makul hale gelir
Zaman kazandırma amaçlı DSL'ler, zaten kod yazabilen birinin daha az kod yazmak istemesi durumudur; kazanım küçük olduğu için genelde pek iyi değildir
Sonra bir programcının bir şeyi değiştirmesi gerektiğinde, sezgisel kod yerine bu DSL'nin tamamını öğrenmesi ya da hatırlaması gerekir
Daha basit bir sezgisel kural olarak, programcılar için DSL'ler programcı olmayanlar için DSL'lere kıyasla daha az iyi fikir olma eğilimindedir
SQL sorgusunu yazıp DataGrip gibi araçlarda test ettikten sonra, onu DSL'ye nasıl çevireceğimi anlamaya çalışırken saatler harcadım
JSON ifadeleri gibi “egzotik” SQL özellikleri kullanırsanız durum daha da kötüleşiyor
Hata ayıklama, “üretilen SQL'i yazdır, DataGrip gibi bir yere kopyala, sorguyu ayarla, sonra bunu tekrar DSL'ye nasıl uyduracağını bul” akışına dönüşüyor
Muazzam bir zaman kaybı
jOOQ'nun temel satış noktası tip güvenli sorgular, ama IntelliJ kod içindeki string SQL'i gerçek veriye göre doğrulamaya başlayınca bunun önemi kayboldu
SQL'i doğrudan düzenleyip veritabanında anında test etme akışı düpedüz daha iyi
jOOQ, DSL'ler hakkındaki asıl yazının tezini güçlendiriyor
Kötü ya da başarısızlığa yakın sayılabilecek popüler DSL örnekleri arasında HCL, E4X, XUL ve Common Lisp'in string formatlama dili var
HCL, Terraform yapılandırma dili; buna rağmen benzer ekipmanı değişken sayıda provizyon etme gibi çok yaygın bir problemi en baştan ele almadığı açıkça görülüyordu
Sonradan özellik ekleme girişimleri de hantaldı ve problemi tam çözmedi
E4X, XML ile çalışmak için bir JavaScript DSL'siydi; basit durumlarda XML işlemlerini daha kısa ifade etmeyi sağlıyordu ama çok hızlı şekilde noktalama işaretleri duvarı gibi okunamaz hale gelebiliyordu
Microsoft'un LINQ'suna benzer biçimde, yazara alttaki kodun hesaplama karmaşıklığının ne olabileceğine dair hiçbir fikir vermiyordu
Sonunda bu DSL ile yazılmış kodlar, daha az özlü ama analiz etmesi daha kolay biçimlerde yeniden yazılırdı
XUL, Firefox tarayıcı chrome uzantıları için bir UI diliydi ve Firefox uzantısı yapma amacı için fena değildi
Ama Firefox bunu şirket içi uygulama platformu olarak da pazarlamak istiyordu ve o alanda ciddi biçimde yetersizdi
Basit işleri yapmak için çok sayıda hile ve dolambaç gerekiyordu
Common Lisp'in string formatlama dili de benzer şekilde küçük problemler için fena değil ama ölçeklenebilir değil
Bazı formatlama problemleri çok tuhaf çözümler gerektiriyor ya da baştan hiç çözümü olmuyor;
formatı özyinelemeli çağıran kod görünce gerçekten nefret ediyorumGenel olarak bu yaklaşımın en yaygın sorunu, geçici çözümlerden ibaret olması ve iyi ölçeklenmemesi
Çok geçmeden düzgün çözülemeyen bir probleme çarpıyorsunuz ve DSL ile yazılmış büyük programlar çoğu zaman yönetmesi kâbus oluyor
Lisp üzerine bir DSL koyarsanız, temel dili değil sadece alan mantığını yazmanız gerekir
İşin büyük kısmı zaten bitmiştir ve dil ilk günden kullanışlıdır
Lisp üzerinde barındırılan bir DSL olarak yapınca gerçekten kullanılabilir hale geliyor; o halde neden sıfırdan yeni bir dil yapıp sönüp gitmesini izlemekte ısrar edildiğini anlamıyorum
Bu maddelerin hepsinin çok sayıda başarılı örneği var
Bu yüzden “neredeyse” kelimesini bir kaçış kapısı olarak kullanmak zor
Bu, daha çok karamsarlık ve yorgun bir alaycılık gibi görünüyor
Bu hissi anlıyorum, ben de yaşadım; ayrıca tutkulu mühendislere kötü fikirlerden vazgeçirmek bazen zor olabiliyor
Ama bu üslup bana zararlı geliyor
Sonsuza ya da maksimum/minimum sınırlara kaçan kontrol döngüleri, dağıtık arızalardan toparlanamayan önbellekler, canlı taşıma sırasında bozulmuş durumlar, en uygunsuz anda aşırı yük yaratan patlamalar, dünya çapındaki resmî tatilleri haber veren sahte anomali tespit uyarıları gibi şeyler
Bu fikirlerin neredeyse hepsinin altında, hemen herkesin hafife aldığı bir karmaşıklık yumağı yatıyor
Bu, ilk bakışta düşündüğünüzden daha zor olan sistem fikirlerinin listesi; ciddiyetle ele alınmalı, hafife alınmamalı
“İyi görünür ama neredeyse hiçbir zaman çalışmaz” ifadesine belirsiz biçimde benziyor ama ayrıntıda tamamen farklı
Bunlara zor problemler gibi davranıp ona göre yatırım yaparsanız, düzgün çalışmaları gayet sıradan biçimde ulaşılabilir bir sonuçtur
Sonradan eklenen bir özellik gibi ele alınırsa ya da safça kolay sanılırsa, işler sık sık ters gider
Bana daha çok, ortada ticari bir fayda yokken mühendislerin erken optimizasyon peşine düşmesinden söz ediyor gibi geliyor
Bu sektörde gerçekten çok yaygın; çünkü birkaç saat içinde dağıtıma alınabilecek bir yedek hazırlayıp sunucuları %200 fazla kapasiteyle ayırarak maliyeti onda birin altına indirebileceğiniz bir iş yerine, yedekli otomatik ölçeklenen uzay gemileri tasarlayıp inşa etmek daha eğlenceli
Bu fikirlerin yerinde olduğu zamanlar var, ama o da ihtiyaç gerçekten doğduktan sonra
Erken ürün aşamasında önceden tasarlanıp sisteme gömülecek şeyler değiller
Bu tür uygulamaların çözmeye çalıştığı ölçek, erişilebilirlik ve karmaşıklığa gerçekten ihtiyaç duyan ürünler çok nadir
Burada pek çok kişi istisnaları ayıran ince bir karar fonksiyonu arıyor gibi görünüyor, ama aslında basit
Bu fikirler ben yaparsam harika, ama benden önceki aptal yaptıysa asla amaçlandığı gibi çalışmaz
Ve bazen o önceki aptal, birkaç ay önceki kendim oluyorum
Buna bir de alan güdümlü tasarım eklemek isterim
Uygulamayı iş yapısına uydurmaya çalışırken iş tasarımını dondurmak, felakete giden bir reçetedir
İş küçükse ya da durağansa sorun fark edilmeyebilir
Ama iş başarılı olur ya da büyürse, kısa süre içinde zaten eskimiş iş pratiklerine bağlanmış korkunç derecede açıklayıcı isimli alanlar oluşturmaya çalıştığınıza pişman olursunuz
Bunun yerine, onlarca yıldır kendini kanıtlamış biçimde işlev katmanları etrafında tasarlamak ve iş mantığını mümkün olduğunca yapılandırmada, veritabanı satırlarında ve kullanıcı iş akışlarında tutmak çok daha esnektir
Alan güdümlü tasarımın tuzakları arasında eskimiş dil ve yeni girişimlerde düşük kod/sistem yeniden kullanımını gördüm; ama tersine, iş mantığını yapılandırmaya, iş akışlarına vb. yığan son derece soyut bir tasarım da ancak tüm organizasyon bu soyutlamaları, yapılandırmaları ve sayısız kombinasyonu oldukça iyi anlıyorsa esnektir
Bu kombinasyonlar hızla labirent gibi çoğalır ve insanların bağımlı hale geldiği, bilinmeyen ve öngörülmeyen davranışlar üretir
Yeni geliştirici onboarding’i ve ekip değişim maliyeti de taşınamaz hale gelir
Organizasyon iki farklı dil konuşmaya başlar
Basit görünen özellik taleplerinin çoğu, soyutlamayı bozuyorsa devasa bir sistem yeniden tasarımına dönüşür ya da “şimdilik daha güvenli ve küçük bir değişiklik gibi görünsün diye bu soyutlamayı biraz hackleyelim” noktasına gelir
İlki, tüm sistem davranışını ve kod tabanını eksiksiz anlayan mükemmel mühendisler ile mükemmel mühendislik pratikleri ve süreçleri olsa bile her zaman çok zordur; aylar hatta yıllar sürebilir
Daha sık olan ikincisidir; bu yüzden “yüksek derecede soyutlanmış, işlev katmanlı, yapılandırma tabanlı ve iş mantığı ortaya çıkan” projeler başlangıçta kusursuz ve esnek görünürken sonunda “bu da ne böyle” noktasına gelir
Sistem uygulandıktan sonra, ortaya çıkmış o iş mantığı herkesin konuştuğu dil haline gelir
Organizasyon birbiriyle uzlaştırılamayan iki ya da üç farklı dil konuşuyorsa ve bunlar arasında yukarı-aşağı ve yatay eksende akıcı çeviri yapabilecek birkaç kişi yoksa, insan sonunda alanı daha doğrudan ifade etmek gerekirdi diye düşünmeye başlar
Bir durumu tür sistemiyle ifade edilemez hale getirecek şekilde tasarlıyorsanız, tasarımın ömrü boyunca o durumun gerçekten imkânsız bir durum olarak kalacağından emin olmanız gerekir
Yüke tepki veren kontrol döngüleri maddesini pek anlayamadım
Sayısız sistemin temel ve kurucu bileşenidir
1800’lerdeki buhar makinelerindeki ya da 1900’lerdeki Victrola plakçalarlardaki santrifüj regülatör bile yüke tepki veren bir kontrol döngüsüdür
Elektroniğin tamamı yüke tepki veren kontrol döngülerinden oluşan bir ağdır; otomatik otomobil şanzımanları da öyle
CPU kullanımı eğlenceli bir örnek
Örneğin, bölgeler arası bir yük dengeleyicinin süreç içi yük kesmeyle kavga ettiği durumlar görebilirsiniz
Çünkü yük dengeleyicinin sinyali yük kesmeyi ya hiç yansıtmaz ya da bunu yanlış yansıtır
Bir başka sorun da, hizmete yerel sonucu optimize etmeye çalışan bir kontrol döngüsünün toplam sonucu kötüleştirmesidir
Genel olarak, etkisi büyük noktalara az sayıda kontrol döngüsü koymanın daha iyi olduğunu düşünüyorum
CPU yükünün, https://arxiv.org/abs/2312.10172 içinde açıklandığı gibi bazı sorunları var
Bu sorunların ortak bir deseni var
Hepsi, programcılara tanıdık gelen sıralı veri işleme programlama modeline eklenen ortogonal kaygılar
Her kısıt eklendiğinde, o sistem üzerinde bundan sonra geliştirme yapacak tüm geliştiricilerin sürekli düşünmesi gereken şeylerin sayısı artıyor
Sistem kolayca aşırı kısıtlanmış hale gelip, bazı kısıtlar gevşetilmeden ilerlenemeyen bir duruma düşebiliyor
İmkânsız olmasa bile yavaşlatıyor
Çünkü geliştiricinin, yeni özelliğin daha önce destekleme sözü verilmiş API, güvenlik, senkronizasyon, gecikme süresi, diğer platformlar ve yerel kodla nasıl etkileşeceğini her seferinde düşünmesi gerekiyor
Bu yüzden tüm bu özellikleri desteklemek de mümkün
Örneğin şeffaf veri senkronizasyonunu platformun temel değer önerisi haline getirirseniz, sonraki tüm geliştirme bunu öncelikli olarak destekler ve mümkün özellik kümesi o kısıtlar içinde evrilir
Bu özellik kümesi kullanıcıların tam olarak istediği şeyle aynı olmayabilir, ama destekleyebildiği kapsam budur
Ürün, bu özelliği satın alma kararında birinci öncelik yapan müşterilere çekici görünür
Birden fazla DSL, P2P cache ve karma paralellik kullanan projelerde çalıştım ve hepsi çalıştı
İnşa etmesi de gerçekten çok eğlenceliydi
Bir istisna dışında iyi bir yatırımdı
P2P cache gerekli değildi, bu yüzden sonunda pek geri dönüş sağlamadı
Dolayısıyla bu tür şeylerin neredeyse hiç işe yaramadığını söylemek açıkça yanlış
Karmaşıklar, ama bu karmaşıklık başka yollarla elde edilmesi zor olan yetenekler getiriyor
P2P cache örneğinden çıkarılan ders, önce bu özelliğin gerçekten gerekli olup olmadığından emin olmak gerektiği
Bu fikirlerin epey çoğunu başarıyla hayata geçirdiğim için biraz tuhaf geliyor
“Sadece veriyi senkronize edelim” benim için zor günlerin neden var olduğunu açıklıyor
Kuyruklar, event handling ve benzerlerini ekleyip bunu “internet ölçeği” gibi şeyler düşünülerek tasarlanmış sistemlerde çok gördüm, ama gerçek doğal kapsam o eşiğin çok daha altında
Bu tür ekipler ya saf ya da en kötü durumda, mühendislikten anlamayan yöneticileri kullanıp eğlenmek için bu problemlerle uğraşmaya para çekiyorlar
Düzgün yapmak için kuyruklar ve event handling şart