Apakah lebih baik menggunakan praktik buruk yang sudah ada sebelumnya, atau praktik baik yang tidak sesuai dengan kode lama?

Saya memikirkan hal ini karena saya mencoba untuk menulis ekstensi untuk perangkat lunak pihak ke-3 yang ada, dan database mereka didenormalkan secara mengerikan. Saya perlu menggunakan tabel yang ada dan menambahkan banyak bidang baru.

Saya memiliki pilihan untuk membuat tabel baru dengan gaya desain mereka (yang terdiri dari hampir semua properti dalam satu tabel besar), atau membuat set tabel baru secara bersamaan dan menggunakan sesuatu yang ekstra seperti Pemicu untuk menyinkronkan data antara yang baru dan yang baru. meja lama.

Saya akhirnya memilih opsi pertama untuk menggunakan gaya desain yang buruk, tetapi saya dibiarkan dengan pertanyaan ini: Apakah lebih baik untuk pergi dengan praktik buruk yang sudah ada sebelumnya, atau untuk menerapkan praktik baik yang tidak cocok dengan kode yang ada? Apakah ada beberapa situasi di mana saya harus memilih satu dari yang lain?

CATATAN: Banyak jawaban sejauh ini berkaitan dengan refactoring kode buruk, namun saya tidak dapat melakukannya. Kode ini bukan milik kita, dan sering diperbarui oleh vendor. Saya hanya bisa membangun di atasnya.

Anda harus memilih desain yang lebih baik jika:

1. Anda akan mengambil alih sebagian besar pengkodean di masa depan

2. Desain yang lebih baik tidak lebih mahal bagi klien dalam jangka panjang. Sebagai contoh, saya telah menyaksikan "refactoring" multi-bulan untuk proyek-proyek yang dihentikan pada akhir tahun.

Anda harus memilih "gaya buruk yang sama" jika:

1. Anda hanya membantu. Tidak realistis untuk berpikir Anda dapat mengambil grup yang ada dan akan membuat mereka ke standar desain yang lebih tinggi jika Anda hanya mengisi paruh waktu pada proyek. Desain yang lebih baik adalah subyektif dan hampir selalu memiliki kurva belajar. Jika desain baru itu tidak dipelajari oleh anggota tim lainnya maka proyek akan berakhir dengan banyak gaya, dan kode Anda yang lebih baik mungkin berakhir di tumpukan barang yang tidak ada yang berubah karena mereka tidak dapat mengerti saya t. Dalam contoh Anda di atas, apa yang terjadi jika ada pembaruan untuk perangkat lunak pihak ketiga?

2. Mengorbankan desain "lebih baik" akan memberi Anda keuntungan bisnis yang nyata. Seperti menambahkan fitur X dengan buruk akan membuat Anda mendapatkan kontrak besar, tetapi melewatkan tenggat waktu menyebabkan Anda berakhir tanpa hasil. Di sinilah konflik bersejarah antara mgmt dan tim teknis masuk. Seperti merenovasi rumah, seseorang harus memutuskan kapan harus membayar. Anda dapat membayar utang awalnya dengan hidup tanpa listrik atau pipa ledeng selama setahun. Atau Anda dapat membayar 3x lebih banyak dengan manfaat memiliki utilitas tersebut.

Dalam jangka panjang, lebih baik menggunakan praktik yang baik. Ini akan menghemat waktu dan upaya karena perubahan akan memakan waktu lebih sedikit untuk diterapkan.

Jika memungkinkan, ambil langkah-langkah kecil untuk memperbaiki praktik yang baik (misalnya: dalam SQL yang akan melanggar tabel denoramlisasi untuk menormalkan satu dan menggunakan tampilan dengan nama tabel lama).

Anda akan perhatikan bahwa saya berkata dalam jangka panjang - segitiga "kualitas, waktu, uang" juga berlaku di sini (yaitu - pilih dua). Jika Anda tidak punya waktu, Anda mungkin harus mengikuti praktik lama, tetapi ini berarti Anda menambah masalah dan bahwa desain Anda juga perlu diperbaiki.

Jika Anda terus bekerja dan menambahkan kode desain yang buruk, Anda tidak akan pernah berakhir dengan basis kode yang menggunakan desain yang baik. Sebisa mungkin coba gunakan desain yang bagus dan refactor untuk desain yang bagus.

Yah, saya pikir itu sangat tergantung pada setiap kasus. Jika kinerja dan desain memungkinkan, lebih baik menggunakan praktik yang baik. Tetapi jika misalnya, jika tabel itu adalah tabel akses tinggi, maka menciptakan pemicu untuk penyinkronan mungkin berdampak negatif pada kinerja.

Sekarang, klien Anda tidak akan melihat bahwa Anda menggunakan desain yang lebih baik, dia hanya akan melihat bahwa solusi Anda membuat sistemnya lebih lambat. Jenis keputusan ini harus dibuat berdasarkan kasus per kasus, dan Anda harus menggunakan pengalaman dan kriteria Anda untuk memutuskan.

Saya pikir Anda mungkin membuat pilihan yang tepat.

Sebisa mungkin, Anda harus mengisolasi kode aplikasi Anda dari desain data yang buruk.

Apakah Anda memperbarui tabel mereka? Jika tidak, maka buat tampilan SQL untuk menyajikan tabel tersebut dengan cara yang nyaman untuk aplikasi Anda. Tampilan SQL relatif mudah untuk ditulis, dan jauh lebih mudah untuk diuji daripada kode aplikasi.

Jika Anda harus memperbarui tabel lawas, pertimbangkan untuk menulis prosedur tersimpan untuk mengelola pembaruan. Mereka sedikit lebih rumit untuk ditulis, tetapi mereka dapat diuji secara instan.

Untuk menjaga kode lama dalam sinkronisasi ketika Anda menormalkan database dengan pemicu ia adalah solusi yang baik jika bersifat sementara. Tujuannya adalah untuk mengubah kode lama, tetapi ketika berhadapan dengan pihak ketiga, itu mungkin tidak berhasil. Anda harus tetap mengikuti perubahan skema mereka.

Menumpuk semakin banyak fitur pada kode buruk akan membuat masalah terus menerus. Bekerja di sekitar menjadi norma. Pengguna akan menjadi frustrasi karena perubahan akan memakan waktu terlalu lama dan mungkin memperkenalkan bug atau batasan lain. Siapa yang mau menjadi programmer untuk mengatakan kita tidak bisa melakukan itu daripada kita tidak seharusnya melakukan itu?

Beberapa kode dapat dibiarkan sendiri; kita tidak selalu memiliki kemewahan itu.

Anda berhadapan dengan hutang teknis di sini. Singkatnya, utang teknis menyiratkan bunga, yang harus Anda bayar seiring waktu, dan pada titik tertentu, Anda harus mengembalikannya.

Waktu Develloper membutuhkan biaya, sehingga utang teknis dapat dilihat seperti utang riil, dan biaya uang nyata.

Anda pada dasarnya memiliki dua solusi utama, dan banyak solusi di antaranya. Anda dapat memutuskan bahwa Anda tidak ingin mengembalikan hutang itu sekarang, dan terus membayar bunga. Jelas, ini akan lebih mahal dalam jangka panjang, tetapi memungkinkan Anda untuk mendapatkan hasil sekarang. Anda juga dapat memilih untuk mengembalikan hutang itu, sehingga Anda tidak akan maju lagi selama Anda tidak mengembalikannya, tetapi, pada akhirnya, Anda bebas dari bunga.

Biasanya Anda memiliki tenggat waktu pengiriman, dan melewatkan tenggat waktu akan menyebabkan ketidakpercayaan pelanggan Anda, dan akhirnya Anda akan kehilangan itu. Ini bisa menjadi alasan yang sah untuk menggali utang teknis: Anda menganggap bahwa apa yang Anda peroleh dengan pelanggan sebanding dengan pembayaran ekstra utang teknis.

Anda tahu bahwa pada akhirnya, Anda harus mengadopsi metodologi baru, selain itu, Anda akan mendapatkan lebih banyak hutang dan Anda akhirnya bangkrut (Anda sekarang, ketika orang memutuskan untuk memulai lagi dari awal atau ketika proyek gagal parah).

Anda harus merencanakan bagaimana Anda akan mengubah basis kode yang ada dan transisi ke praktik baru dari waktu ke waktu, dan distribusikan perubahan sedikit demi sedikit setiap hari. Pada titik tertentu, ketika refactoring mereka akan menyebabkan kerugian lain, pertimbangkan kerugian mana yang lebih buruk dan pilih yang terbaik.

Biaya tidak refactoring akan meningkat dari waktu ke waktu (ini adalah bunga hutang teknokratis). Jadi ini akhirnya akan menjadi pilihan termahal.

Pastikan bos Anda memahami konsep utang teknis. Bahkan dengan tindakan pencegahan, Anda akan membuat hutang teknis. Pada titik tertentu, uang digunakan untuk mengembalikannya. Ketika Anda membuat utang teknis dengan sengaja, Anda HARUS punya alasan yang sah untuk itu, dan melihat utang itu sebagai investasi (seperti utang riil). Dalam kasus lain, JANGAN MELAKUKAN hutang teknis dengan sengaja.

Anda mungkin tertarik pada metodologi untuk mengembangkan DB dan menggunakan evolusi mereka: http://richarddingwall.name/2011/02/09/the-road-to-automated-database-deployment

Ngomong-ngomong, itu tugas yang sulit, semoga sukses. Pantas !

Ini adalah masalah khas: "Apakah saya perlu menuai manfaat dari pekerjaan saya sekarang atau nanti?" dan saya tidak berpikir akan ada solusi generik untuk jawaban itu. Hanya Anda yang tahu semua faktor (teknis dan manusia) yang terlibat dalam keputusan seperti itu.

Namun masalah Anda menimbulkan pertanyaan menarik:

Apakah refactoring kode otomatis membuat kemajuan yang cukup sehingga keseragaman kode harus lebih dihargai?

Pada akhirnya, desain yang buruk harus berubah atau mati. Atau yang lain, itu bukan desain yang buruk. Pertanyaan sebenarnya di sini adalah tentang biaya refactoring. Tampaknya jelas dari pertanyaan Anda bahwa Anda (atau atasan Anda) tidak mau membayar harganya sekarang, dan dalam kondisi teknologi saat ini, sepertinya tidak akan pernah mau.

Namun, otomatisasi refactoring kode membuat beberapa kemajuan. Jika kompiler dapat mengoptimalkan binari hari ini, siapa bilang mereka tidak akan mengoptimalkan kode besok? Pada titik tertentu, beberapa alat akan muncul, memungkinkan pengembang dan perancang untuk membuat ulang kode mereka dengan sangat mudah, untuk beradaptasi dengan persyaratan yang lebih baru. Bagaimanapun, berurusan dengan kode warisan adalah salah satu tantangan terbesar saat ini.

Jika alat seperti itu pernah ada (saya tidak akan terkejut bahwa itu sudah ada), akan baik untuk memperhitungkannya, ketika membuat keputusan seperti itu.

Praktik yang baik selalu mengalahkan yang buruk. Jika basis kode Anda dikotori oleh kode dengan cara yang salah, Anda tidak harus hanya kargo barang Anda sendiri dengan cara yang sama, Anda harus menulis kode dengan benar dan kemudian mencoba untuk mendidik semua orang dengan cara yang benar.