Kötü uygulama - ortamı ayarlamak için durum değiştir

Geliştirici olarak çalıştığım son üç yılda, insanların bir URL için yolu (hem arka uçta hem de ön uçta) belirlemek için bir switch ifadesini kullandığı birçok örnek gördüm. Aşağıda buna bir örnek verilmiştir:

Arka uç örneği (C #):

public static string getHost(EnvironmentEnum environment){
    var path = String.Empty;
    switch (environment)
    {
        case EnvironmentEnum.dev:
            path = "http://localhost:55793/";
            break;
        case EnvironmentEnum.uat:
            path = "http://dev.yourpath.com/";
            break;
        case EnvironmentEnum.production:
            path = "http://yourpath.com/";
            break;
    }
    return path;
}

Ön uç örneği (JavaScript):

(function () {
    if (window.location.host.indexOf("localhost") !== -1) {
        window.serviceUrl = "http://localhost:57939/";
    }
    else if (window.location.host.indexOf("qa") !== -1) {
        window.serviceUrl = "http://dev.yourpath.com/";
    }
    else {
        window.serviceUrl = "http://yourpath.com/";
    }
})();

İyi bir uygulama mı yoksa kötü bir uygulama mı olduğu tartışıldı ve bunun kötü bir uygulama olduğunu düşünüyorum, çünkü bu tür bir koddan kaçınmalı ve uygun bir yapılandırma ayarlamalıyız. Ancak dürüst olmak gerekirse, doğru cevabı gerçekten bilmiyorum ve neden tavsiye edilmiyor ve bunu uygulamanın doğru yolu nedir?

Birisi yukarıdaki uygulamanın artılarını ve eksilerini açıklayabilir mi?

Sizin için çalışan ve bakımı kolay olan kod, tanım gereği "iyi" dir. Asla birisini "iyi uygulama" fikrine uymak uğruna hiçbir şey değiştirmemelisiniz, eğer bu kişi kodunuzdaki sorunun ne olduğunu gösteremezse.

Bu durumda, en belirgin sorun, kaynakların uygulamanıza kodlanmış olmasıdır - dinamik olarak seçilmiş olsalar bile, hala kodlanmışlardır. Bu, uygulamanızı yeniden derlemeden / yeniden dağıtmadan bu kaynakları değiştiremeyeceğiniz anlamına gelir. Harici bir yapılandırma dosyasında, yalnızca bu dosyayı değiştirmeniz ve uygulamanızı yeniden başlatmanız / yeniden yüklemeniz gerekir.

Bunun bir problem olup olmadığı onunla ne yaptığınıza bağlıdır. Yine de her istekle otomatik olarak yeniden dağıtılan bir Javascript çerçevesinde, hiç sorun değil - değiştirilen değer, uygulamayı bir sonraki kullanışında her kullanıcıya yayılacaktır. Derlenmiş bir dilde şirket içi konuşlandırmanın erişilemez bir konumda olması gerçekten çok büyük bir sorundur. Uygulamayı yeniden yüklemek uzun sürebilir, çok paraya mal olabilir veya kullanılabilirliği korumak için gece yapılması gerekebilir.

Kodlanmış değerlerin bir sorun olup olmaması, durumunuzun ilk örnek gibi mi yoksa ikinci örnek gibi mi olduğuna bağlıdır.

Bunun kötü bir uygulama olduğunu düşünmekte kesinlikle haklısın. Bunu üretim kodunda gördüm ve seni ısırmaya her zaman geri döndü.

Başka bir ortam eklemek istediğinizde ne olur? Veya geliştirme sunucunuzu değiştirin? Yoksa farklı bir yere mi gideceksin? Yapılandırmanız doğrudan koda bağlı olduğu için yapamazsınız.

Yapılandırma kodun dışına ve çevreye zorlanmalıdır. On İki Faktörlü Uygulamanın ( http://12factor.net/config ) bir prensibidir , ancak herhangi bir uygulama için iyi bir uygulamadır. Ortam değişkenlerinin durumunuza uygun olmadığını görebilirsiniz, bu durumda bu yapılandırmayı bir yapılandırma dosyası veritabanında (ancak kontrol edilmemiş) bir kodda saklamayı öneririm.

Birincisi (diğerlerinin dediği gibi) bu kötü bir fikir çünkü uygulama ayrıntılarını kodunuza bağlıyorsunuz. Bu, şeyleri değiştirmeyi zorlaştırır.

Bu cevapta belirtildiği gibi , şimdi yeni bir ortam eklemek istiyorsanız , programınızı yeni bir ortama eklemek yerine, kodunuzu her yerde güncellemeniz gerekir .

Javascript kodunuzda bunu yapmanın başka ciddi bir kusuru var: Şirketinizin içini potansiyel saldırganlara maruz bırakıyorsunuz. Elbette, bir güvenlik duvarının arkasında olabilirsiniz, ancak yine de hoşnutsuz bir çalışanınız veya virüs bulaşmasına izin veren biri olabilir.

Kötü haber ayılar.

Yapılacak en iyi şey, konfigürasyonunuzu ortamdan ayarlamaktır (daha önce bağlanmış olan cevaplarda olduğu gibi, On İki Faktör Uygulaması'nın konuyla ilgili harika tavsiyeleri vardır). Dilinize bağlı olarak bunu yapmanın birkaç yolu vardır. En kolay yöntemlerden biri (genellikle) yalnızca ortam değişkenlerini ayarlamaktır. Ardından, nereye çalıştığınıza bağlı olarak değişkenleri değiştirirsiniz - yerel bir kutu, qa veya prodüksiyon olup olmadığı. Diğer bir seçenek ise değerleri bir .inidosyada veya JSON'da saklamaktır . Yine bir başka alternatif, config değerlerinizi gerçek kod olarak saklamak olacaktır. Hangi dili veya ortamı kullandığınıza bağlı olarak, iyi bir fikir olabilir veya olmayabilir.

Ancak nihai amaç, bir kod tabanı seçmenize , desteklenen mimariye / bağlantıya sahip herhangi bir makineye düşürmenize ve kodu herhangi bir şekilde değiştirmeden çalıştırabilmenize izin vermektir .

Arka ucu kendi makinemde çalıştırmak istiyorsam, ancak 55793 numaralı bağlantı noktasında çalıştırmak istemiyorsam, örneğin bunları karşılaştırmak için aynı anda birden fazla sürüm çalıştırıyorsam? Uygulamayı arka uç bir makinede çalıştırmak, ancak diğerine erişmek istersem ne olur? Dördüncü bir ortam eklemek istersem ne olur? Diğerlerinin de belirttiği gibi, sadece temel konfigürasyonu değiştirmek için yeniden derlemelisiniz.

Açıkladığınız yaklaşım şu ana kadar ekibiniz için pratikte çalışmış olabilir, ancak bu çok sınırlayıcıdır. Bu yol gibi parametrelerin merkezi bir yapılandırma dosyasında keyfi olarak ayarlanmasına izin veren bir yapılandırma sistemi, yalnızca sabit seçenekler sunandan çok daha esnektir ve switch ifadesi yaklaşımında ne gibi avantajlar elde edersiniz? Yok!

Bu bir var KÖTÜ UYGULAMA .

Yazılım tasarımının temel bir prensibi: Programlarınızın içinde sabit konfigürasyon değerlerini kodlamayın. Bu, özellikle gelecekte değişme ihtimali makul olan her şey için geçerlidir.

Geliştirdiğiniz program kodu, QA testi, UAT ve üretim gibi herhangi bir ortama giren kodla aynı olmalıdır. Birisi daha sonra ortam değiştiği için yapılandırmayı değiştirmesi gerekiyorsa veya yeni bir ortamda kullanması gerekiyorsa, sorun değil. Ancak bunu yapmak için hiçbir zaman program kodunuza dokunmaları gerekmemelidir. Her ortam için farklı kod sürümlerine sahip olmamanız gerekir. Programınız test edildikten sonra değiştiyse, o sürümü test etmediniz. Herhangi bir yazılım mühendisine, herhangi bir yazılım kalite güvence uzmanına, herhangi bir BT proje yönetimi uzmanına, herhangi bir BT denetçisine danışın.

Biri testi başka bir sunucuya taşıyabilir. Birisi aynı zamanda bir kullanıcı eğitim ortamı ya da satış gösterileri için bir ortam istediğine karar verebilir. İdari yapılandırma için bir programcıya gitmeleri gerekmemeliydi.

Yazılım, sebepsiz olarak, beklenmeyen durumlarla başa çıkabilecek kadar esnek ve sağlam olmalıdır.

Dahası, yazılım basitçe yazılmamalı ancak şu anda sizin için en kolay görünüyor. Yazılım geliştirme maliyeti, kullanım ömrü boyunca yazılım bakım maliyetine kıyasla düşüktür. Ve bundan bir yıl sonra diyelim ki, bu kod üzerinde çalışan kişi olmayabilir. Belki daha yeşil meralara gittikten yıllar sonra, geride bıraktığınız pisliği toplamak zorunda olan bir sonraki zavallı aptal için ne bırakacağınızı düşünmelisiniz. Ya da yıllar sonra kodu alan kişi olabilir, o zaman yaptığınız şeye inanmayacaksınız.

Her şeyi elinizden geldiğince doğru şekilde kodlayın. Daha sonra sorun olma olasılığı daha düşüktür.