Praktik buruk - alihkan kasing untuk mengatur lingkungan

32

Dalam tiga tahun terakhir saya bekerja sebagai pengembang, saya telah melihat banyak contoh di mana orang menggunakan pernyataan beralih untuk mengatur jalur (baik di back-end dan front-end) untuk URL. Di bawah ini adalah contohnya:

Contoh back-end (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;
}

Contoh front-end (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/";
    }
})();

Telah dibahas apakah itu praktik yang baik atau buruk, dan saya pikir itu adalah praktik yang buruk, karena kita harus menghindari kode semacam ini dan mengatur konfigurasi yang tepat. Tetapi sejujurnya saya benar-benar tidak tahu jawaban yang tepat dan mengapa itu tidak direkomendasikan dan apa cara yang benar untuk menerapkan ini.

dapatkah seseorang menjelaskan pro dan kontra dari praktik di atas?

— gon250
sumber

13

Baris ini saja tidak optimal. path = " yourpath.com "; Konfigurasi harus eksternal untuk kode.

— paparazzo

2

Dari perspektif tinjauan kode murni, a Dictionaryadalah cara yang jauh lebih bersih untuk mengkode ini dalam C #. Lihat ideone.com/45g5xO . Atau di JS gunakan objek yang sudah tua, lihat jsfiddle.net/1ouhovqq .

— Danny Beckett

4

apa yang terjadi jika nama perusahaan Anda berubah menjadi sesuatu yang mengandung "qa"?

— user253751

Ingat bahwa jika Anda menggunakan file konfigurasi, file tersebut harus dikontrol dalam kontrol kode sumber .... Apa pun Anda mungkin harus mengedit file konfigurasi beberapa kali sehari ketika Anda menyiapkan mesin uji baru. Saya masih berpikir file config adalah yang terbaik, tetapi Anda mungkin ingin terlebih dahulu mencari file yang bernama Environment berdasarkan sebelum melihat file config detaul.

— Ian,

1

Saya tidak berpikir Anda harus berkeliling menyebut hal-hal praktik buruk jika Anda tidak dapat menghitung mengapa Anda berpikir itu adalah praktik yang buruk

— Roy

81

Kode yang cocok untuk Anda dan mudah dipelihara adalah definisi "baik". Anda tidak boleh mengubah hal-hal hanya demi mematuhi gagasan seseorang tentang "praktik yang baik" jika orang itu tidak dapat menunjukkan apa masalahnya dengan kode Anda.

Dalam hal ini, masalah yang paling jelas adalah bahwa sumber daya dikodekan secara keras ke dalam aplikasi Anda - bahkan jika mereka dipilih secara dinamis, mereka masih dikodekan dengan keras. Ini berarti bahwa Anda tidak dapat mengubah sumber daya ini tanpa mengkompilasi ulang / mempekerjakan kembali aplikasi Anda. Dengan file konfigurasi eksternal, Anda hanya perlu mengubah file itu dan memulai ulang / memuat ulang aplikasi Anda.

Apakah itu masalah atau tidak tergantung pada apa yang Anda lakukan dengannya. Dalam kerangka Javascript yang secara otomatis didistribusikan kembali dengan setiap permintaan, itu tidak masalah sama sekali - nilai yang diubah akan menyebar ke setiap pengguna saat mereka menggunakan aplikasi berikutnya. Dengan penyebaran di tempat dalam bahasa yang dikompilasi di lokasi yang tidak dapat diakses, itu memang masalah yang sangat besar. Menginstal ulang aplikasi mungkin membutuhkan waktu lama, biaya banyak uang atau harus dilakukan pada malam hari untuk menjaga ketersediaan.

Nilai hard-coded atau tidak merupakan masalah tergantung pada apakah situasi Anda lebih seperti contoh pertama atau lebih seperti contoh kedua.

— Kilian Foth
sumber

15

Saya suka paragraf pertama Anda. Tentu, Anda menindaklanjutinya dengan ... menunjukkan apa masalahnya ... tetapi gagasan bahwa "ini buruk karena blog XYZ mengatakan demikian" adalah penyebab kode lebih buruk daripada yang sebenarnya mencegahnya.

— corsiKa

5

Para pemula harus diberikan prinsip-prinsip yang telah teruji oleh waktu untuk hidup, bukan hanya "jika itu berhasil untuk Anda, maka itu tidak apa-apa" relativisme. Saya kira saya tidak salah untuk mengatakan bahwa nilai-nilai lingkungan hard-coding adalah praktik yang benar-benar buruk di bawah cahaya apa pun.

— Tulains Córdova

3

@ jpmc26: Anda tentu saja mengasumsikan bahwa menyebarkan kode sisi server adalah non-sepele, dan juga bahwa ada beberapa proses terpisah di mana nilai-nilai konfigurasi dapat diperbarui dengan lebih sedikit overhead. Keduanya tidak selalu benar. Banyak toko memiliki sedikit overhead dalam proses penempatannya. Di sisi lain, sebenarnya ada beberapa toko di mana perubahan konfigurasi pada dasarnya memiliki overhead yang sama dengan menggunakan kode yang diubah. (Validasi, membutuhkan persetujuan dari sejumlah besar orang, dll). Masalah duplikasi jelas valid.

— Kevin Cathcart

2

Dengan pengaturan lingkungan yang dicampur dengan kode aplikasi Anda, Anda satu kesalahan logika - atau perubahan yang tidak terduga dalam lingkungan eksekusi - jauh dari memukul tes dari produksi, atau produksi dari tes, atau kombinasi tak terduga dan mungkin bencana lainnya. Mempertahankan sifat khusus lingkungan yang terpisah dari kode dalam C # umumnya sepele. Mengapa mengambil risiko yang tidak perlu?

— John M Gant

1

@ user61852 "Saya kira saya tidak salah mengatakan bahwa nilai-nilai lingkungan hard-coding benar-benar praktik buruk di bawah cahaya apa pun." mem-parsing ke "nilai-nilai lingkungan hard-coding selalu praktik buruk" Jika itu selalu praktik yang buruk, maka itu harus selalu mungkin untuk mengidentifikasi setidaknya satu masalah yang akan menyebabkan nilai-nilai lingkungan pengkodean keras.

— emory

14

Anda benar dalam berpikir ini adalah praktik yang buruk. Saya telah melihat ini dalam kode produksi, dan selalu kembali menggigit Anda.

Apa yang terjadi ketika Anda ingin menambahkan lingkungan lain? Atau ubah server pengembangan Anda? Atau Anda harus gagal ke lokasi yang berbeda? Anda tidak bisa karena konfigurasi Anda langsung terkait dengan kode.

Konfigurasi harus dipaksa keluar dari kode dan masuk ke lingkungan itu sendiri. Ini adalah prinsip dari Aplikasi Dua Belas-Faktor ( http://12factor.net/config ), tetapi ini adalah praktik yang baik untuk aplikasi apa pun. Anda mungkin menemukan bahwa variabel lingkungan tidak sesuai untuk situasi Anda, dalam hal ini saya sarankan melihat menyimpan konfigurasi itu dalam database file konfigurasi bersama (tetapi tidak diperiksa dengan) kode.

— mgw854
sumber

Jika Anda tidak melacak file konfigurasi, bagaimana Anda tahu jika file konfigurasi yang Anda miliki valid untuk versi perangkat lunak yang baru saja Anda periksa dari VCS Anda. (yaitu file konfigurasi yang tidak

— dilacak

Saya tidak setuju bahwa file konfigurasi yang tidak dilacak adalah proposisi yang sulit. Cara saya berurusan dengan ini sebelumnya adalah dua kali lipat: satu, biner untuk penyebaran juga mengandung Skema XML yang mendefinisikan konfigurasinya (sehingga Anda dapat memverifikasi bahwa file konfigurasi yang diberikan akan berfungsi). Kedua, file konfigurasi untuk setiap lingkungan disimpan dalam sistem kontrol dokumen dengan folder yang berbeda untuk masing-masing lingkungan. Hal serupa dapat dilakukan di Git dengan cabang - versi yang dikontrol, tetapi dibedakan dari kode yang kurang ramah lingkungan.

— mgw854

5

Untuk satu, (seperti yang telah disebutkan orang lain) ini adalah ide yang buruk karena Anda mengikat detail implementasi ke dalam kode Anda. Ini membuatnya sulit untuk mengubah banyak hal.

Seperti disebutkan dalam jawaban ini , jika Anda ingin menambahkan lingkungan baru sekarang Anda harus memperbarui kode Anda di mana-mana , alih-alih hanya menambahkan program Anda ke lingkungan baru.

Ada kesalahan serius lain dengan melakukan ini dalam kode Javascript Anda: Anda mengekspos internal perusahaan Anda kepada penyerang potensial. Tentu, Anda mungkin berada di belakang firewall, tetapi Anda mungkin masih memiliki karyawan yang tidak puas atau seseorang yang membiarkan virus masuk.

Berita buruk ditanggung.

Hal terbaik yang harus dilakukan adalah mengatur konfigurasi Anda dari lingkungan (seperti pada jawaban yang ditautkan sebelumnya, Twelve-Factor App memiliki saran hebat tentang topik ini). Ada beberapa cara untuk melakukan ini tergantung pada bahasa Anda. Salah satu yang termudah (biasanya) adalah hanya mengatur variabel lingkungan. Kemudian Anda hanya mengubah variabel tergantung di mana Anda menjalankan - apakah itu kotak dev, qa, atau produksi lokal. Opsi lain adalah menyimpan nilai-nilai dalam .inifile atau JSON. Alternatif lain adalah menyimpan nilai konfigurasi Anda sebagai kode aktual. Bergantung pada bahasa atau lingkungan apa yang Anda gunakan ini mungkin atau mungkin bukan ide yang baik.

Tetapi tujuan utamanya adalah membiarkan Anda mengambil satu basis kode, meletakkannya di mesin apa pun yang memiliki arsitektur / konektivitas yang didukung, dan dapat menjalankannya tanpa mengubah kode dengan cara apa pun.

— Wayne Werner
sumber

1

Bagaimana jika saya ingin menjalankan backend pada komputer saya sendiri tetapi tidak pada port 55793, misalnya jika saya menjalankan beberapa versi pada saat yang sama untuk membandingkannya? Bagaimana jika saya ingin menjalankan aplikasi backend pada satu mesin, tetapi mengaksesnya dari yang lain? Bagaimana jika saya ingin menambahkan lingkungan keempat? Seperti yang orang lain tunjukkan, Anda harus mengkompilasi ulang hanya untuk mengubah konfigurasi dasar.

Pendekatan yang telah Anda jelaskan mungkin telah berhasil dalam praktik untuk tim Anda sejauh ini, tetapi itu membatasi tanpa tujuan. Sistem konfigurasi yang memungkinkan parameter seperti jalur ini ditetapkan secara sewenang-wenang dalam file konfigurasi pusat jauh lebih fleksibel daripada yang hanya menyediakan opsi tetap, dan apa keuntungan yang Anda dapatkan dengan pendekatan pernyataan switch? Tidak ada!

— PeterAllenWebb
sumber

0

Ini PRAKTEK YANG BURUK .

Prinsip dasar desain perangkat lunak: Jangan nilai-nilai konfigurasi hard-code di dalam program Anda. Ini terutama berlaku untuk apa pun yang memiliki peluang yang wajar untuk berubah di masa depan.

Kode program yang Anda kembangkan harus kode yang sama yang masuk ke lingkungan apa pun seperti pengujian QA, UAT, dan produksi. Jika seseorang perlu mengubah konfigurasi nanti karena lingkungan telah berubah, atau mereka perlu menggunakannya di lingkungan baru, baiklah. Tetapi mereka tidak perlu menyentuh kode program Anda untuk melakukannya. Dan Anda seharusnya tidak memiliki versi kode yang berbeda untuk setiap lingkungan. Jika program Anda telah berubah sejak diuji, maka Anda belum menguji versi itu. Tanyakan insinyur perangkat lunak apa pun, profesional penjaminan kualitas perangkat lunak apa pun, profesional manajemen proyek TI, auditor TI apa pun.

Seseorang dapat memindahkan pengujian ke server lain. Seseorang mungkin memutuskan juga menginginkan lingkungan pelatihan pengguna, atau lingkungan untuk demonstrasi penjualan. Mereka tidak harus pergi ke programmer untuk konfigurasi administratif.

Perangkat lunak harus fleksibel dan cukup kuat untuk menangani situasi yang tidak terduga, masuk akal.

Selain itu, perangkat lunak tidak boleh ditulis tetapi sepertinya paling mudah untuk Anda saat ini. Biaya pengembangan perangkat lunak kecil dibandingkan dengan biaya pemeliharaan perangkat lunak selama masa pakainya. Dan katakanlah setahun dari sekarang, Anda mungkin bukan orang yang mengerjakan kode itu. Anda harus memikirkan apa yang Anda tinggalkan untuk orang bodoh miskin berikutnya yang harus mengambil kekacauan apa pun yang mungkin Anda tinggalkan, mungkin bertahun-tahun setelah Anda pergi ke padang rumput yang lebih hijau. Atau Anda mungkin orang yang mengambil kode bertahun-tahun kemudian, tidak percaya dengan apa yang Anda lakukan saat itu.

Kode hal-hal dengan benar, sebaik mungkin. Ini cenderung menjadi masalah nanti.

— WarrenT
sumber