Bir yapılandırma dosyası hangi noktada programlama dili haline gelir?

Bir süredir yapılandırma dosyaları ve bunların kodla ilişkileri üzerine kafa yoruyorum ve rüzgarın gününe ve yönüne bağlı olarak görüşlerim değişiyor gibi görünüyor. Her ne kadar Lisp'i öğrenirken ilk farkına vardığım gerçeğe gittikçe daha fazla geri dönmeme rağmen: veri ve kod arasında çok az fark var. Bu, yapılandırma dosyaları için iki kat daha doğru görünüyor. Doğru ışıkta bakıldığında Perl betiği, perl için bir yapılandırma dosyasından biraz daha fazlasıdır. Bu, yapılandırma dosyalarını değiştirmekten kimin sorumlu olması gerektiği gibi QA ve iş bölümü gibi görevler için oldukça ağır sonuçlara sahip olma eğilimindedir.

Yapılandırma dosyasından tam teşekküllü dile geçiş genellikle yavaştır ve genel bir sisteme sahip olma arzusundan kaynaklanıyor gibi görünmektedir. Çoğu proje, günlüklerin nereye yazılacağı, verilerin nerede aranacağı, kullanıcı adları ve şifreleri vb. Gibi birkaç yapılandırma öğesiyle küçük başlıyor gibi görünüyor. işlemlerin zamanlamaları ve sırası kontrol edilmeye başlar ve kaçınılmaz olarak birisi ona mantık eklemeye başlamak ister (örneğin, makine X ise 10 ve makine Y ise 15 kullanın). Belirli bir noktada, yapılandırma dosyası alana özgü bir dil haline gelir ve bunda kötü yazılmış bir dil olur.

Şimdi sahneyi hazırlamaya başladığıma göre, işte sorularım:

1. Bir yapılandırma dosyasının gerçek amacı nedir?
2. Yapılandırma dosyalarını basit tutmak için bir girişimde bulunulmalı mı?
3. Bunlarda değişiklik yapmaktan kim sorumlu olmalıdır (geliştiriciler, kullanıcılar, yöneticiler vb.)?
4. Kaynak kontrollü olmalı mı (bkz. Soru 3)?

Daha önce de söylediğim gibi, bu sorulara verdiğim yanıtlar sürekli değişiyor, ancak şu anda düşünüyorum:

1. programcı olmayanların büyük davranış parçalarını hızla değiştirmesine izin vermek
2. evet, kaba taneli olmayan her şey kodda olmalıdır
3. kullanıcılar yapılandırma dosyalarından sorumlu olmalı ve programcılar, yapılandırma dosyaları ile uygulamanın daha ayrıntılı denetimini sağlayan kod arasındaki bir yapılandırma katmanından sorumlu olmalıdır.
4. hayır, ancak daha ince taneli orta katman

Çok ilginç sorular!

Yapılandırma dosyalarımı çok basit bir "anahtar = değer" biçimiyle sınırlama eğilimindeyim, çünkü yapılandırma dosyalarının çok hızlı bir şekilde tam gelişmiş programlar haline gelebileceğine tamamen katılıyorum. Örneğin, OpenSER'ı "yapılandırmayı" deneyen herkes, bahsettiğiniz duyguyu bilir: bu yapılandırma değil, (acı veren) programlama.

Uygulamanızın bugün hayal edemeyeceğiniz şekillerde son derece "yapılandırılabilir" olmasına ihtiyacınız olduğunda, gerçekten ihtiyacınız olan şey bir eklenti sistemidir . Uygulamanızı, başka birinin yeni bir eklentiyi kodlayabileceği ve gelecekte uygulamanıza bağlayabileceği şekilde geliştirmeniz gerekir.

Öyleyse, sorularınızı cevaplamak için:

1. Bir yapılandırma dosyasının gerçek amacı nedir?

   Uygulamanızı kuracak kişilerin, ana bilgisayar adı, iş parçacığı sayısı, ihtiyacınız olan eklentilerin adları ve bu eklentiler için dağıtım parametreleri gibi dağıtımla ilgili bazı parametreleri tweetleyebilmesine izin vermek için söyleyebilirim (kontrol edin) Bu ilkenin bir örneği için FreeRadius yapılandırması), vb. Kesinlikle iş mantığını ifade edecek yer değil.

2. Yapılandırma dosyalarını basit tutmak için bir girişimde bulunulmalı mı?

   Kesinlikle. Önerdiğiniz gibi, bir yapılandırma dosyasında "programlama" korkunçtur. Bundan kaçınılması gerektiğine inanıyorum.

3. Bunlarda değişiklik yapmaktan kim sorumlu olmalıdır (geliştiriciler, kullanıcılar, yöneticiler vb.)?

   Genel olarak, uygulamayı dağıtan yöneticiler diyebilirim.

4. Kaynak kontrollü olmalı mı (bkz. Soru 3)?

   Genelde yapılandırma dosyalarının kendilerinin kaynak denetimini yapmıyorum , ancak bir şablon yapılandırma dosyasını tüm parametreler ve varsayılan değerleri ve ne yaptıklarını açıklayan yorumlarla birlikte kaynak-denetimi yapıyorum. Örneğin, bir yapılandırma dosyası adlandırılırsa database.conf, genellikle adlı bir dosyanın kaynağını kontrol ederim database.conf.template. Şimdi elbette geliştirici olarak ne yaptığımdan bahsediyorum . Bir yönetici olarak , her kurulum için seçtiğim gerçek ayarları kaynak-kontrol etmek isteyebilirim. Örneğin, birkaç yüz sunucuyu uzaktan yönetiyoruz ve yapılandırmalarını takip etmemiz gerekiyor: bunu kaynak denetimi ile yapmayı seçtik.

Düzenle: Yukarıdakilerin çoğu uygulama için doğru olduğuna inanmama rağmen, elbette her zaman istisnalar vardır. Uygulamanız, örneğin, kullanıcılarının karmaşık kuralları dinamik olarak yapılandırmasına izin verebilir. Çoğu e-posta istemcisi, kullanıcıların e-postalarının yönetimi için kurallar tanımlamasına izin verir (örneğin, "'john doe'den gelen ve Kime: alanında beni içermeyen tüm e-postalar atılmalıdır"). Diğer bir örnek, kullanıcının yeni bir karmaşık ticari teklif tanımlamasına izin veren bir uygulamadır. Ayrıca, kullanıcılarının karmaşık veritabanı raporları oluşturmasına olanak tanıyan Cognos gibi uygulamaları da düşünebilirsiniz. E-posta istemcisi, muhtemelen kullanıcıya kuralları tanımlamak için basit bir arayüz sunacaktır ve bu, karmaşık bir yapılandırma dosyası (veya belki de biraz kod) oluşturacaktır. Diğer yandan, ticari teklifler için kullanıcı tanımlı konfigürasyon, yapılandırılmış bir şekilde bir veri tabanına kaydedilebilir (ne basit bir anahtar = değer yapısı ne de kodun bir bölümü). Ve diğer bazı uygulamalar, kullanıcının python veya VB veya başka bir otomasyon özellikli dilde kod yazmasına bile izin verebilir. Başka bir deyişle ... kilometreniz değişebilir.

Tamam. Gerçekten basit bir yapılandırma isteyen bazı kullanıcılarınız olacak, onlara vermelisiniz. Aynı zamanda, sürekli "Bunu ekleyebilir misin? Yapılandırma dosyasında nasıl yaparım?" Gibi istekleriniz olacak, neden her iki grubu da destekleyemediğinizi anlamıyorum.

Şu anda üzerinde çalıştığım proje, yapılandırma dosyası için Lua'yı kullanıyor. Lua bir betik dilidir ve bu senaryoda oldukça iyi çalışır. Varsayılan konfigürasyonumuzun bir örneği var .

Bunun esas olarak anahtar = değer ifadeleri olduğunu not edeceksiniz, burada değer Lua'nın yerleşik türlerinden herhangi biri olabilir. En karmaşık şey listelerdir ve gerçekten karmaşık değildirler (bu sadece bir sözdizimi meselesidir).

Şimdi birisinin sunucusunun bağlantı noktasını her başlattığında rastgele bir değere nasıl ayarlayacağını sormasını bekliyorum ...

Geçenlerde bir proje üzerinde çalışıyordum ve konfigürasyon dosyamın içinde koşullara sahip olmak istediğimi fark ettim - bu daha önce oldukça basitti:

key = val
key2 = val
name = `hostname`

Mini bir dil yazmak istemedim çünkü çok dikkatli yapmazsam, kullanışlı olacak esnekliğe izin veremezdim.

Bunun yerine iki formum olduğuna karar verdim:

1. Dosya "#!" İle başlamışsa ve çalıştırılabilirdi, çalıştırmanın sonucunu ayrıştırırdım.

2. Aksi takdirde olduğu gibi okurdum

Bu, artık insanların şuna benzeyen "yapılandırma dosyaları" yazmasına izin verebileceğim anlamına geliyor:

 #!/usr/bin/perl
if ( -x /bin/foo ) 
{
   print <<EOF;
foo=me
bar=you
EOF
}
else
{
   print <<EOF;
foo=bar
bar=foo
EOF
}

Bu şekilde, kullanıcı kullanmak isterse dinamik bir yapılandırma dosyasının gücünü ve kendi mini dilimi yazmak zorunda kalmamanın basitliğini elde ederim.

Her (yeterince uzun ömürlü) yapılandırma dosyası şeması sonunda bir programlama dili haline gelir. Tanımladığınız tüm etkiler nedeniyle, yapılandırma dosyası tasarımcısının bir programlama dili yazdığını fark etmesi ve buna göre plan yapması akıllıca olacaktır, aksi takdirde gelecekteki kullanıcılara kötü miras yükler.

Yapılandırma dosyaları hakkında farklı bir felsefem var. Bir uygulamanın nasıl çalıştırılması gerektiğine ilişkin veriler hala veridir ve bu nedenle koda değil bir veri deposuna aittir (IMO yapılandırma dosyası koddur). Son kullanıcıların verileri değiştirebilmesi gerekiyorsa, uygulama bunu yapmak için bir arayüz sağlamalıdır.

Yapılandırma dosyalarını yalnızca veri depolarına işaret etmek için kullanıyorum.

Neyin bir programlama dili olarak sayılacağını tanımlamak için hesaplama teorisine dönebilirsiniz. Konfigürasyon dosya formatınız Turing Complete ise, makul ölçüde bir programlama dili olarak sayılır. Bu tanıma göre, Sokoban seviyelerini tanımlayan bir dosya formatı bir programlama dili olarak sayılır ( buraya bakın ). Turing Complete'in altında, Regular Grammars ve Pushdown Automata gibi sayılabilecek başka karmaşıklık düzeyleri de vardır .

Buna bakmanın başka bir yolu da, birçok yapılandırma dosyasının yalnızca veri işaretleme yeteneğine sahip olduğu, oysa uygun bir programlama dilinin algoritmaları uygulayabilmesi gerektiğidir . Örneğin, JSON bir yapılandırma dosyası biçimidir, oysa ECMA Script bir programlama dilidir.

İşte düşüncelerim:

1. Bir uygulamanın çalışma zamanı davranışının kolayca değiştirilmesine izin vermek için. Bu, ihtiyaçlara bağlı olarak programcılar veya programcı olmayanlar tarafından yapılabilir. Bu, geliştirme sırasında olabilir, ancak genellikle yapılandırma dosyalarını bir programı herhangi bir noktada daha esnek hale getirmeye yardımcı olacak bir yol olarak görüyorum.

2. Evet. Çalışma zamanınızın farklı davranışlarını kontrol etmek için çeşitli seçeneklere ihtiyaç duyabileceğiniz kısıtlaması göz önüne alındığında, yapılandırma dosyalarının olabildiğince basit olması gerektiğini düşünüyorum. Yapılandırma ayarlarını gruplamayı ve mümkün olduğunca basitleştirmeyi tercih ediyorum.

3. Değişikliğin neye ve neden yapıldığına bağlıdır. Kullanıcılar değiştirecekse, onları ayrıntılardan gizlemek için bir ön uç yapılmalıdır. Aynı durum genellikle geliştirici olmayanlar için de geçerlidir.

4. Sıklıkla "varsayılan" yapılandırmayı kaynak kontrol ediyorum, ancak gerçek çalışma süresi için bunu sistem başına geçersiz kılmanın bir yolu var.

Yapılandırma dosyasına mantık eklemeye gelince - bundan kaçınırım. Yapılandırma dosyasını uygulamanızdaki mantık üzerinde açmanın daha iyi olacağını düşünüyorum. Yapılandırma dosyalarındaki davranış, benim deneyimlerime göre, sürdürülebilirlik ve anlayış eksikliğine yol açar. Yapılandırma dosyalarını olabildiğince basit tutmayı şiddetle tercih ederim.

Bu sorunun öncülüne katılma eğilimindeyim. Bunun olacağını erkenden tahmin ederek başımı belaya sokmaktan kaçınıyorum ve bu nedenle asla kendi yapılandırma sistemimi deviremiyorum.

• Ya işletim sistemlerinin yapılandırma olanağını kullanıyorum (bir plist veya gconf gibi veya uygun olanı),
• Veya kullanıma hazır bir INI ayrıştırıcısı gibi bir şeyle ele alınabilecek basit bir düz dosya.
• Mermiyi ısır ve uygulamaya hafif bir dil ayrıştırıcısı, genellikle lua, bazen tcl takın,
• Veya verileri bir SQLite veya benzer ilişkisel veritabanında depolayın.

Ve verdiğim karar ne olursa olsun yaşamaya istifa ediyorum ya da yapamıyorsam, yukarıdaki seçeneklerden uygulamaya daha uygun olanı kullanmak için yeniden düzenleme yapıyorum.

Mesele şu ki, evde yetiştirilen bir yapılandırma çözümünü kullanmak için gerçekten bir neden yok. Birincisi, kullanıcılarınızın yeni, uygulamaya özel bir yapılandırma formatı öğrenmesi zor. Bir diğeri için, kullanıma hazır bir çözüm kullanırken ücretsiz olarak gelen tüm hata düzeltmelerinden ve güncellemelerden faydalanırsınız. Son olarak, Özellik sürünmesi dinlenmeye bırakıldı, çünkü aslında büyük bir revizyon yapmadan bir özellik daha ekleyemezsiniz çünkü yapılandırma sistemi ilk etapta gerçekten sizin elinizde değildir.

Takımdaki diğer geliştiricilerle ne kabul ettiğinize bağlıdır. Yapılandırma dosyalarını aynı yapılandırma dosyaları olarak mı kullanıyorsunuz yoksa Model Driven uygulaması mı oluşturuyorsunuz?

Yapılandırma dosyasının bir programlama dili haline gelmesinin belirtileri:

• isim = değer çiftleri birbirine bağlı olmaya başlar
• akış kontrolüne sahip olma ihtiyacı hissediyorsunuz (örn. eğer (bu) bundan daha fazlası )
• Daha fazla geliştirme yapmak için (sadece uygulamayı kullanmak yerine) yapılandırma dosyası için dokümantasyon gerekli hale gelir
• Yapılandırmadaki değer okunmadan önce bir bağlama sahip olması gerekir (yani değerler yapılandırma dosyasının kendisine harici bir şeye bağlıdır)

Yapılandırma dosyaları her zaman çirkin, mantıksız "tam teşekküllü programlama dilleri" olma yolunda ilerlemektedir. İyi programlama dilleri tasarlamak sanat ve beceri gerektirir ve programlama diline dönüşen yapılandırma dilleri korkunç olma eğilimindedir.

İyi bir yaklaşım, güzel tasarlanmış bir dil, örneğin python veya ruby ​​kullanmak ve yapılandırmanız için bir DSL oluşturmak için kullanmaktır. Bu şekilde konfigürasyon diliniz yüzeyde basit kalabilir, ancak aslında tam teşekküllü programlama dili olabilir.

"Akıcı arayüzlere" geçiş düşünüldüğünde sorunuzun çok alakalı olduğuna inanıyorum. Birçok geliştirici XML ile yapılandırılmış uygulamalara göre "ışığı gördü". XML kullanmak çok ayrıntılı ve doğru şekilde düzenlemek zor olabilir (özellikle şema sağlanmadıysa). Akıcı bir arayüze sahip olmak, geliştiricinin düz metin yapılandırma dosyasından (veya belki de komut satırı parametrelerinden) bazı anahtar-değer çiftlerinin yardımıyla uygulamayı alana özgü bir dilde yapılandırmasına olanak tanır. Ayrıca, test veya her neyse, uygulamanın yeni örneklerini kurmayı ve yapılandırmayı çok kolaylaştırır.

İşte sorunuza cevaplarım:

• Bir yapılandırma dosyasının gerçek amacı nedir?

Yapılandırma dosyası, kullanıcının programının çalışma zamanında davranışını özelleştirmesine olanak tanımanın bir yoludur.

• Yapılandırma dosyalarını basit tutmak için bir girişimde bulunulmalı mı?

İdeal olarak, yapılandırma dosyalarının programı yapılandırmak için en azından akıcı bir arayüzle desteklenmesi gerektiğini düşünürdüm (bu birçok açıdan yararlıdır). Bir yapılandırma dosyasına ihtiyacınız varsa, o zaman çok basit tutulmalıdır, anahtar-değer çiftlerinden başka bir şey olmamalıdır.

• Bunlarda değişiklik yapmaktan kim sorumlu olmalıdır (geliştiriciler, kullanıcılar, yöneticiler vb.)?

Bunun cevabının organizasyonunuza bağlı olduğunu düşünüyorum. Doğru şekilde yapılandırıldığından emin olmak, yazılımı dağıtan kişinin sorumluluğunda olmalıdır.

• Kaynak kontrollü olmalı mı (bkz. Soru 3)?

Bu cevabı bir başkasından çalacağım :) Kaynak kontrolünde bir şablon konfigürasyonu saklama ve her yerel kullanıcının ihtiyaçları için onu değiştirme fikrini seviyorum. Muhtemelen bir geliştiricinin yapılandırma dosyası başka bir geliştiricinin kabusu olduğundan, kullanıcıya göre değişen şeyleri kaynak kontrolü dışında bırakmak en iyisidir. Bir şablona sahip olmak, uygulamayı dağıtan kişinin (veya diğer geliştiricilerin) yapılandırma dosyası için tam olarak hangi değerlerin geçerli olduğunu görmesini sağlamanın güzel bir yoludur.

Yapılandırma dosyası nerede piton programlarını gördük olduğunu kodu. Özel bir şey yapmanız gerekmiyorsa (koşullu ifadeler vb.), Diğer yapılandırma stillerinden çok farklı görünmez. örneğin config.py, aşağıdaki gibi şeylerle bir dosya oluşturabilirim:

num_threads = 13
hostname = 'myhost'

INI dosyalarıyla karşılaştırıldığında kullanıcı üzerindeki tek yük, dizelerin etrafına '' koymaları gerektiğidir. Hiç şüphe yok ki aynı şeyi diğer tercüme edilmiş dillerde de yapabilirsiniz. Muhtemelen kullanıcılarınızı korkutma riski altında, gerekirse yapılandırma dosyanızı karmaşık hale getirme konusunda size sınırsız yetenek sağlar.

Evet, yapılandırma dosyaları basit olmalıdır. Kendi kendilerine hiçbir 'mantık' içermemelidirler - bunları, koşullu ifadelerin tamamını değil, if ifadelerindeki ifadelerin bir listesi olarak düşünün.

Kullanıcının uygulama içinde kodlanan seçeneklerden hangisinin kullanılması gerektiğine karar vermesine izin vermek için oradalar, bu yüzden onları karmaşık hale getirmeye çalışmayın, kendi kendine engel olur - sonunda basit yapılandırma dosyaları yazabilirsiniz. orijinal yapılandırma dosyasının başka türlü nasıl yapılandırılacağını kontrol etmek için!

Microsoft'taki "Oslo" çalışmasının amaçlarından biri, bu sorunun çözülmesine izin vermektir (gerekli olmasa da).

1. Bir uygulama, içerdiği yeni bileşenlerin modelleriyle birlikte gönderilir. Mevcut modelleri de kullanırdı. Örneğin, bir web hizmeti içerebilir, böylece bir web hizmetinin sistem modelini yeniden kullanabilir.
2. Modeller, araçlara metinsel veya grafiksel olarak erişmek için yeterli bilgi dahil olmak üzere onları tanımlayan meta verileri içerecektir.
3. Modellerin parçaları "konfigürasyona" karşılık gelecektir

Bu, bugünün yapılandırma dosyalarının eşdeğerinin, yapılandırmalarının hem metinsel hem de grafiksel düzenlemesini destekleyecek kadar zengin olabileceği anlamına gelir. Grafik araç, "Oslo" (kod adı "Quadrant") ile birlikte sağlanacaktır.

Karşı taraf olacağım ve bunun yalnızca XML ile temsil edilebilecek olandan daha fazlasını içerdiği zaman bir dil olduğunu sunacağım; veya XML bir dil olarak kabul edildiğinde.

Alternatif olarak, çoğu yapılandırma dosyası sınıflar olarak düşünülebilir, ancak yalnızca özelliklerle ve yöntemler olmadan. Yöntemler olmadan bunun bir dil olduğunu düşünmüyorum.

Sonuçta, "dil" hafif bir soyutlamadır, ancak evet, kenarlar belirsizdir.

Uygulamalarımızın kodu daha az önemli hale geliyor ... Komut dosyası var, sınıfların, yöntemlerin, yöntem argümanlarının ve özelliklerin davranışını tanımlayan her türlü öznitelik var. Kullanıcılar, veritabanı tetikleyicilerini ve veritabanı kısıtlamalarını tanımlayabilir. Çok karmaşık yapılandırma dosyaları olabilir. Bazen kullanıcı, girdi ve çıktıyı işlemek için XSLT stil sayfalarını tanımlayabilir çünkü sistemlerimizin açık olması gerekir (SOA). Ve BizzTalk gibi karmaşık konfigürasyon gerektiren şeyler de var. Kullanıcılar karmaşık iş akışlarını tanımlayabilir.

Bu karmaşık ortamla başa çıkmak için daha iyi kod yazmalıyız, böylece uygulamalarımızın kodu daha önemli hale gelir ...

Python programlarını, özellikle arka plan yordamları için yapılandırma dosyaları olarak kullanmanın büyük bir hayranıyım. "Konfigürasyon portu" haricinde daemon'u konfigürasyondan tamamen boşaltmayı seviyorum. Python programı daha sonra arka plan programına bağlanır ve arka planda çalışan nesneler oluşturmaya ve istenen yapılandırmayı oluşturmak için bunları birbirine bağlamaya devam eder. Her şey ayarlandıktan sonra, arka plan programı kendi başına çalışmaya bırakılabilir. Elbette faydaları, yapılandırma dosyalarınızı yazmak için tam teşekküllü bir programlama diline sahip olmanız ve zaten başka bir programdan arka plan programıyla konuşmanın bir yolunu bulduğunuzdan, hata ayıklama ve istatistik almak için kullanabilirsiniz. En büyük dezavantajı, herhangi bir zamanda gelen başka bir programdan gelen mesajlarla uğraşmaktır.

Yapılandırma dosyası : " Amacım nedir?"
Siz : "Yağı yapılandırın."
Yapılandırma dosyası : "Tamam ..."
Yapılandırma dosyası : " Amacım nedir?"
Siz : "Tereyağı yapılandırırsınız."
Yapılandırma dosyası : "Aman tanrım."

1. Bir yapılandırma dosyasının "gerçek amacı" yoktur. Uygulamanız için mantıklı olan şey budur. Genel olarak, makineler arasında farklılık gösteren (veya farklılık gösterebilecek) ve uygulamanızın ortasında değişmeyen şeyler muhtemelen bir yapılandırma dosyasında olmalıdır. Diğer hizmetler için varsayılanlar, bağlantı noktaları ve adreslerin hepsi harika adaylardır. Anahtarlar ve sırlar da harika adaylardır ancak güvenlik nedenleriyle normal yapılandırmanızdan ayrı olarak ele alınmalıdır. Bir yapılandırma dosyasının amacının hızlı değişikliklere izin vermek olduğuna katılmıyorum. Amaç, uygulamanızın kurulumunda esneklik sağlamak olmalıdır. Bir yapılandırma dosyası çok daha iyi, o esnekliği sağlamak için yol kolay hızlı ise - ancak gerektiği değil yapılandırma dosyalarınızı yönelecek gibi sık değişiyor gibi.

2. Evet ve hayır. Uygulamanızın kodunu basitleştirmeyi denemeli misiniz? Evet. Yazdığınız her şeyi basit ve isabetli hale getirmeye çalışmalısınız. Olması gerekenden daha karmaşık değil. Aynısı yapılandırmanız için de geçerlidir. Ancak, bu çok uygulamaya özeldir. Yapılandırmanızın "çok karmaşık" olmasına neden olacağı için yapılandırmada olması gerekenleri sabit kodlamak kötü bir tasarımdır. Aslında, "işleri basit tutmaya" çalışmak, yapılandırma dosyalarının büyük bir karmaşa haline gelmesinin nedenidir. Bazen en basit hareket modülerleştirmektir. Bu nedenle yapılandırma dosyalarınız iyi bilinen genel amaçlı bir programlama dilinde yazılmalıdır - kötü bir yapılandırma dili değil (okuyun: tüm "yapılandırma dilleri" berbat ).

3. Yine, yapılandırma dosyalarını kimin değiştirmesi gerektiği tamamen uygulamaya bağlıdır. Ancak miniquark ile aynı fikirdeyim, uygulamayı her kim dağıtırsa, konfigürasyondan sorumlu olmalıdır.

4. Kaynak, yapabileceğiniz her şeyi kontrol eder. Kaynak kontrolü harika. İşleri çok kolay bir şekilde geri alabilirsiniz ve yaptığınız değişikliklerin tam bir geçmişine ve bu değişiklikleri kimin yaptığına dair bir kaydına sahip olursunuz. Yani neden olmasın?