Size tamamen ciddi bir karşı soru sormama izin verin: Sizce "data" ve "code" arasındaki fark nedir?
"Veri" kelimesini duyduğumda "durum" olduğunu düşünüyorum. Veriler, tanım gereği, uygulamanın kendisinin yönetmek için tasarlandığı ve bu nedenle uygulamanın derleme zamanında asla bilmediği şeydir. Mümkün değilVeriyi kodlamak , çünkü kodladığınız anda onu davranış haline getirir - veri değil.
Veri tipi uygulamaya göre değişir; Ticari bir faturalandırma sistemi müşteri ve sipariş bilgilerini bir SQL veritabanında saklayabilir ve bir vektör grafik programı geometri verilerini ve meta verileri bir ikili dosyada depolayabilir. Hem bu durumlarda hem de aradaki her şeyde, kod ve veriler arasında açık ve kırılmaz bir ayrım vardır. Veriler kullanıcıya aittir. , programlayıcıya değil , bu nedenle asla kodlanmış olamaz.
Konuştuğum gibi görünüyor, şu anki sözlüğüm için mevcut olan teknik olarak doğru olan açıklamayı kullanmak: uygulamanın çoğunluğunu geliştirmek için kullanılan birincil programlama dilinde yazılmayan program davranışını yönetme.
Sadece "veri" kelimesinden çok daha az belirsiz olan bu tanımın bile birkaç sorunu var. Örneğin, programın önemli bölümlerinin her biri farklı dillerde yazılmışsa ne olur? Şahsen yaklaşık% 50 C # ve% 50 JavaScript olan birkaç projede çalıştım. JavaScript kodu "veri" mi? Çoğu insan hayır derdi. Peki ya HTML, bu "veri" mi? Çoğu insan hala hayır derdi.
Peki ya CSS? Bu veri mi yoksa kod mu? Eğer kodun program davranışını kontrol eden bir şey olduğunu düşünürsek, CSS gerçekten kod değildir, çünkü sadece (çoğunlukla, çoğunlukla) davranışı değil görünümü etkiler. Ancak bu da gerçekten veri değil; kullanıcı ona sahip değil, uygulama bile gerçekten sahip değil. Bir UI tasarımcısı için kodun karşılığı. Bu Kodunuzu var gibi oldukça kod değil.
CSS'ye bir çeşit konfigürasyon diyebilirim, ancak daha pratik bir tanım bunun sadece alana özgü bir dilde kodlanmasıdır. . XML'inizin, YAML'nizin ve diğer "formatlanmış dosyalarınızın" sıklıkla temsil ettiği şey budur. Etki alanına özgü bir dili kullanmamızın nedeni, genel olarak konuşursak, aynı bilgiyi aynı alanda, aynı bilgiyi C veya C # veya Java gibi genel amaçlı bir programlama dilinde kodlamaktan daha özlü ve daha ifade edici olmasıdır.
Aşağıdaki formatı tanıyor musunuz?
{
name: 'Jane Doe',
age: 27,
interests: ['cats', 'shoes']
}
Eminim çoğu insan yapar; öyle JSON . Ve işte JSON hakkındaki ilginç şey: JavaScript’te açıkça kod var ve diğer her dilde de açıkça biçimlendirilmiş veri. Neredeyse her bir ana programlama dilinde JSON'u "ayrıştırmak" için en az bir kütüphane bulunur.
Bir JavaScript dosyasındaki bir fonksiyonun içinde aynı sözdizimini kullanırsak, koddan başka bir şey olamaz. Ve yine de, eğer bu JSON'u alırsak, bir .jsondosyaya sokar ve bir Java uygulamasında ayrıştırırsak, aniden "veri" olur. Bu gerçekten mantıklı geliyor mu?
Ben "veri-ness" veya "yapılandırma-ness" veya "kod-ness" 'in tanımlandığı şeylere özgü olduğunu , nasıl tanımlandığını değil .
Programınızın rastgele bir parola oluşturmak için, yani 1 milyon kelimelik bir sözlüğe ihtiyacı varsa, bu şekilde kodlamak ister misiniz:
var words = new List<string>();
words.Add("aa");
words.Add("aah");
words.Add("ahhed");
// snip 172836 more lines
words.Add("zyzzyva");
words.Add("zyzzyvas");
Yoksa tüm bu kelimeleri satır ayrılmış bir metin dosyasına sokup programınıza bundan okumalarını mı söylersiniz? Eğer kelime listesinin hiç değişmemesi gerçekten önemli değil, zor kodlama mı yoksa yumuşak kodlama mı (birçoğunun doğru kullanılmadığı zaman bir anti-pattern olarak kabul edilir) olup olmadığı değil. Hangi format en verimlidir ve "malzeme" ne olursa olsun, "malzeme" tanımlamasını kolaylaştırır. Kod veya veri olarak adlandırmanız oldukça önemli değil; Programınızın çalışması için gereken bilgidir ve düz dosya formatı onu yönetmenin ve sürdürmenin en kolay yoludur.
Doğru uygulamaları uyguladığınızı varsayarsak, tüm bu şeyler yine de kaynak kontrolüne giriyor, bu yüzden ona kod de diyebilirsiniz, sadece farklı ve belki de minimalist bir formatta kod. Veya buna konfigürasyon diyebilirsiniz, ancak kodu konfigürasyondan gerçekten ayıran tek şey, dokümante edip etmemeniz ve son kullanıcılara nasıl değiştireceklerini söylemenizdir. Konfigürasyonun başlangıçta veya çalışma zamanında yorumlanıp derleme zamanında yorumlanmaması konusunda sahte bir argüman icat etmiş olabilirsiniz, ancak o zaman dinamik olarak yazılmış birkaç dil ve içinde kesinlikle bir komut dosyası motoru bulunan herhangi bir şeyi tanımlamaya başlayacaksınız (örneğin; çoğu oyun). Kod ve konfigürasyon, bunları etiketlemeye karar verdiğiniz her şeydir, başka bir şey değil, daha az bir şey değil.
Şimdi, orada olduğu için bir tehlike dışsallaştırıcı aslında değiştirmek güvenli olmayan bilgiler (yukarıdaki "yumuşak kodlama" bağlantıya bakın). Ünlü dizinizi bir yapılandırma dosyasında dışsallaştırırsanız ve onu son kullanıcılarınız için bir yapılandırma dosyası olarak belgelerseniz, uygulamanızı anında kırmak için neredeyse kusursuz bir yol sunarsınız, örneğin "q" harfini bir sesli harf olarak koyarak. Ancak bu, "kod ve verilerin ayrıştırılması" ile ilgili temel bir sorun değil, sadece kötü bir tasarım anlayışı.
Küçük geliştiricilere söylediğim şey, daima ortam başına değişmeyi bekledikleri ayarları dışlamaları gerektiğidir. Bu, bağlantı dizeleri, kullanıcı adları, API anahtarları, dizin yolları ve benzerlerini içerir. Bunlar sizin dev kutunuzda ve üretimde aynı olabilir , ancak muhtemelen değil ve sistem yöneticileri, devlere değil, üretimde nasıl görünmelerini isteyeceklerine karar verecekler. Bu nedenle, bazı makinelerde bir ayar grubunun ve diğer makinelerde uygulanan diğer ayarların (ergo, harici yapılandırma dosyaları (veya bir veritabanındaki ayarlar vb.) Yapılması için bir yönteme ihtiyacınız vardır.
Ancak bazı "verileri" basit bir şekilde "dosyaya" yerleştirmenin, onu yapılandırmayla dışlamakla aynı olmadığını vurguluyorum. Bir sözcük sözlüğünü bir metin dosyasına koymak, kullanıcıların (veya BT'nin) değiştirmesini istemeniz anlamına gelmez, bu, geliştiricilerin neler olup bittiğini anlamalarını ve gerektiğinde yapmalarını kolaylaştırmanın bir yoludur. ara sıra değişiklikler. Aynı şekilde, aynı bilgiyi bir veritabanı tablosuna koymak, tablonun salt okunur olması ve / veya DBA'ların asla onunla oynamaması istenmemesi durumunda, davranışın dışlanması olarak sayılmaz. Yapılandırma, verilerin değişebilir olduğunu, ancak gerçekte biçim seçimi yerine süreç ve sorumluluklarla belirlenen gerçek olduğunu gösterir.
Yani, özetlemek gerekirse:
"Kod" katı bir tanımlanmış terim değildir. Tanımınızı etki alanına özgü diller ve davranışı etkileyen herhangi bir şey içerecek şekilde genişletirseniz, bu görünür sürtünmenin çoğu ortadan kalkacak ve hepsi mantıklı olacaktır. Derlenmemiş, DSL "kodunu" düz bir dosyada olabilirsiniz.
"Veri", kullanıcılara veya en azından geliştiricilerden başka birine ait olan ve tasarım zamanında genellikle bulunmayan bilgileri belirtir. Bunu yapmak isteseniz bile kodlanmış olamaz. Kendini değiştiren kodun istisnası dışında, kod ile veri arasındaki ayrım kişisel bir tercih değil, bir tanım konusudur.
"Yumuşak kodlama" aşırı uygulandığı zaman korkunç bir uygulama olabilir, ancak dışsallaştırmanın her örneği zorunlu olarak yumuşak kodlama oluşturmaz ve bilgilerin "düz dosyalarda" saklanması çoğu kez dışsallaştırma için iyi niyetli bir girişim değildir.
Yapılandırma Soft-kodlama bunun özel bir türüdür olduğu , çünkü uygulama farklı ortamlarda çalışmasını gerekebileceğini bilginin gerekli. Uygulama ile birlikte ayrı bir yapılandırma dosyasını dağıtmak, kodun farklı bir sürümünü her ortama dağıtmaktan çok daha az iş (ve çok daha az tehlikeli) olur. Bu yüzden bazı yumuşak kodlama türleri gerçekten kullanışlıdır.