2. Yalan: Dünya modeli etrafında kod tasarlanmalı mı? [kapalı]

Geçenlerde Three Big Lies blog gönderisini okudum ve burada belirtilen ikinci yalanı haklı çıkarmak için çok zorlanıyorum:

(LIE # 2) DÜNYANIN BİR MODELİ ÜZERİNDE KOD DÜŞÜNMELİDİR

Kodda, hayali bir dünya modelinin ya da modelinin bir değeri yoktur. Bunun neden bazı programcılar için bu kadar zorlayıcı olduğunu bilmiyorum, ama son derece popüler. Oyunda bir roket varsa, tam olarak bir roket için veri içeren ve roketli şeyler yapan bir "Roket" sınıfı (kodun C ++ olduğu varsayımı) olduğundan emin olun. Hangi verilerin değişiminin gerçekten yapılmakta olduğu ya da verilerin düzenlenmesi ile ilgili olarak. Veya bu konuda, temel bir anlayış olmadan, tek bir şeyin olduğu yerde, muhtemelen birden fazla şeyin olduğu anlaşılmaz.

Bu tür bir tasarım için çok fazla performans cezası olsa da, en önemlisi ölçeklendirilmemesidir. Hiç. Yüz roket, bir roketten yüz kat daha pahalıdır. Üstelik bundan daha pahalıya mal olması çok muhtemel! Programcı olmayanlara bile, hiç mantıklı gelmemelidir. Ölçek ekonomisi. Daha fazla bir şeyiniz varsa daha ucuza almalı, daha pahalı olmamalı. Bunu yapmanın yolu da verileri uygun şekilde tasarlamak ve benzer dönüşümlerle gruplandırmaktır.

Özellikle bu yalanla ilgili problemlerim.

1. Kodda, hayali dünyayı modellemenin yardımcı olduğu (en azından ben, kişisel olarak) kodu görselleştirip organize ettiği için hayali bir dünyanın bir modeli / haritası olmanın değeri vardır.

2. Bir "Roket" sınıfına sahip olmak, benim için, bir sınıf için mükemmel geçerli bir seçimdir. Belki de "Roketler", yük taşıma kuvveti, maksimum hız, maksimum dönüş yarıçapı, hedefleme tipi ve benzeri şeyleri içeren AGM-114 Cehennem Ateşi gibi roket türlerine ayrılabilir, ancak yine de ateşlenen her roketin bir pozisyonu olması gerekir. ve bir hız.

3. Tabii ki 100 Roket sahibi olmak 1 Roketten daha fazladır. Ekranda 100 Roket varsa, konumlarını güncellemek için 100 farklı hesaplama yapılmalıdır. İkinci paragraf, 100 Roket varsa, durumu güncellemenin 100 hesaplamadan daha azına mal olması gerektiği iddiasındadır.

Buradaki sorunum yazarın "hatalı" bir programlama modeli sunması ancak onu "düzeltmenin" bir yolunu sunmaması. Belki de Rocket sınıfının analojisini açıyorum, ama bu yalanın arkasındaki mantığı gerçekten anlamak istiyorum. Alternatif nedir?

Öncelikle, bazı bağlamlara bakalım: bu, konusu bir Cell BE işlemcisinin son performans düşüşünü belirten bir blogda yazan bir oyun tasarımcısı. Başka bir deyişle: bu, oyun konsolu programlaması, daha spesifik olarak, PlayStation 3 için oyun konsolu programlaması ile ilgilidir.

Şimdi, oyun programcıları meraklı bir demet, konsol oyun programcıları daha da öyle ve Cell BE oldukça garip bir işlemci. (Sony'nin PlayStation 4 için daha geleneksel bir tasarıma sahip olmasının bir nedeni var!)

Dolayısıyla bu ifadelere bu bağlamda bakmamız gerekiyor.

Bu blog yazısında da bazı basitleştirmeler var. Özellikle, bu Lie # 2 zayıf bir şekilde sunulmuştur.

Gerçek dünyadan soyutlayan her şeyin bir anlamda bir model olduğunu savunuyorum . Yazılım gerçek olmadığı, ancak sanal olduğu için, her zaman bir soyutlama ve dolayısıyla her zaman bir modeldir. Fakat! Bir modelin gerçek dünyaya 1: 1 oranında eşlemeli olması gerekmez. Ne de olsa, her şeyden önce onu model yapan şey budur.

Yani, bir bakıma, yazar açıkça yanlıştır: yazılım olan bir modeli. Dönemi. Başka bir anlamda, haklı: bu model aslında gerçek dünyaya benzemek zorunda değil.

OO 101 Banka Hesabına (in) ünlü Giriş örneğindeki yıllar boyunca zaten bazı cevaplarda verdiğim bir örneği vereceğim. İşte bir Banka Hesabının şimdiye kadarki her OO sınıfında nasıl göründüğü:

class Account {
  var balance: Decimal
  def transfer(amount: Decimal, target: Account) = {
    balance -= amount
    target.balance += amount
  }
}

Yani: balancebir veri ve transferbir olduğunu operasyon .

Fakat! İşte bir Banka Hesabının şimdiye kadarki her bankacılık yazılımında nasıl göründüğü:

class TransactionSlip {
  val transfer(amount: Decimal, from: Account, to: Account)
}

class Account {
  def balance = 
    TransactionLog.filter(t => t.to == this).map(_.amount).sum - 
    TransactionLog.filter(t => t.from == this).map(_.amount).sum
}

Bu yüzden, şu anda transferbir veri ve balancebir bir işlem (işlem günlüğü fazla kat sol). (Ayrıca TransactionSlipdeğişmez olduğunu , balancesaf bir işlev olduğunu fark edeceksin, TransactionLogsadece son derece "neredeyse" değişmez bir veri yapısı olabilir ... Eminim çoğunuz ilk uygulamada göze çarpan eşzamanlılık hatalarını farkettiniz, şimdi sihirli bir şekilde ortadan kayboluyor. .)

Bunların her ikisinin de model olduğuna dikkat edin . Bunların her ikisi de eşit derecede geçerlidir. Bunların ikisi de doğru. Bu modelin her ikisi de aynı şeyi. Ve yine, onlar tam olarak ikili bir modelde bir operasyon diğer modelde veridir olan bir modelde veriler diğer modelde bir operasyondur olan her şeyi ve her şey: birbirlerine.

Yani, soru değil olmadığını kodunuzda "gerçek dünya" modellemek ama nasıl bunu modellemek.

Görünen o ki, ikinci model aslında bankacılığın gerçek dünyada nasıl yürüdüğüdür. Ben, bu ikinci model, aslında bir süresi çok uzun zaman önce, nereye olmadığını düşünürsek çok önemli eşzamanlılık hataları, çoğunlukla değişmez ve saf ve bağışıklık yukarıda ima gibi TransactionSlips idi fiili etrafında gönderilen kağıt makbuzları at ve vagon ile.

Bununla birlikte, bu ikinci modelin hem gerçek dünya bankacılığının nasıl çalıştığını hem de gerçek dünya bankacılık yazılımının nasıl çalıştığını gerçekten eşleştirmesi, onu otomatik olarak daha “doğru” yapmaz. Çünkü, aslında, ilk ("yanlış") model, bankacılık müşterilerinin bankalarını nasıl gördüklerine oldukça yaklaşıyor . To Bunlardan , transferbir olan operasyon (onlar bir form doldurmak zorunda) ve balancebir parça veri hesap tablosu altındaki.

Yani, çok iyi bir yüksek performanslı PS3 shooter çekirdek oyun motoru kodunda, bir olmayacak doğru olabilir Rockettip, ama yine de orada olacak bazı modeli garip görünse bile devam dünyasının modelleme Konsol oyunu fizik motoru programlama alanında uzman olmayan birine.

Önerdiği her "yalan" ile aynı fikirde değilim.

TL; DR Bu makalenin yazarı, makalesini daha ilginç hale getirmek için tartışmalı olmaya çalışıyordu, ancak “yalanlar”, yazılım geliştiricileri tarafından iyi nedenlerle kabul edildi.

Lie # 1 - Big O ölçeklendirme için önemlidir. Hiç kimsenin küçük bir uygulamanın daha uzun zaman alması umrunda değil, sadece zaman sabiti önemlidir, giriş boyutunu iki katına çıkardıklarında, yürütme süresini 10 kat ile çarpmamasına dikkat ederler.

Lie # 2 - Programların gerçek dünyadan sonra modellenmesi bir programcının koduna 3 yıl sonra bakıp ne yaptığını kolayca anlamasını sağlar. Kodun korunabilir olması gerekir veya yalnızca programın ne yapmaya çalıştığını anlamaya çalışmak için saat harcamanız gerekir. Başka bir cevap, LaunchPadve gibi daha genel sınıflara sahip olabileceğinizi önerdi MassiveDeviceMover. Bunlar mutlaka kötü bir sınıfa sahip olmak zorunda değildir, ancak yine de Rocketsınıfa ihtiyacınız olacaktır . Birinin ne yaptığını MassiveDeviceMoverveya ne yaptığını nasıl bilmesi gerekiyor ? Hareketli dağlar mı, uzay gemileri mi yoksa gezegenler mi? Bu, temel olarak, bu gibi sınıflara eklemenin MassiveDeviceMover, programınızı daha az verimli hale getirdiği anlamına gelir (ancak muhtemelen daha okunaklı ve anlaşılabilir).

Ek olarak, geliştirici zamanının maliyeti, uzun zaman önce donanım maliyetini aşmaya başladı. Düşünceleriniz önünde optimizasyon ile tasarlamaya çalışmaktan başlamak korkunç bir fikir. Kolay ve anlaşılır bir şekilde programlıyorsunuz ve ardından programlarınızın hangi kısımlarının çalıştırılmasının çok zaman aldığını tespit ettikten sonra programın ince ayarını yapıyorsunuz. Unutma: Uygulama süresinin% 80'i programın% 20'si tarafından kullanılıyor.

Lie # 3 - Kod çok önemlidir. İyi yazılmış (ve modüler) kod yeniden kullanılabilirliğe izin verir (sayısız adam saatini korur). Ayrıca, kötü verileri gözden geçirmenize ve tanımanıza olanak sağlar, böylece ele alınabilir. Veriler harika, ancak kod olmadan analiz etmek ve ondan yararlı bilgiler almak imkansız olurdu.

Bir e-ticaret sisteminde, "roket" ile sınıf düzeyinde ilgilenmez, "ürünler" ile ilgilenirsiniz. Bu, neyi başarmaya çalıştığınıza ve istediğiniz soyutlama seviyesine bağlıdır.

Bir oyunda, roketlerin yalnızca birçok "hareketli nesne" türünden biri olduğu söylenebilir. Aynı fizik diğer tüm hareketli cisimler için de geçerlidir. Bu yüzden en azından "roket" bazı daha genel "hareketli nesneler" temel sınıflarından miras alacak.

Her durumda, alıntı yaptığınız pasajın yazarı davasını biraz abartmış görünüyor. Roketler hala "kalan yakıt miktarı" ve "itme" gibi benzersiz özelliklere sahip olabilir ve bunu yüz roket için temsil etmek için yüz sınıfa ihtiyacınız yok, sadece bir taneye ihtiyacınız var. Nesne oluşturma, en iyi programlama dillerinde oldukça düşük maliyetlidir, bu nedenle roket benzeri şeyleri izlemeniz gerekiyorsa, Roket nesneleri yapmamanız gerektiği kavramı çok pahalı olabilir çünkü çok pahalı olabilir.

Gerçek dünyadaki sorun o lanet olası fizik. Gerçek dünyadaki şeyleri fiziksel nesnelere ayırıyoruz, çünkü bireysel atomlara göre hareket etmeleri daha kolay, ya da potansiyel olarak roket olabilecek dev bir erimiş cüruf.

Aynı şekilde, gerçek dünya, güvendiğimiz çok sayıda yararlı özellik sunar. Penguen istisnalarını yapmak gerçekten çok kolay - "tüm kuşlar uçuyor, hariç ...". Ve şeyleri roket olarak etiketlemek gerçekten çok kolay, yani eğer penguene roket diyor ve onu yakıyorsam ... işe yaramıyor.

Öyleyse gerçek dünyadaki şeyleri nasıl ayırdığımızı kavramsal olarak bu kısıtlar altında işler . Kodları olan şeyleri yaparken , kesinlikle farklı olan bu kısıtlamalar altında çalışacak şeyleri ayırmalıyız .

Alternatif nedir?

Ağları düşünün. Bağlantı noktalarını ve telleri ve yönlendiricileri kod olarak modellemiyoruz. Bunun yerine ağ iletişimini bağlantı ve protokoller olarak soyutlarız. Bunu yapıyoruz çünkü gerçek dünyadaki uygulamadan bağımsız olarak faydalı bir soyutlama. Ve sadece kodda önemli olan yararlı kısıtlamalar koyar (örneğin: bağlantı açılıncaya kadar iletişim kuramazsınız) .

Yani evet, bazen gerçek dünya çalıştıktan sonra kod modelleme, ama bu bir tesadüf . İnsanlar OOP hakkında konuştuğunda, nesneler gerçek dünya nesneleri değildir. Okullar ve eğitmenlerin aksi halde söyledikleri on yıllarca süren bir trajedidir.

Alternatif, programlarınızın önem verdiği şeyleri modellemektir. Programınız roketlerle uğraşsa bile, a adında bir öğeye sahip olmanız gerekmeyebilir Rocket. Örneğin, bir LaunchPadvarlığa, bir LaunchSchedulevarlığa ve bir MassiveDeviceMovervarlığa sahip olabilirsiniz. Bütün bunların roket fırlatılmasına yardım etmesi gerçeği, roketleri kendiniz tuttuğunuz anlamına gelmez.

Buradaki sorunum yazarın "hatalı" bir programlama modeli sunması ancak onu "düzeltmenin" bir yolunu sunmaması. Belki de Rocket sınıfının analojisini açıyorum, ama bu yalanın arkasındaki mantığı gerçekten anlamak istiyorum. Alternatif nedir?

Asıl sorun bu, ama size geliştirici olarak kabul ediyorum, belki bu yardımcı olacaktır.

İlk olarak, yanlış anlamalar olarak bunların hiçbirini yalan olarak adlandırmam. Yalan söylemek sadece yutturmaca.

Biri Haklı, bazı yönlerden. Bunun için çok zaman harcamamayı tercih ederim, çünkü bu sorunun bir parçası değil. Ama özünde o haklı. Bunu "Laboratuarda çalışanlar gerçek hayatta işe yaramayabilir" olarak ifade edebilirim. Geliştiriciler, çoğu zaman "laboratuarda" çalışan ancak gerçek dünya uygulamalarında başarısız olan bir tasarıma sadık kalıyorlar.

Üç Kulağa biraz sabun geliyor, ama aslında yine doğru. Ancak bu, "ihtiyaçlarınızın etrafına kod yazmak, ihtiyaçlarınızı kodunuza uymaya çalışma" şeklinde yeniden yazılabilir.

İki Yine, burada haklı. Geliştiricilerin, basit bir "araç" sınıfı işe yarayacak, hatta daha basit, "hareketli" bir sınıf çalıştığında "roket" sınıfı geliştirmek için haftalar veya daha uzun zaman harcadıklarını gördüm. Tüm roketinizin yapması gereken ekranın solundan sağa doğru hareket etmek ve bir ses çıkarmaksa, otomobiller, trenler, tekneler ve sinekler için yaptığınız aynı sınıfı kullanabilirsiniz. 100, 1 * 100 argümanının daha az maliyetli olması gerektiğini düşünerek zaman harcamakta ve hesaplama maliyetlerinde fazla olmamaktadır. Yeniden kullanılmasının daha az genel sınıfa yapışması "daha ucuz" olmasına rağmen, tekrar kullanılamayan birçok özel sınıfa sahiptir. Bu muhtemelen "genel sınıflar belirli sınıflardan daha iyidir," diye yazılabilir.

Temelde, makalenin tamamı, daha az sayıda buzzwords ile yeniden yazılabilir ve yalnızca en iyi şekilde bir paragraf olurdu. Bu, dar bir programlama alanına odaklanan bir blog yazısı olduğunu söyledi. Gömülü bir programlama yaptım ve bu ifadelerin ardındaki genel fikirle aynı fikirdeyim, ancak GDC'de bir sunuma uygun hale getirmek için etraflarında oldukça fazla "kabartmalar" var.

Son bir not, makale 2008'de yazıldı (en iyi söyleyebileceğim). İşler çabuk değişiyor. İfadeler bugün doğrudur, ancak gömülü sistemler o günden çok daha yaygındır ve gelişim kalıpları değişir. Belki bu yazıya / konuşmaya yanıt olarak bile.

Bunların akademik kaygılar etrafında toplandığını ilginç buluyorum: Platform, bellek kullanımının etkinliği ve veriler. Ama insan unsurunu tamamen görmezden geliyor.

Yazılım, insanların ihtiyaçlarını karşılamakla ilgilidir. Genelde bu, iş açısından ölçülür - bir şey isteyen müşteriler ve gerçekleşmesi için para ödemeye razı olan destekçileri vardır. Yazılım, denklemin her iki tarafının ihtiyaçlarını karşılayacak şekilde yazılıyorsa, o zaman iyi bir yazılımdır, değilse de kötü bir yazılımdır.

Platform müşteri için önemli değilse, platform önemli değildir. Bellek verimliliği müşteri için önemli değilse, o zaman önemli değildir. Veriler müşteri için önemli değilse, veriler önemli değildir. Kod çalışıyor ancak okunamıyor veya sürdürülemiyorsa ve müşteri uygun bir fiyatla hızlı ve güvenilir değişiklikler yapmak istiyorsa, kötü yazılmış kod kötü bir şeydir. Kod çalışıyor ancak okunamıyor veya bakımı yapılamıyorsa ve müşteri pahalı refaktörler için umursamıyor veya ödemeye istekliyse, kötü yazılmış kod iyi bir şeydir.

Büyük yalan, insan unsurunun önemi dışında her şeyin olmasıdır. Veriler neden önemlidir? Çünkü olması gereken bazı müşteri veya paydaş var. Bu "büyük gerçek" dir.

IMHO Kod "dünyanın bir modeli etrafında tasarlandı" ise, hem tasarımcılar hem de geliştiriciler için ve bakımcılar için anlaşılması kolaydır. Ama bence sadece ben değil, sadece yazılım değil. Wikipedia'dan: Bilimsel modelleme, amacı dünyanın belirli bir bölümünü veya özelliğini, var olan ve genellikle yaygın olarak kabul edilen bilgilere yönlendirerek anlamayı, tanımlamayı, ölçmeyi, görselleştirmeyi veya simüle etmeyi kolaylaştırmaktır.