Izinkan saya mengajukan pertanyaan tandingan yang sangat serius: Apa, menurut Anda, perbedaan antara "data" dan "kode"?
Ketika saya mendengar kata "data", saya pikir "keadaan". Data, menurut definisi, adalah hal yang dirancang untuk dikelola oleh aplikasi itu sendiri, dan oleh karena itu, hal yang tidak pernah diketahui aplikasi pada saat kompilasi. Data hard-code tidak mungkin , karena segera setelah Anda membuat-kode data, itu menjadi perilaku - bukan data.
Jenis data bervariasi berdasarkan aplikasi; sistem faktur komersial dapat menyimpan pelanggan dan memesan informasi dalam database SQL, dan program vektor-grafik mungkin menyimpan data geometri dan metadata dalam file biner. Dalam kedua kasus ini dan semua yang ada di antaranya, ada pemisahan yang jelas dan tidak dapat dipecahkan antara kode dan data. Data itu milik pengguna , bukan programmer, jadi tidak akan pernah bisa dikodekan dengan keras.
Apa yang Anda bicarakan adalah, untuk menggunakan deskripsi yang paling akurat secara teknis tersedia untuk kosa kata saya saat ini: informasi yang mengatur perilaku program yang tidak ditulis dalam bahasa pemrograman utama yang digunakan untuk mengembangkan sebagian besar aplikasi.
Bahkan definisi ini, yang jauh lebih sedikit ambigu daripada hanya kata "data", memiliki beberapa masalah. Misalnya, bagaimana jika sebagian besar program masing-masing ditulis dalam bahasa yang berbeda? Saya secara pribadi telah mengerjakan beberapa proyek yaitu sekitar 50% C # dan 50% JavaScript. Apakah kode JavaScript "data"? Kebanyakan orang akan mengatakan tidak. Bagaimana dengan HTML, apakah itu "data"? Kebanyakan orang masih mengatakan tidak.
Bagaimana dengan CSS? Apakah itu data atau kode? Jika kita menganggap kode sebagai sesuatu yang mengontrol perilaku program, maka CSS tidak benar-benar kode, karena hanya (well, sebagian besar) yang mempengaruhi penampilan, bukan perilaku. Tapi itu juga bukan data; pengguna tidak memilikinya, aplikasi bahkan tidak benar-benar memilikinya. Ini setara dengan kode untuk perancang UI. Ini seperti kode , tetapi tidak cukup kode.
Saya mungkin menyebut CSS semacam konfigurasi, tetapi definisi yang lebih praktis adalah bahwa itu hanya kode dalam bahasa domain-spesifik . Itulah yang sering diwakili oleh XML, YAML, dan "file berformat" lainnya. Dan alasan kami menggunakan bahasa khusus-domain adalah bahwa, secara umum, secara bersamaan lebih ringkas dan lebih ekspresif dalam domain khusus daripada mengkodekan informasi yang sama dalam bahasa pemrograman tujuan umum seperti C atau C # atau Java.
Apakah Anda mengenali format berikut?
{
name: 'Jane Doe',
age: 27,
interests: ['cats', 'shoes']
}
Saya yakin kebanyakan orang melakukannya; itu JSON . Dan inilah hal yang menarik tentang JSON: Dalam JavaScript, ini jelas kode, dan dalam setiap bahasa lainnya, itu jelas diformat data. Hampir setiap bahasa pemrograman utama tunggal memiliki setidaknya satu perpustakaan untuk "parsing" JSON.
Jika kita menggunakan sintaks yang sama persis di dalam suatu fungsi dalam file JavaScript, itu tidak mungkin berupa apa pun selain kode. Namun, jika kita mengambil JSON itu, mendorongnya dalam .jsonfile, dan menguraikannya dalam aplikasi Java, tiba-tiba itu "data". Apakah itu masuk akal?
Saya berpendapat bahwa "data-ness" atau "konfigurasi-ness" atau "kode-ness" melekat pada apa yang sedang dijelaskan, bukan bagaimana itu dijelaskan.
Jika program Anda memerlukan kamus 1 juta kata untuk, katakanlah, menghasilkan frasa sandi acak, Anda ingin kode seperti ini:
var words = new List<string>();
words.Add("aa");
words.Add("aah");
words.Add("ahhed");
// snip 172836 more lines
words.Add("zyzzyva");
words.Add("zyzzyvas");
Atau apakah Anda hanya mendorong semua kata itu ke dalam file teks yang dibatasi baris dan memberi tahu program Anda untuk membacanya? Tidak masalah jika daftar kata tidak pernah berubah, ini bukan pertanyaan apakah Anda pengodean keras atau pengodean lunak (yang banyak dianggap sebagai anti-pola ketika diterapkan secara tidak tepat), itu hanya pertanyaan tentang format apa yang paling efisien dan membuatnya paling mudah untuk menggambarkan "barang", apa pun "barang" itu. Cukup tidak relevan apakah Anda menyebutnya kode atau data; ini adalah informasi yang diperlukan oleh program Anda untuk dapat dijalankan, dan format file-datar adalah cara yang paling nyaman untuk mengelola dan memeliharanya.
Dengan asumsi Anda mengikuti praktik yang benar, semua hal ini akan menjadi kontrol sumber, jadi Anda bisa menyebutnya kode, kode saja dalam format yang berbeda dan mungkin sangat minimalis. Atau Anda dapat menyebutnya konfigurasi, tetapi satu-satunya hal yang benar-benar membedakan kode dari konfigurasi adalah apakah Anda mendokumentasikannya dan memberi tahu pengguna akhir cara mengubahnya. Anda mungkin dapat menciptakan beberapa argumen palsu tentang konfigurasi yang ditafsirkan pada waktu startup atau runtime dan bukan pada waktu kompilasi, tetapi kemudian Anda akan mulai menggambarkan beberapa bahasa yang diketik secara dinamis dan hampir pasti apa saja dengan mesin skrip yang tertanam di dalamnya (misalnya kebanyakan game). Kode dan konfigurasi adalah apa pun yang Anda putuskan untuk diberi label, tidak lebih, tidak kurang.
Sekarang, ada adalah bahaya bagi eksternalisasi informasi yang tidak benar-benar aman untuk memodifikasi (lihat "coding lunak" link di atas). Jika Anda mengeksternalkan array vokal Anda dalam file konfigurasi, dan mendokumentasikannya sebagai file konfigurasi untuk pengguna akhir Anda, Anda memberi mereka cara yang hampir sangat mudah untuk langsung menghancurkan aplikasi Anda, misalnya dengan meletakkan "q" sebagai vokal. Tapi itu bukan masalah mendasar dengan "pemisahan kode dan data", itu hanya pengertian desain yang buruk.
Apa yang saya katakan kepada para junior devs adalah bahwa mereka harus selalu mengeksternalisasi pengaturan yang mereka harapkan berubah per lingkungan. Itu termasuk hal-hal seperti string koneksi, nama pengguna, kunci API, jalur direktori, dan sebagainya. Mereka mungkin sama di kotak dev Anda dan dalam produksi, tetapi mungkin tidak, dan sysadmin akan memutuskan bagaimana mereka ingin terlihat dalam produksi, bukan devs. Jadi Anda memerlukan cara agar satu kelompok pengaturan diterapkan pada beberapa mesin, dan pengaturan lain diterapkan pada mesin lain - ergo, file konfigurasi eksternal (atau pengaturan dalam database, dll.)
Tetapi saya menekankan bahwa hanya dengan meletakkan beberapa "data" ke dalam "file" tidak sama dengan mengeksternalkannya sebagai konfigurasi. Menempatkan kamus kata ke dalam file teks tidak berarti Anda ingin pengguna (atau TI) mengubahnya, itu hanya cara untuk memudahkan pengembang untuk memahami apa yang sedang terjadi dan, jika perlu, membuat perubahan sesekali. Demikian juga, memasukkan informasi yang sama dalam tabel database tidak selalu dianggap sebagai eksternalisasi perilaku, jika tabel tersebut hanya baca dan / atau DBA diperintahkan untuk tidak mengacaukannya. Konfigurasi menyiratkan bahwa data dapat berubah, tetapi pada kenyataannya yang ditentukan oleh proses dan tanggung jawab daripada pilihan format.
Jadi, untuk meringkas:
"Kode" bukan istilah yang didefinisikan secara kaku. Jika Anda memperluas definisi untuk memasukkan bahasa khusus domain dan hal lain yang memengaruhi perilaku, banyak gesekan nyata ini akan hilang begitu saja dan semuanya masuk akal. Anda dapat memiliki "kode" DSL yang tidak dikompilasi dalam file datar.
"Data" menyiratkan informasi yang dimiliki oleh pengguna atau setidaknya seseorang selain pengembang, dan umumnya tidak tersedia pada waktu desain. Itu tidak dapat dikodekan dengan keras bahkan jika Anda ingin melakukannya. Dengan kemungkinan pengecualian dari kode modifikasi diri , pemisahan antara kode dan data adalah masalah definisi, bukan preferensi pribadi.
"Soft-coding" bisa menjadi praktik yang mengerikan ketika diterapkan berlebihan, tetapi tidak setiap instance eksternalisasi harus merupakan soft-coding, dan banyak contoh menyimpan informasi dalam "flat file" tidak selalu merupakan upaya yang bonafid untuk eksternalisasi.
Konfigurasi adalah tipe khusus dari soft-coding yang adalah diperlukan karena pengetahuan bahwa aplikasi mungkin perlu untuk menjalankan dalam lingkungan yang berbeda. Menyebarkan file konfigurasi terpisah bersama dengan aplikasi jauh lebih sedikit bekerja (dan jauh lebih berbahaya) daripada menggunakan versi kode yang berbeda untuk setiap lingkungan. Jadi beberapa jenis soft-coding sebenarnya bermanfaat.