Menghapus nilai-nilai hard-coded dan desain defensif vs YAGNI

Pertama, sedikit latar belakang. Saya sedang mengkode pencarian dari Usia -> Nilai. Ada 7 kurung umur sehingga tabel pencarian adalah 3 kolom (Dari | Ke | Tingkat) dengan 7 baris. Nilai-nilai jarang berubah - mereka adalah tingkat yang ditetapkan (kolom pertama dan ketiga) yang tetap sama selama 3 tahun. Saya menduga bahwa cara termudah untuk menyimpan tabel ini tanpa hard-coding adalah dalam database dalam tabel konfigurasi global, sebagai nilai teks tunggal yang mengandung CSV (jadi "65,69,0.05,70,70,74,0,06" adalah bagaimana tingkatan 65-69 dan 70-74 akan disimpan). Relatif mudah diurai lalu digunakan.

Kemudian saya menyadari bahwa untuk mengimplementasikan ini saya harus membuat tabel baru, repositori untuk membungkusnya, tes lapisan data untuk repo, tes unit di sekitar kode yang tidak mendatar CSV ke dalam tabel, dan tes di sekitar pencarian itu sendiri. Satu-satunya manfaat dari semua pekerjaan ini adalah menghindari pengkodean keras tabel pencarian.

Ketika berbicara dengan para pengguna (yang saat ini menggunakan tabel pencarian langsung - dengan melihat salinannya) pendapatnya cukup banyak bahwa "harga tidak pernah berubah." Jelas itu tidak benar-benar benar - tarif hanya dibuat tiga tahun lalu dan di masa lalu yang "tidak pernah berubah" memiliki kebiasaan berubah - jadi bagi saya untuk memprogram defensif ini saya pasti tidak seharusnya menyimpan tabel pencarian di aplikasi.

Kecuali ketika saya berpikir YAGNI . Fitur yang saya terapkan tidak menentukan bahwa tarif akan berubah. Jika tarif berubah, mereka masih akan berubah sangat jarang sehingga pemeliharaan bahkan tidak menjadi pertimbangan, dan fitur sebenarnya tidak cukup kritis sehingga apa pun akan terpengaruh jika ada penundaan antara perubahan tarif dan aplikasi yang diperbarui.

Saya sudah cukup banyak memutuskan bahwa tidak ada nilai yang akan hilang jika saya melakukan hard-code pencarian, dan saya tidak terlalu khawatir tentang pendekatan saya untuk fitur khusus ini. Pertanyaan saya adalah, sebagai seorang profesional, sudahkah saya membenarkan keputusan itu? Nilai-nilai hard-coding adalah desain yang buruk, tetapi pergi ke masalah menghapus nilai-nilai dari aplikasi tampaknya melanggar prinsip YAGNI.

EDIT Untuk mengklarifikasi pertanyaan, saya tidak khawatir tentang implementasi yang sebenarnya. Saya khawatir bahwa saya dapat melakukan hal yang cepat, buruk, dan membenarkannya dengan mengatakan YAGNI, atau saya dapat mengambil pendekatan yang lebih defensif, upaya yang tinggi, yang bahkan dalam kasus terbaik sekalipun pada akhirnya memiliki manfaat rendah. Sebagai seorang programmer profesional, apakah keputusan saya untuk mengimplementasikan suatu desain yang saya tahu cacat hanya sampai pada analisis biaya / manfaat?

EDIT Sementara semua jawaban itu sangat menarik karena saya pikir ini berkaitan dengan pilihan desain individu, saya pikir jawaban terbaiknya adalah @ Corbin dan @EZ Hart ketika mereka memunculkan hal-hal yang tidak saya pertimbangkan dalam pertanyaan:

• dikotomi yang salah dari 'menghapus nilai-nilai hard-coded dengan benar' dengan memindahkannya ke database vs 'secara efisien menerapkan YAGNI' dengan menggunakan hard-coding. Ada opsi ketiga menempatkan tabel pencarian ke dalam konfigurasi aplikasi, yang tidak menimbulkan overhead dengan cara yang benar, dan tanpa efisiensi YAGNI. Kami umumnya tidak terbatas pada salah satu atau keputusan, dan kemudian turun ke keputusan biaya / manfaat.
• pembuatan kode dapat mengurangi overhead memindahkan nilai-nilai hard-coded ke database, dan dengan cara yang juga menghilangkan keputusan over-engineered saya untuk memproses CSV ke dalam tabel. Berpotensi ini juga menambahkan masalah pemeliharaan jangka panjang dengan kode yang dihasilkan jika persyaratan dasar berubah untuk metode pencarian. Ini semua hanya mempengaruhi analisis biaya / manfaat, dan kemungkinan jika saya memiliki otomasi yang tersedia, saya bahkan tidak akan mempertimbangkan pengkodean keras seperti ini.

Saya menandai jawaban @ Corbin sebagai benar karena itu mengubah asumsi saya tentang biaya pengembangan, dan saya mungkin akan menambahkan beberapa alat penghasil kode ke gudang senjata saya dalam waktu dekat.

Anda menemukan kekurangan dalam proses pengembangan Anda. Ketika sulit untuk melakukan hal yang benar (membuat tabel, repo, tes repo, tes rata ...), pengembang akan menemukan cara mengatasinya. Ini biasanya melibatkan melakukan hal yang salah. Dalam hal ini, Anda tergoda untuk memperlakukan data aplikasi sebagai logika aplikasi. Jangan lakukan itu. Alih-alih, tambahkan otomatisasi yang bermanfaat ke proses pengembangan Anda. Kami menggunakan CodeSmith untuk menghasilkan kode boilerplate yang membosankan dan tidak seorang pun ingin menulis. Setelah kami membuat tabel, kami menjalankan CodeSmith dan menghasilkan DAO, DTO, dan berhenti tes unit untuk masing-masing.

Bergantung pada teknologi yang Anda gunakan, Anda harus memiliki opsi serupa. Banyak alat ORM akan menghasilkan model dari skema yang ada. Migrasi rel bekerja berlawanan arah - tabel dari model. Meta-programming dalam bahasa dinamis sangat kuat dalam menghilangkan kode boilerplate. Anda harus bekerja sedikit lebih keras untuk menghasilkan semua yang Anda butuhkan jika Anda memiliki aplikasi multi-tier yang kompleks, tetapi itu sepadan. Jangan biarkan perasaan, "wow, ini sakit di leher" menghentikan Anda melakukan hal yang benar.

Oh, dan jangan menyimpan data Anda dalam format yang membutuhkan pemrosesan tambahan (CSV). Itu hanya menambah langkah-langkah tambahan yang membutuhkan perhatian dan pengujian Anda.

Untuk membuka dan memperluas @ Thorbjørn Ravn Andersen jawaban: Menjaga perhitungan / pencarian di satu tempat adalah awal yang baik.

Proses pemikiran Anda defensif vs YAGNI adalah masalah umum. Dalam hal ini, saya akan menyarankan itu diinformasikan oleh dua hal lagi.

Pertama - bagaimana persyaratan pengguna disajikan? Apakah mereka menentukan tingkat yang dapat diedit? Jika tidak, apakah kompleksitas yang ditambahkan adalah bagian dari sesuatu yang dapat Anda bayar atau tidak? (atau jika Anda adalah staf, Anda dapat menghabiskan waktu melakukan pekerjaan lain sebagai gantinya?) Jika demikian, maka lanjutkan dan sampaikan apa yang diminta secara wajar.

Kedua, dan mungkin yang lebih penting, kemampuan mengedit belaka tidak mungkin memenuhi persyaratan aktual dalam menghadapi perubahan yang disahkan. Jika dan ketika tarif berubah, kemungkinan ada tanggal cut-over dan beberapa proses sebelum dan sesudah yang harus terjadi. Lebih jauh lagi jika antarmuka yang sama kemudian harus melakukan pemrosesan klaim tanggal kembali, maka nilai yang benar mungkin harus dicari berdasarkan tanggal efektif entri, bukan tanggal aktual.

Singkatnya, saya mencatat bahwa persyaratan yang dapat diedit yang sebenarnya mungkin cukup kompleks, jadi kecuali atau sebelum itu disempurnakan, yang sederhana kemungkinan lebih baik.

Semoga berhasil

Jadikan fungsi pencarian sebagai perpustakaan. Anda kemudian dapat melihat semua kode menggunakan pencarian itu di repositori sumber Anda, sehingga Anda tahu program mana yang perlu ditingkatkan ketika tarif berubah.

Biarkan saya melihat apakah saya menjawab pertanyaan Anda dengan benar. Anda memiliki 2 opsi untuk mengimplementasikan fitur: Anda memberikan nilai pada hardcode dan fitur Anda mudah diimplementasikan (tetapi Anda tidak menyukai bagian hardcode) atau Anda memiliki upaya yang sangat besar untuk "mengulang" banyak hal yang dilakukan sehingga Anda dapat mengembangkan fitur Anda dengan cara yang bersih. Apakah itu benar?

Hal pertama yang terlintas di benak saya adalah "Hal terpenting tentang mengetahui praktik yang baik adalah mengetahui kapan Anda lebih baik tanpanya".

Dalam hal ini, upayanya sangat tinggi sehingga Anda dapat melakukannya dengan cara yang bersih, kemungkinan efek jaminan dari perubahan ini besar dan pengembalian yang akan Anda peroleh kecil (seperti yang Anda jelaskan, sepertinya tidak akan perubahan).

Saya akan menggunakan pendekatan hardcode (tapi bersiaplah untuk menjadi fleksibel di masa depan), dan, jika terjadi perubahan tingkat ini di masa depan, gunakan kesempatan untuk memperbaiki semua bagian desain kode yang buruk ini. Jadi waktu dan biaya dapat diestimasi dengan benar dan biaya untuk mengubah nilai hardcode Anda menjadi minimal.

Ini akan menjadi pendekatan saya :)

Ini adalah item yang "tidak akan berubah" sampai item itu berubah. Tidak dapat dihindari bahwa itu akan berubah, tetapi waktu itu mungkin agak jauh.

Pembenaran Anda benar. Saat ini, pelanggan tidak meminta kemampuan untuk dengan mudah mengubah tarif tersebut. Karena itu, YAGNI.

Namun, yang tidak Anda inginkan adalah kode yang mengakses tarif Anda dan menginterpretasikan hasil yang tersebar di seluruh basis kode. Desain OO yang baik akan membuat Anda merangkum representasi internal harga Anda di kelas, dan hanya mengekspos satu atau dua metode yang diperlukan untuk menggunakan data.

Anda akan memerlukan enkapsulasi untuk mencegah kesalahan salin dan tempel, atau harus melakukan refactoring di semua kode yang menggunakan tarif ketika Anda perlu membuat perubahan ke representasi internal. Ketika Anda mengambil tindakan pencegahan awal, pendekatan yang lebih rumit bisa berupa pertukaran sederhana dan ganti untuk versi yang lebih banyak fitur.

Selain itu, sebutkan batasan desain saat ini untuk klien. Beri tahu mereka bahwa demi menjaga jadwal, Anda memberikan kode yang sulit kepada nilai - yang memerlukan perubahan kode untuk memperbaruinya. Dengan begitu, ketika mereka menyadari perubahan suku bunga yang tertunda karena undang-undang baru, mereka dapat memilih untuk hanya memperbarui tabel pencarian atau melakukan perubahan yang lebih rumit pada saat itu. Tapi taruh keputusan itu di pangkuan mereka.

Pisahkan perbedaan dan letakkan data kecepatan dalam pengaturan konfigurasi. Anda dapat menggunakan format CSV yang sudah Anda miliki, Anda menghindari overhead database yang tidak perlu, dan jika perubahan itu diperlukan, itu akan menjadi perubahan yang harus dapat dilakukan pelanggan tanpa harus mengkompilasi ulang / menginstal ulang dan tanpa mengacaukan sekitar dalam database - mereka hanya dapat mengedit file konfigurasi.

Biasanya ketika Anda melihat pilihan antara dua ekstrem (melanggar YAGNI vs data dinamis hard-coding), jawaban terbaik adalah di suatu tempat di tengah. Waspadalah terhadap dikotomi palsu.

Ini mengasumsikan semua konfigurasi Anda dalam file; jika ini suatu tempat yang sulit seperti registri, Anda mungkin harus mengabaikan saran ini :)

Saya menduga bahwa cara termudah untuk menyimpan tabel ini tanpa hard-coding adalah dalam database dalam tabel konfigurasi global, sebagai nilai teks tunggal yang mengandung CSV (jadi "65,69,0.05,70,70,74,0,06" adalah bagaimana tingkatan 65-69 dan 70-74 akan disimpan.

Baru saja membuat Tabel DB. (Anda berpikir untuk menyimpan seluruh meja dalam satu arsip, apakah Anda sudah gila?)

Tabel membutuhkan 2 bidang BUKAN 3. Usia dan Tingkat. Baris berikutnya ini berisi nilai tertinggi! Anda mendeormalisasi tanpa menyadarinya!

Berikut ini adalah Sql untuk mendapatkan tarif untuk seseorang usia 67 tahun.

Select * from RateTable where Age in (Select max(age) from RateTable where age <=67) 

Jangan repot-repot membuat layar pemeliharaan karena berada di luar ruang lingkup. Jika mereka memintanya nanti, keluarkan permintaan perubahan dan lakukan.

EDIT: Seperti yang orang lain katakan menjaga kode mendapatkan kurs terpusat, dalam kasus seluruh struktur Rate berubah.

Saya setuju dengan sebagian besar jawaban yang diberikan. Saya juga menambahkan bahwa konsistensi dengan sisa aplikasi itu penting. Jika ini adalah satu - satunya tempat dalam kode yang memiliki nilai-nilai hard-coded, itu mungkin akan mengejutkan pengelola. Ini terutama benar jika basis kode yang besar dan stabil. Jika ini adalah program kecil yang dikelola oleh Anda, keputusan itu tidak terlalu penting.

Saya memiliki ingatan yang jauh tentang membaca seorang pria tangkas / OOP terkenal (seperti Dave Thomas atau Kent Beck atau seseorang) mengatakan bahwa aturan praktis mereka untuk duplikasi kode dua kali dan hanya dua kali: jangan refactor saat pertama kali Anda menduplikasi sesuatu sejak Anda mungkin hanya pernah menulisnya dua kali dalam hidup Anda. Tapi yang ketiga kalinya ...

Itu tidak persis menjawab pertanyaan, karena Anda mempertanyakan YAGNI tapi saya pikir itu berbicara dengan fleksibilitas umum dari aturan tangkas. Tujuan tangkas adalah beradaptasi dengan situasi dan bergerak maju.

Kode keras dalam suatu fungsi.

• Ketika nilai berubah, Anda dapat menagih pelanggan lagi
• Ketika nilai berubah, kemungkinan format tabel harus berubah, melakukan CSV akan membuang waktu
• Lebih mudah diimplementasikan, peluang lebih tinggi untuk mendapatkan anggaran dengan kontrak saat ini
• Dapat menemukan dengan mudah kapan perlu diperbarui