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

10

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.

design

— Rebecca Scott
sumber

Jangan lupa, jika tarif berubah dan semua yang Anda miliki adalah nilai yang dikodekan dengan keras, Anda dapat mengacaukan perhitungan catatan historis ketika tarif berubah (dan mereka akan melakukannya, terlepas dari apa yang klien Anda katakan kepada Anda).

— Andy

6

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.

— Corbin March
sumber

Saya tidak akan mengatakan bahwa migrasi Rails membuat tabel dari model ... Rails migrasi menggambarkan perubahan ke tabel. Menjalankan migrasi mengubah basis data. Properti model yang cocok dengan struktur tabel dibuat pada saat dijalankan.

— kevin cline

Ini menarik minat saya, saya belum mempertimbangkan mengotomatisasi bagian dari upaya awal ke tingkat itu. Dan memiliki otomasi itu berarti saya dapat membuat tabel lengkap daripada menggunakan CSV untuk menghemat waktu. Yang saya khawatirkan adalah pemeliharaan jangka panjang dari kode yang dihasilkan. Dengan membuatnya di muka saya sudah membuat asumsi awal bahwa metode melakukan pencarian tidak akan pernah berubah. Saya kira jika itu kemungkinan saya hanya harus mempertimbangkan itu sebagai bagian dari biaya / manfaat, memberikan pengurangan biaya boilerplate. +1

— Rebecca Scott

Pertanyaannya adalah, "haruskah saya nilai-nilai hard-code ketika klien saya mengatakan mereka tidak akan berubah?" dan jawaban Anda adalah "tidak, dan sebenarnya Anda harus melempar ORM ke masalah." Saya tidak setuju. Ada opsi yang lebih sederhana yang memungkinkan OP menghindari pengkodean keras. Membuat penambahan besar pada arsitektur untuk mendukung hal-hal yang secara eksplisit ditunjuk tidak perlu adalah tidak etis. Sangat disayangkan bahwa banyak pengembang cenderung melakukan hal-hal seperti itu. Dan saya harus mengatakan, saya tidak setuju 100% dengan saran Anda untuk tidak "biarkan perasaan, 'wow, ini sakit di leher' menghentikan Anda dari melakukan hal yang benar." Perasaan itu penting!

— user1172763

10

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

— sdg
sumber

1

+1 untuk poin kedua Anda. Saya tidak mencoba untuk mengetahui apa yang mungkin dilakukan oleh badan legislatif di masa depan.

— David Thornley

Lakukan di fungsi perpustakaan. Tidak masalah memiliki hanya satu pengguna. Kapan dan jika persyaratan berubah, Anda punya satu tempat untuk diubah. (Anda mungkin perlu menambahkan fungsi untuk melakukan pencarian nilai pada tanggal tertentu.)

— BillThor

Jawaban terbaik dan terlengkap, +1

— Andy

7

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.

Pencarian hanya akan dilaksanakan di satu tempat (sesuatu seperti PensionRateLookupkelas mungkin) yang kemudian digunakan secara global. Saya akan melakukan itu terlepas dari apakah itu disimpan di luar aplikasi atau hardcoded, dengan cara itu hanya implementasi PensionRateLookupkelas yang perlu dipertahankan. Masalah saya adalah bagaimana saya menggunakan YAGNI untuk sampai pada kesimpulan bahwa pengkodean keras tabel pencarian dapat diterima.

— Rebecca Scott

Terima kasih atas jawaban Anda. Menjaga implementasi pencarian di satu tempat jelas merupakan desain yang bagus.

— Rebecca Scott

YAGNI hanya valid JIKA Anda bisa mengirim binari baru ketika tarif berubah. Jika Anda tidak bisa, tetapi Anda dapat mengubah konfigurasi, maka jadikan itu nilai konfigurasi yang dibaca saat memulai dengan representasi tekstual saat ini sebagai default.

Saya mengirimkan versi baru biasanya setiap minggu jadi sebenarnya memperbarui pencarian bukanlah masalah. Memasukkannya ke dalam konfigurasi klien sebenarnya lebih buruk karena saya tidak dapat mengubah konfigurasi klien dengan biner baru. Alternatif seperti yang saya lihat adalah meletakkannya di database yang berarti banyak usaha.

— Rebecca Scott

Lalu apa masalahnya? Ketika tarif berubah, Anda memperbarui kode dan mengirim ke semua pelanggan?

2

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 :)

— JSBach
sumber

Terima kasih @Oscar. Bagian teknis dari itu adalah def. benar. Dan saya setuju dengan bagaimana Anda akan mendekati masalah, dengan refactoring hanya ketika dibutuhkan. Jadi Anda mengatakan bahwa sebagai seorang profesional kita dapat dan harus memilih prinsip-prinsip desain kami, hanya berdasarkan biaya / manfaat? Masuk akal.

— Rebecca Scott

@ Ben Scott: Terima kasih kembali :). Ya, dalam pandangan saya, prinsip-prinsip desain diciptakan / di katalog bukan karena mereka terlihat indah, tetapi karena mereka membawa manfaat seperti kode "kebersihan", fleksibilitas, ketahanan, dll. Tetapi selalu ada 2 pertanyaan: 1- Apakah saya memerlukan itu ? 2- Apakah batasan saya (waktu, teknis, dll) memungkinkan saya untuk mengimplementasikannya? Inilah yang biasanya membuat saya memilih prinsip desain saya. Rekayasa berlebihan juga buruk;) ps: jika menurut Anda ini adalah jawaban yang menarik, silakan berikan suara sehingga orang lain juga membacanya dengan probabilitas yang lebih tinggi. Terima kasih! :)

— JSBach

terbalik ;-)

— Rebecca Scott

2

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.

— Berin Loritsch
sumber

Terima kasih @berin, saya tidak menyebut SRP dalam pertanyaan tapi itu ada dalam rencana. Poin yang baik adalah memberikan kepemilikan masalah kembali ke klien.

— Rebecca Scott

Menugaskan menyalahkan ketika ada masalah di masa depan tampaknya tidak profesional bagi saya.

— Andy

@Andy, bagian mana dari yang menyalahkan? Menyajikan batasan desain kepada klien memungkinkan mereka kesempatan untuk memprioritaskan pekerjaan rumit sekarang dan mengambil hal-hal lain dari meja, mendorong tenggat waktu, atau menerima desain terbatas sekarang karena hal-hal lain di atas meja lebih penting bagi mereka. Anda memberdayakan klien Anda dengan pilihan atas produk mereka. Membuat klien Anda sadar akan risiko / hadiah pilihan yang ingin Anda buat sesuai minat mereka akan membuat proyek berjalan lebih lancar.

— Berin Loritsch

@BerinLoritsch Tapi keputusan desain khusus ini mirip dengan menggunakan bagian di bawah standar yang mengatakan "Saya bisa menggunakan dempul tukang ledeng untuk memasang pipa bocor ini, itu pilihan termurah Anda!" Tarif AKAN berubah. Ini diberikan, dan tidak bertanggung jawab bagi seorang profesional untuk membangun sistem yang tidak memungkinkannya. Dan penghematan mungkin diabaikan dalam skema besar biaya proyek. Masukkan data ke dalam tabel; kode yang mendapatkan data pencarian sedikit berbeda, logika menentukan tingkat yang digunakan adalah sama. Satu-satunya keputusan lain adalah bagaimana menangani data historis setelah ...

— Andy

perubahan tarif, yang biasanya ditangani dengan hanya menyalin tarif ke catatan yang relevan. Tidak ada layar admin diperlukan pada saat ini, sistem kemudian dapat menangani ketika tarif berubah, dan itu akan menjadi skrip sederhana untuk mengubahnya. Semua ini seharusnya tidak lebih dari beberapa jam, tetapi akan mencegah ruang bawah tanah dari banjir tahun depan ketika dempul gagal.

— Andy

2

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 :)

— EZ Hart
sumber

Saya memang mempertimbangkan untuk memilikinya dalam pengaturan konfigurasi tetapi mengesampingkannya karena pengguna tidak terlalu teknis sejauh mengedit string CSV, jadi saya akan menjadi orang yang memperbarui konfigurasi untuk pengguna N (seperti yang saya lakukan semua dukungan TI di org juga), dalam hal usaha akan lebih mudah untuk melakukan pekerjaan dimuka untuk memasukkannya ke dalam database yang dapat saya kelola dari satu tempat. Saya kira jika itu bukan pertimbangan (jika pengguna mampu mengelola konfigurasi masing-masing) saya tidak akan memiliki masalah ini. Jadi poin yang sangat bagus, terima kasih.

— Rebecca Scott

Jika Anda menggabungkan ini dengan saran lain dari logika terpusat maka itu adalah jawaban yang bagus. Adalah kejahatan murni untuk benar-benar hardcore pencarian daripada dimasukkan ke dalam cara yang memungkinkan untuk diubah melalui konfigurasi. Setiap kali pengembang lain menemukannya, mereka akan membenci Anda karenanya. Bahkan satu toko pengembang harus mempertimbangkan apa yang terjadi jika mereka tertabrak bus dan harus memudahkan pengembang berikutnya untuk mengubah nilai-nilai tanpa rilis perangkat lunak lengkap. Hanya jika Anda membenci klien dan membenci semua pengembang lain, Anda dapat melakukannya. Jadi pada dasarnya tidak pernah.

— simbo1905

2

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.

— Orang bodoh
sumber

Hai @Morons, terima kasih atas jawaban Anda. Tabel sebenarnya membutuhkan 3 kolom. Ini adalah tarif tunggal per rentang usia, usia minimum hingga usia maksimal (usia 65 hingga 69 tahun adalah pada 5%). Dan saya hanya menyimpan sejumlah kecil data untuk tujuan terbatas, jadi apa salahnya membuat asumsi tentang struktur dan menggunakan CSV alih-alih seluruh tabel khusus? Saya mungkin akan menambahkan pembatas baris, dan membagi demi baris lalu kolom dan tarik kolom ke bidang yang diperlukan. Ini akan selalu dibaca lebih dari sekadar menulis jadi saya tidak terlalu khawatir tentang tabel lengkap.

— Rebecca Scott

Baris berikutnya Berisi nilai atas rentang ... Ini adalah duplikasi data. Mengatakan <69 dan> 7 adalah hal yang sama. Satu-satunya alasan untuk memiliki kedua nilai adalah jika rentang dapat memiliki Lubang. ... Saya mengatakan untuk menggunakan tabel karena itu lebih mudah (dan desain yang lebih baik). Saya tidak mengerti mengapa Anda berpikir menyimpan csv dalam sebuah tabel akan menghemat waktu atau usaha Anda, Anda masih membutuhkan panggilan DB hanya untuk mendapatkan string itu, maka Anda harus menguraikannya. Seperti yang saya tunjukkan di atas, Anda bisa mendapatkan tarif dengan satu panggilan DB.

— Moron

Ah benar. Saya menjaga meja itu sendiri mirip dengan bahan sumber ... dan saya melewatkan bahwa usia adalah batas atas dalam jawaban Anda karena saya memiliki sads yang saya berikan kepada Anda sads.

— Rebecca Scott

1

"Kamu membuat demoralisasi tanpa menyadarinya!" - pada awalnya saya pikir ini adalah kesalahan ketik dan yang Anda maksud adalah 'denormalize', tetapi semakin saya memikirkannya, semakin Anda sepertinya baik-baik saja :)

— EZ Hart

@ez hart LOL benar.

— Rebecca Scott

1

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.

— Dave
sumber

Terima kasih @Dave, itu sangat membantu. Saya adalah satu-satunya pengelola, sejak awal, tetapi merupakan basis kode yang besar dan relatif stabil (ribuan file, lebih dari 100 tabel, dll) dan saya masih terus-menerus terkejut (dan kecewa). Konsistensi jelas merupakan salah satu tujuan saya ke depan.

— Rebecca Scott

0

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

— earlNameless
sumber

Biarkan saya memasang nilai di bawah standar ini sehingga ketika pasti rusak dalam setahun saya mendapatkan bisnis yang berulang. Kedengarannya teduh, karena memang begitu.

— Andy