Bir sistem% 100 veri odaklı olabilir mi?

Yeni patronum bu proje üzerinde uzun yıllardır çalışıyor. Sadece birkaç haftadır burdaydım, ama bunun mümkün olduğundan emin değilim. “% 100 veri odaklı” bir sistem tasarlamak istiyor.

Dolayısıyla, yeterli veri girersek herhangi bir uygulamayı tanımlayabilir ve oluşturabiliriz. En azından kullanıcılar gibi bazı şeyleri kabul etmesini sağlamayı başardım ya da uygulamalar önceden tanımlanmış değerlere sahip olmalı, ancak sistemin yapısı, kullanıcı arayüzü ve veri olarak depolanan mantığı seviyor.

Bazı basit şeylerin demoları var ve temelde nesne yönelimli programlama ve temel şablon sistemlerinizin basit fikirlerini yeniden keşfetti, ancak genel olarak bu amacın gerçekten imkansız olabileceğini düşünüyorum.

Sistem ne kadar karmaşık olursa olsun, gerçek programlama yaptığınız zaman, verileri kullanarak mantığı nasıl tanımlayabileceğinizi bilmiyorum.

Teorik olarak bence bu, verileri yorumlayan şeyin, uygulamayı tanımlamak için tam turing olması gerektiğinin sona ermesidir; bu nedenle, sorunu sadece net bir fayda sağlamayarak bir seviyeye yükselttiniz.

Böyle bir% 100 Veri Driven Uygulaması mümkün mü?

Patronunuz bu yazıyı okumalıdır: Kötü Carma: “Vizyon” projesi, iç platform etkisi veya ikinci sistem etkisi hakkında uyarıcı bir hikaye.

Soyut, Özet

Bilgi Teknolojileri'nde (BT) çalışanlarımız hepimizin önemli bir şeyin doğru olmadığı bir projede bulunduk. Bunu biliyoruz, çoğu herkes biliyor, ama kimse soruna parmağını ikna edici bir şekilde sokamıyor.

Bu hikaye, şimdiye kadar karşılaştığım en muhteşem başarısızlık gibi bir BT projesi hakkında. Orta ölçekli bir BT departmanının tamamen işten çıkarılmasıyla sonuçlandı ve sonunda büyüyen bir şirketin büyüyen bir sektörde imha edilmesine yol açtı. "Upstart" olarak adlandırdığımız şirket, başarılı ve kârlı bir abonelik televizyonu işiydi.

Proje 1990'ların başında meydana geldi ve şimdi Müşteri İlişkileri Yönetimi veya CRM olarak adlandırılan şeye benzeyen, özel yapım bir sipariş girişi ve müşteri hizmetleri uygulamasıydı. Sistemin temel işlevselliği şunları içeriyordu:

• Sipariş girişi ve envanter
• Müşteri hizmetleri, yardım masası
• Genel muhasebe, alacak hesapları, faturalandırma ve ödenecek hesaplar

Uygulama "Vizyon" olarak adlandırıldı ve adı hem Upstart için resmi olarak belirtilen sözü verdi, hem de mimarına kendini utandırıyor. Uygulama, iş için gelecekteki değişiklikleri barındıracak kadar esnek olacak şekilde inşa edildiği için yenilikçiydi. Sadece işle ilgili gelecekteki herhangi bir değişiklik değil, kesinlikle işle ilgili herhangi bir değişiklik. Bu oldukça dikkate değer bir iddia oldu, ancak Vizyon şimdiye kadar yapılmış en son uygulama olarak tasarlanmıştı. Tamamen veri odaklı, sınırsız soyutlama sağlayarak ve o sırada en son teknolojiye sahip nesne yönelimli programlama tekniklerini kullanarak bu mutlak esnekliği elde etti .

Görev açısından kritik bir uygulama oluşturmak için tasarlanan bu tür birçok proje gibi, geliştirme çalışmaları da iki yıl kadar sürdü, başlangıçta tahmin edilenden bir yıl daha sürdü. Ancak bu kabul edilebilirdi, çünkü bu, sonsuza dek sürecek, gelecekteki gereksinimlere adapte olacak ve sınırsız Yatırım Getirisi (ROI) sağlayacak uygulamadı. Uygulama nihayet “canlı” hale geldiğinde, şirketteki hemen hemen herkes o kadar çok yatırım yapmıştı ki, kelimenin tam anlamıyla şirketin kaderi başarısına bağlı kaldı.

Bununla birlikte, toplam proje arızası durumunda, çokuluslu şirketlerin temel işini yürüten kritik iş uygulamalarına, İnternet balonu döneminde binlerce "dot-com" firması tarafından gösterilen hızlı filiz türünün lüksüne izin verilmemektedir. Vizyonun “yaşadığı” bir ay içinde, yapımında en fazla kazanılanların dışında bir başarısızlık olduğu açıkça görülüyordu.

Ayrıca bakınız

http://en.wikipedia.org/wiki/Inner-platform_effect

Cevap evet, tamamen veri odaklı bir sistem oluşturmak mümkün ve evet, bu genellikle çok kötü bir fikir.

Tamamen veri odaklı bir program, tüm mantık ve konfigürasyonun, başka bir bağlamda veri olarak kabul edilebilecek şekilde depolanan değerlerle ele alındığı programdır. 1980'lerde üretilen ve çok sayıda forma girilen, tablolarda depolanan ve raporlar yoluyla erişilebilen veri öğelerini kullanarak raporlar, formlar, tablolar ve mantık oluşturma yeteneği sağlayan birçok 4GL ürünü vardı. "Rakamlarla boya" gibi sistemlere atıfta bulunuyordum ama şimdi "iç sistem" etkisi olarak bilindiğini görüyorum. İyi isim.

Bu sistemleri yaratan insanlar yeni bir programlama dili oluşturmaya çalışıyor (bilseler de bilmeseler de). Becerileri olmadığından, bunu çok kötü yaparlar. JVM / CLR'nin bakış açısına göre, derlenmiş bir Java / C # programı sadece veridir. Bu durumda iyi yapıldı. Her iki durumda da, ne olursa olsun, dili kullanmak için programcılara ihtiyaç vardır.

Bu işi yapmanın, bildiğim özel bir yolu var. İhtiyacınız olan bileşenlerin her birinin iskeletini oluşturursunuz: form, rapor, tablo vb. Veri bileşenlerini ayarlayarak bu bileşenlerin çeşitli bölümlerini yapılandırmak için bir mekanizma sağlarsınız. Seçilmiş bir özellikler dizisi için kararları verir ve sisteme dondurursunuz ve özellikle bu özellikleri yapılandırma yeteneğini reddedersiniz.

Ayrıca, mantıksal işlemleri kodlama yeteneğine sahip bir dil de uygularsınız. Tavsiyem lua veya belki Python gibi mevcut bir dili kullanmak. Bu kodun parçalarını, mantıksal işlemlerin gerekli olduğu yere gömün.

Bunu yaparak, her formu, raporu, tabloyu vb. Uygulamak için gereken yazma miktarını önemli ölçüde azaltırsınız. Sistem veri güdümlü görünüyor, ancak sadece bir noktaya.

Bu noktada az önce yeni bir 4GL uyguladınız. Bunu başarılı bir şekilde yaparsanız, lütfen bana bildirin. Çoğu insan kasvetli değil. Başarınız için sizi ilk tebrik eden ben olacağım.

Bence temelde haklısın. Bir dil çalışma zamanı zaten tamamen esnek bir veri odaklı sistemdir. Bir veri parçasını (program) alır ve diğer veriler üzerinde nasıl davranması gerektiğini belirlemek için kullanır. Diğer programlar tarafından yeniden kullanım için kodu depolamak için çok kullanıcılı bir program bile içerebilir (dahil etme yolundan uygun kurulum yönetimine kadar).

Kabaca konuşulan bir "betik dili", bu kod girişinin insan tarafından okunabildiği bir dil çalışma zamanıdır. Bir derleyici, kullanıcı ve çalışma zamanı arasında fazladan bir adım atıyor. Malbolge ve APL gibi "şaka" dillerinin hiçbir şekilde insan tarafından okunmasına gerek yoktur. Ancak, her şey aynı seviyede ve insan tarafından okunabilir olan her şey, tüm potansiyel kullanıcıların okuma veya yazma becerisine sahip olduğu veya onları geliştirmesi beklenebileceği anlamına gelmiyor.

Normalde bir dil çalışma zamanını doğrudan son kullanıcılara maruz bırakmamanın iyi nedenleri vardır . Asıl esnekliğin kaldırılmasının rahatlığı arttırmasıdır.

Bir SO gönderisi yazmak istersem, sadece yazmak istiyorum. Bunun yerine çıktı almak için bir C ++ programı yazma becerisine sahibim, ancak normal bir metin kutusu yerine C ++ program düzenleyicisini gösteren bir web tarayıcısı kullanmıyorum. C ++ bilmeyen insanlar sadece tarayıcıyı kullanmakla kalmazlar, kullanmazlardı.

Bazı işletme parametrelerini yapılandırmak istersem, bunu Turing-complete bir özellik dili kullanarak yapmak istemiyorum, ve bunu yapsam bile , muhtemelen diğer işletme programlarında bu aynı işletme parametrelerini "sabit kodlama" dan ayırt edilemez değildir dil. Hala yazdığın şeyin ne anlama geldiğini anlamadığını düşünmen gerekiyor. Hala değişikliklerin doğru olduğunu test etmeniz gerekiyor. Olduğunu, yine de önemsiz olmayan ve birileri tarafından beklenen olmayan herhangi görevler için programlama beceri gereken mu yapılandırmak ( "kullanım") sizin için özel bir alt sistemi ( "Uygulama") hazırlanan programlama becerisine sahip.

Dolayısıyla,% 100 veriye dayalı bir sisteme girmek üzereyseniz, bu doğru verileri verilen her şeyi yapabilir, kendinize sormanız gereken iki sorum vardır:

1. Programlama dillerini icat etme işinde miyiz, yoksa öyle mi olmalıyız?
2. Yeni programlama dilimiz zaten sahip olduklarımızdan daha iyi (amaçlarımız için) olacak mı ve ihtiyaç duydukça destekleyip geliştirecek miyiz?

Bazen cevaplar evet ve bir çeşit alana özgü dil yazıyorsunuz. Ya da eğer Sun / Microsoft / Stroustrup / van Rossum / diğerleri ise gerçek bir genel amaçlı programlama dili. Bazen cevaplar hayırdır ve "iç platform" etkisine sahip olursunuz - çok çaba ve deneme yanılmasından sonra bir şeyle sonuçlanırsınız. Şanslıysanız, yazdığınız programlama dilinden sadece biraz daha düşüktür ve kullanımı kolaydır.

Bazı diller diğerlerinden daha zor veya daha kolaydır, özellikle de R gibi bir amaç için uzmanlaşmışlarsa, bazı kullanıcılar onları daha kolay bulacaklardır. Muhtemelen yapmayacağınız şey, genel uygulamaları programlamayı temel olarak kolaylaştırmaktır. Herhangi bir zamanda muhtemelen dünyada bunu yapma potansiyeli olan birkaç kişi / kuruluş vardır, ancak patronunuz / şirketiniz bunun sizi de içerip içermediğini dürüstçe düşünmelidir.

Lua bağlamalarını oyun motoruna maruz bırakmak için, oyunlarda sıklıkla kullanılan bir numara var. Bu, tasarımcıların nispeten kolay bir dilde programlamalarına olanak sağlar, ancak performans için veya motorun veya platformun belirli işlevlerine erişmek için gerekli olduğunda "gerçek" bir programlayıcıyı çalıştırmaya devam eder. Elde edilen Lua scriptleri, motor söz konusu olduğunda "veri" dir. Bunların hepsinin konfigürasyon verilerinin aksine "mantık" olarak adlandırdığınız şeyin pek çoğunu içermesine gerek yoktur ve çoğu zaman tüm komploları ve çevreyi hemen hemen tanımlarlar, ama tüm oyunu değil. Bu% 100 veri odaklı değildir ve kesinlikle% 100 hatasız değildir, ancak ilginç bir pratik uzlaşmadır.

Bunun amaç olduğu bir şirkette çalıştım. SQL snippet'leri veritabanı tablolarında depolandı, çalışma zamanında okundu ve çalıştırıldı. Performans, tahmin edebileceğiniz gibi berbattı ve böcekler sıktı. Ayrıca yığın izleri veya hayatı kolaylaştıran başka hiçbir şey olmadan hata ayıklamak imkansızdı.

"Veriye dayalı programlama", programcılar olarak ne yaptığımızı anlama konusundaki temel bir anlayış eksikliğinden kaynaklanmaktadır; Bir algoritma yapabilen herhangi bir veri , kullanıcı arayüzündeki iki fikri karıştırmayı (karışma?) bir şekilde yönetmeyi başarsanız bile, aslında "programlama" dır. Şimdi, bu iki fikri diğer yönden birleştiremeyeceğiniz anlamına gelmez, böylece tüm kod veridir; Homoconicity tarafından sağlanan ve makro sistemi tarafından sömürülen lisp arkasındaki öncül budur. Evet, bu kavramlar kulağa benzer geliyor, ancak uygulamadaki etkileri ve uygulamaları çok farklı.

Ayrıca, bu editoryalleştirici olabilir, ancak "tamamen veri odaklı" programlama isteyen karşılaştığım yerler gerçekten programcılarına değer vermiyor. Kodu bir maliyet merkezi, dış kaynaklı veya ihmal edilecek bir şey olarak düşünüyorlar.

Patronun bunu yazmanı istiyor demek istiyorsun:

[
  {
    "statement": "Assignment ",
    "variable": "App",
    "value": {
      "type": "Function",
      "arguments": [],
      "function-body": [
        {}
      ]
    }
  },
  {
    "statement": "Assignment",
    "variable": "App.prototype.action",
    "value": {
      "type": "Function",
      "arguments": [
        "data"
      ],
      "function-body": [
        {
          "statement": "Call",
          "function-name": "console.log",
          "arguments": [
            "data"
          ]
        }
      ]
    }
  }
]

Bunu üretmek için:

var App = function () {};
App.prototype.action = function ( data ) {
    console.log( data );
}

Birincisi JSON ve ikincisi JavaScript .

Clearification

Teorik olarak bence bu, verileri yorumlayan şeyin, uygulamayı tanımlamak için tam turing olması gerektiğinin sona ermesidir; bu nedenle, sorunu sadece net bir fayda sağlamayarak bir seviyeye yükselttiniz.

Böyle bir% 100 Veri Driven Uygulaması mümkün mü?

Burası daha yeni başladığım yer. Cevabımla asıl gönderi ile aynı fikirdeyim: Bu mümkün, ama haklısın, bu sorunu [bariz] yararı yok etmek için bir seviye daha yükseğe çıkaracak .

Herhangi bir web tarayıcısı uygulaması tahrik% 100 veriler olarak kabul edilebileceğini, sanırım, inandırıcı ileri sürülebilir ¹ .

Tabii ki, bu web üzerinde uygulamalar oluşturmak için daha kolay veya daha kolay yapmaz, aslında onları çok zorlaştırır.

Patronunuza, web tarayıcısını yeniden icat ettiğini ve sonunda oldukça karmaşık bir şey oluşturmak için JavaScript'i yeniden icat etmesi gerektiğini söyleyin.

¹ Peki, eklentileri görmezden gelirseniz, JavaScript ve HTML5 .

Evet. Bildiğim kadarıyla, güçlü bir programlama dili olarak adlandırılan ancak esasen bir kabuk olan Mathematica gibi bir sistem , patronunuzun beklediği gibi benzer bir düşünceye dayanıyor. Wolfram Mathematica , artık birçok hesaplama işleminin kolayca yapabileceği şekilde karmaşık hale geliyor.

Veri odaklı bir kavramdır. Eğer programcılar verileri basit bir şekilde manipüle edeceksek, verilerle oynamamız için kolay olan bir kabuğa ihtiyacımız var. Sözdizimine dayalı bir programlama dili öğrenmek hakkında konuşmaya başladığımızda, aslında uygulama arayüzünü ya da sadece kabuğunu öğrendiğimizi anlamaya çalışın. Eğer kabuğu anlarsak, programları sürebiliriz.

Sürülen% 100 veri gelince, derleyici veya tercüman kabuğu anlayabiliyorsa hesaplama sürülür. Veriler, kabuk veya arayüz ile aynı temel yapıya sahipse, veriler de derleyici veya tercüman tarafından çalıştırılabilir. Bence Mathematica , size neden evet cevabı verdiğimin iyi bir açıklaması.