Neredeyse Çalışmayan Sistem Fikirleri

Neredeyse Çalışmayan Sistem Fikirleri

• "Sadece eklenti yapılabilir hale getirelim"

  • Bir uygulama çalışmadığında, geliştiricilerin yeni bir uygulamayı kolayca ekleyebilmesini amaçlayan bir fikirdir. Ancak çoğu durumda API'nin sunduğu işlevler beklenildiği kadar sorunsuz çalışmaz. Gerçek anlamda eklenti esnekliği için ikinci uygulama en baştan birlikte tasarlanmalıdır.

• "Sadece API ekleyelim"

  • Geliştiricileri çekmek için platform kurarken API ekleme eğilimi sıktır. Ancak API sağlamak, uyumluluk ve birlikte çalışabilirlik için sürekli bir çaba gerektirir; API sunmak tek başına kullanıcı kazandırmaz. Platform oluşturmak ciddi bir iştir ve yalnızca API eklemek, ekonomik bir temel oluşturmak için yeterli değildir.

• "Bir katman daha soyutlayalım"

  • Bilgisayar biliminin “başka bir dolaylı referans düzeyiyle” bir sorunu çözebileceği söylenir. Ancak çok erken yapılan soyutlama, bakım, güvenlik ve performans optimizasyonunda sorunlar yaratabilir. Plan yapmadan eklenen soyutlama, kodun bakımını zorlaştırır.

• "Asenkron hale getirelim"

  • Asenkronluk bilgisayar biliminde uzun zamandır araştırılan bir konudur. Web frameworkleri bunu iyi soyutlar; ancak framework dışından asenkronluğu doğrudan yönetmeye çalışıldığında tahmin edilemeyen hata riski artar.

• "Erişim kontrolünü sonradan ekleyelim"

  • Sistem güvenliği baştan tasarlanmalıdır, ancak genelde pazara hızlı çıkma baskısıyla sonradan eklenir. Müşteri ve saldırgan bakış açısından erişim kontrolünü baştan düşünmezseniz, ürünü sonradan yeniden tasarlama ihtimaliniz artar.

• "Veri senkronizasyonu yapalım"

  • Veri senkronizasyonu çok zor bir problem olup, ancak deneyimle çözülebilecek pek çok zorluğu barındırır. Çözümleri veri senkronizasyonuna dayandırmak neredeyse tercih edilmez.

• "Çapraz platform geliştirelim"

  • Çapraz platform geliştirme, işletim sistemi, bulut sağlayıcısı veya tarayıcı geliştirmeye benzer. Platform yeni olduğu veya uygulama basit olduğu durumlarda çalışabilir ama zaman içinde giderek zorlaşır.

• "Yerel özelliklere kaçış imkanı bırakalım"

  • Çapraz platform sınırlı olduğunda, yerel işlevlere kaçış sağlayacak şekilde tasarlamak yaygındır. Ancak bu yöntem, çerçevenin tutarlı tuttuğu durumla çakışabileceğinden 10'da 9 kez başarısız olur.

• Sonuç

  • Bu yöntemlerin her zaman başarısız olması söz konusu değildir, ancak çoğu durumda daha iyi bir yol vardır. Temel prensiplere bağlı kalarak sorunu çözmek ve başarısızlık olasılığı yüksek yazılım kalıplarından kaçınmak önemlidir.

[ndrgrd]

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...

[GN⁺]

Hacker News Yorumu

• DSL'ler ve API'ler çoğu zaman başarılı olur. TensorFlow gibi çıkarım motorları da bir DSL ya da bir DSL'i saran bir API olarak görülebilir

  • SQL, Shader dilleri ve BPF de buna benzer örnekler olarak görülebilir
  • "Sadece bir API ekleyelim" yaklaşımı başarılı olmayabilir. Bir UI geliştirildiği gibi dikkatli ve ayrıntılı biçimde ele alınmalı

• DSL'ler bazen gerçekten iyi çalışır. jOOQ.org'a bakılabilir

• Elastic Load Balancer, iş yüküne tepki veren bir kontrol döngüsüdür. Bu bir bakıma üründür

• Çoğu endüstride kaynak kıtlığı yaygındır. İlgili referanslar olarak erikbern.com ve "Goal: Process of Ongoing Improvement"ya bakılabilir

• Anomali tespiti dağıtık sistemlerin bir sorunu değildir. Ancak sorunu yaşayanların bu alana ihtiyaç duyduğunu düşünebileceği olur

  • Isolation Forest algoritması bazen mucizevi sonuçlar verir. 2018'de metinlerde CNN tabanlı gömme kullanılarak iyi sonuçlar alınmıştı

• "Neredeyse" ifadesi burada uygun değildir. Bu sadece basit bir kötümserlik ve alaycılıktır

• Birçok kişi, istisnalar için ince bir karar fonksiyonu bulmaya çalışır. Ama pratikte durum basittir. Ben yaptığımda iyi oluyor, bir önceki kişi yaptığında olmuyor

• "Domain Driven Design", uygulamayı iş yapısına göre tasarlamak bir felaket tarifidir

  • Küçük bir işte sorun yaratmayabilir; ancak başarılı veya büyüyen bir işte bunu hemen pişmanlıkla karşılar
  • Bunun yerine işlev katmanı odaklı tasarlanmalı ve mümkün olduğunca iş mantığı veritabanı satırlarında ve kullanıcı iş akışlarında tutulmalıdır

• Yük tepkisi kontrol döngüsü temel ve vazgeçilmez bir bileşendir. Birçok sistemde kullanılır

• Birçok DSL, P2P önbellek ve hibrit paralellik kullanan projede çalıştım ve çoğu başarılı oldu

  • P2P önbellek gerekli olmadığından büyük başarı getirmedi
  • Karmaşık olsa da bu karmaşıklık, farklı yollarla elde edilemeyecek özellikler sağlar

• "Sadece veriyi senkronize edelim" yaklaşımı sorun yaratabilir

  • Çok sayıda sistem "internet ölçeği" hedeflenerek tasarlanmış olsa da, gerçekte bunun altında kalır
  • Bu tür ekipler ya saftır ya da en kötüsü, bunu çözmek için bir "mühendislik dışı yönetici"ye para akıtır

• Birçok fikri başarıyla uyguladım. Bu yüzden biraz tuhaf görünüyor