Apakah ada harapan untuk menulis kode yang baik di atas database yang dirancang dengan mengerikan?


18

Inilah kesulitan saya. Salah satu dari beberapa program yang baru-baru ini saya warisi dibangun dengan database yang mengerikan di backend. Pencipta yang terhormat itu rupanya tidak menghargai konsep relasional. Tabel untuk masing-masing dan setiap klien, dinamai sebagai ID klien yang unik. Delapan puluh tiga bidang bernama cryptically. Kode ini semuanya prosedural dengan lusinan pernyataan SQL inline bersambung.

Karena kami tidak dilengkapi dengan aplikasi tambahan penting yang menjalankan database yang sama, saya telah ditugaskan untuk membuatnya dari awal. Saya adalah pengembang tunggal, yang bahkan bukan tanggung jawab utama saya karena setidaknya setengah dari waktu saya diambil oleh hal-hal operasi. Ada tenggat waktu yang tak terhindarkan yang ditetapkan selama 30 hari dari sekarang.

Terlepas dari pengalaman saya, saya yakin saya bisa mendesain database ini dan aplikasi yang ada jauh lebih baik daripada sebelumnya, tetapi saya tidak berpikir itu realistis bagi saya untuk mengubah database, menyesuaikan aplikasi yang ada, dan pastikan saya tidak melakukannya Jangan pecahkan apa pun saat perlu membuat aplikasi tambahan ini dengan cepat.

Jadi mari kita asumsikan saya terjebak dengan database yang mengerikan. Perlu bekerja dengan struktur yang begitu buruk, akankah sesuatu yang saya tulis yang sesuai dengannya hanya menambah tumpukan utang teknis yang harus ditangguhkan sampai sesuatu yang benar-benar rusak atau fungsi baru diperlukan? Bagaimana saya bisa mendekati situasi ini dan mendapatkan sesuatu yang baik selain dari aplikasi yang mudah-mudahan fungsional?

sunting: Jika ada yang tertarik, kami akhirnya menghapus basis data yang mengerikan ini dan aplikasi yang menjalankannya. Kami mengalihdayakan pembuatan aplikasi tambahan (saya tidak terlibat dalam pengaturan ini) pada akhirnya dua kontraktor yang berbeda yang akhirnya jatuh pada kami, tidak menghasilkan apa-apa. Saya akhirnya harus menjalankan perbaikan yang mengerikan, sebagian fungsional dari perbaikan dalam tiga hari yang masih digunakan sampai sekarang.


2
Coba pikirkan bagaimana Anda akan kode terhadap perpustakaan di mana kasus khusus "2 + 2" tidak kembali 4. Ini tidak mudah.

8
jadi, yang saya dengar semua ini adalah Anda punya waktu 30 hari untuk mencari pekerjaan lain. coba karier.stackoverflow.com ;-)
Steven A. Lowe


@gnat: Bahkan tidak dekat.
Robert Harvey

Jawaban:


27

Ada harapan, tetapi ini adalah perjuangan yang berat, terutama jika tidak ada yang menyadari bahwa desain database mengerikan. Anda dapat mencoba untuk mengabstraksi nastiness dengan lapisan abstraksi, tetapi kemungkinan itu tidak akan sebanding dengan pertempuran.

Saran saya adalah untuk membuat abstraksi yang cukup atas database sehingga aplikasi itu sendiri bersih dan dirancang dengan baik; dengan begitu jika Anda dapat memperbaiki database, aplikasi tidak akan terpengaruh karena tidak peduli bagaimana database dirancang.

Ini adalah pendekatan yang biasanya saya gunakan ketika berhadapan dengan database yang ada dan, lebih sering daripada tidak, dirancang dengan pemikiran nol. Beberapa aplikasi pilihan pola Repositori atau Gateway, dengan beberapa lapisan layanan untuk berbicara dengan gateway / repositori, akan membantu untuk mengkarantina desain yang buruk.


1
+1 Saya pada dasarnya mengatakan hal yang sama dalam jawaban saya sebelum sepenuhnya membaca jawaban Anda namun saya tidak melihat cara untuk menghapus jawaban saya karena jawaban Anda mencakup materi yang sama.
Ominus

Seperti yang telah saya komentari kepada orang lain yang membuat saran ini, itu adalah saran yang bagus tetapi sangat mungkin bahwa jika desain basis data adalah omong kosong maka kode aplikasi kemungkinan juga omong kosong. Saya tidak melihat gunanya pergi ke masalah ini jika kode aplikasi harus di refactored juga.
maple_shaft

3
@maple_shaft Setuju tetapi OP mengatakan bahwa dia diminta untuk membuat, dari awal, aplikasi baru yang akan berinteraksi dengan database. Dalam kasus seperti itu, masuk akal untuk membuat aplikasi baru dengan benar.
Wayne Molina

1
@maple_shaft, satu-satunya bagian omong kosong dari aplikasi akan menjadi bagian yang berinteraksi dengan database sampah. Itulah inti dari arsitektur N-Tier dan SOC.
StuperUser

1
@maple_shaft Tujuannya adalah untuk menempatkan database ke dalam semacam "kotak hitam", dan memberikan aplikasi antarmuka yang lebih ideal dan tidak selalu mewakili desain database.
Michael Dean

10

Buat layer antarmuka yang menangani semua hal DB lalu tulis aplikasi Anda untuk berinteraksi dengannya. Jika database pernah "diperbaiki", Anda hanya mengganti / memperbarui "antarmuka" Anda. Pendekatan ini telah menyelamatkan saya banyak waktu ketika berhadapan dengan database yang buruk atau database yang memberi makan aplikasi lain dan tidak dapat dikacaukan.


Bagaimana Anda bisa menghapus jawaban Anda sendiri atau ini bukan suatu kemungkinan?
Ominus

Anda dapat menghapus jawaban Anda sendiri. Anda tetap melihat mereka dengan latar belakang berwarna dan akan mengatakan sesuatu seperti "dihapus oleh pemilik". Selain Anda, hanya orang dengan kekuatan moderator yang akan melihatnya.
Marjan Venema

@Minus: Seharusnya mungkin, tapi mengapa Anda mau? Anda mendapat 3 upvotes!
FrustratedWithFormsDesigner

1
@ Marsjan: Moderator dan siapa pun dengan> 10 ribu perwakilan.
Jerry Coffin

1
Mengapa Anda ingin menghapus jawaban ini? Saya pikir ini solusi yang sangat baik.
Jim G.

6

Aduh ... Anda mewarisi kekacauan mimpi buruk, Anda punya 30 hari untuk membuatnya dapat digunakan untuk organisasi Anda, dan setengah hari Anda diambil dengan tugas-tugas operasi?

Saya yakin Anda bisa refactor tetapi tentu saja tidak dalam waktu sebanyak itu.

Untuk menjawab pertanyaan Anda, saya rasa Anda tidak bisa menulis kode yang bagus pada desain seperti itu. Utang teknis sudah terlalu banyak. Jika saya adalah Anda, saya akan meretas fitur yang saya bisa, dan tekan untuk refactoring lengkap di kemudian hari ketika Anda memiliki lebih banyak waktu dan orang-orang di tim Anda untuk mengatasinya dengan lebih baik.

Hati-hati mendorong untuk refactoring. Terkadang atasan akan membuat keputusan untuk membeli kode sumber produk dan hak kepemilikan dan mereka tidak ingin berpikir bahwa mereka benar-benar membuang-buang uang mereka untuk sampah. Ini adalah kasus bagi saya di satu pekerjaan yang saya miliki. Sayangnya manajer membuat keputusan untuk membeli perangkat lunak seperti ini dan mereka tidak pernah mendapatkan keterlibatan teknis untuk mengevaluasi apa yang mereka beli dan melihat apakah itu dapat dipertahankan dan memiliki banyak hutang teknis. Dalam hal ini keputusan yang buruk adalah keputusan politik dan mendorong refactoring dapat membahayakan pekerjaan Anda.


Meskipun orang lain tidak terbiasa dengan pemrograman, saya telah menjelaskan bagaimana kualitas basis kode ini akan mempengaruhi pemeliharaan. Mereka ada di papan dengan upaya refactoring besar untuk mendapatkan semuanya dalam keadaan yang lebih cocok sehingga saya tidak berisiko membahayakan pekerjaan saya, tetapi saya tidak berpikir itu akan terjadi bulan ini.
John Straka

3
Terkadang melakukan peretasan yang berhasil karena pengalaman pertama Anda dengan proyek dapat memberi Anda kredibilitas untuk melakukan refactor di proyek selanjutnya untuk aplikasi yang sama. Sedih tapi benar. Pertama, mereka harus percaya bahwa Anda tahu apa yang Anda lakukan sebelum mereka akan mempertimbangkan perubahan radikal. Poster itu berada di tempat yang sulit untuk dipastikan.
HLGEM

1
@ John, Ini bagus karena mereka MENGAKUI perlunya refactoring. Ini adalah tanda manajemen jangka panjang yang baik dan langkah pertama untuk benar-benar melakukan refactoring.
maple_shaft

3
+1 untuk jawaban hebat dan realistis. Anda memiliki satu bulan, tetapi benar-benar hanya setengah bulan karena Anda bekerja paruh waktu di operasi. Itu 11-15 hari tergantung pada apakah Anda melepas akhir pekan. Saya benci mengatakannya, tetapi saya setuju bahwa taruhan terbaik Anda adalah membanting sesuatu yang berfungsi dengan segera dan membuat catatan tentang bagaimana meningkatkan atau menulis ulang nanti, terutama karena manajemen Anda berada di atas kapal dengan refactoring.
Bob Murphy

6

Database dapat di-refactored seperti kode lainnya. Perbaiki bagian yang dipengaruhi oleh kode yang Anda butuhkan untuk menulis dan menulis tes untuk memastikan tidak ada lagi yang rusak. Lakukan sedikit demi sedikit sama seperti refactoring lainnya. Ada buku bagus tentang refactoring basis data yang mungkin membantu Anda memulai membersihkan kekacauan. http://www.amazon.com/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1307025831&sr=8-1

Ada yang lain juga, tapi saya pribadi sudah membaca dan bekerja dengan teknik yang satu ini.

Dan jangan lupa Anda dapat merestrukturisasi cara yang Anda butuhkan untuk query database dengan membuat tampilan untuk melakukan pekerjaan transformatif yang buruk bagi Anda menjadi sturcture yang lebih mudah untuk query.


Ini semua baik dan bagus tetapi saya memiliki kecurigaan yang kuat bahwa jika desain database berantakan maka kode aplikasi mungkin juga tidak berharga.
maple_shaft

@maple_shaft, bisa jadi itu adalah pengalaman saya bahwa bahkan pengembang aplikasi yang baik mendesain database yang mengerikan. Either way hanya refactoring bertahap akan memperbaiki kekacauan, dia tidak bisa langsung menggantinya meskipun aku yakin dia akan menyukainya.
HLGEM

+1 @HLGEM, Ini poin bagus. Nasihat Anda bagus jika kode aplikasi dirancang dengan baik. Refactoring sebagian mungkin adalah cara terbaik untuk pergi tetapi dalam seluruh karir saya, saya belum pernah melihat yang berhasil. Namun mungkin karena manajemen proyek yang buruk, bukan karena itu adalah ide yang tidak sehat.
maple_shaft

5

Untuk mendapatkan keuntungan terbesar dari uang Anda, buat tampilan yang dapat diperbarui untuk memulihkan beberapa "keterkaitan" dan untuk memberikan nama kolom yang lebih bermakna.


Ini akan menjadi awal yang baik. Jika basis data didenormalisasi, maka saya akan menambahkan pemicu atau prosedur tersimpan untuk mengisolasi aplikasi dari denormalisasi.
kevin cline

4

Satu kemungkinan adalah untuk membuat database kedua yang terstruktur (setidaknya lebih dekat dengan) seperti yang Anda inginkan, dan mengatur replikasi antara dua database. Kemudian Anda dapat menulis kode Anda terhadap basis data baru dan tetap membiarkan basis data (dan aplikasi) yang ada tetap utuh, untuk ditangani ketika Anda memiliki lebih banyak waktu.

Sejujurnya, masih terbuka untuk banyak pertanyaan apakah Anda dapat melakukannya dalam ~ 15 hari kerja. Secara khusus, itu kemungkinan tergantung pada apakah Anda memerlukan replikasi dua arah (yaitu, aplikasi baru Anda benar-benar akan memperbarui data) atau hanya satu arah (aplikasi baru Anda hanya membuat orang melihat data). Kasus terakhir (tentu saja) secara dramatis lebih mudah untuk ditangani.

Jika Anda membutuhkan replikasi dua arah, kemungkinannya adalah itu tidak cukup waktu untuk melakukan pekerjaan itu. Secara khusus, replikasi dua arah yang melibatkan transformasi struktur secara substansial tidak pernah sepele, dan alat yang tersedia sering mendukungnya dengan sangat buruk (misalnya, harus menulis secara manual semua SQL untuk semua transformasi data di kedua arah).

Jika Anda hanya perlu satu arah, itu tepat pada titik yang mungkin membatasi kemungkinan. Hal ini juga akan tergantung sedikit pada apakah Anda diperbolehkan untuk menghabiskan uang atau tidak - ada beberapa data yang pergudangan aplikasi yang ditujukan untuk persis semacam ini tugas yang mungkin akan membuatnya sedikit lebih cepat dan lebih mudah untuk mengelola - tetapi kebanyakan dari mereka tidak murah.


+1, Ini bisa menjadi ide yang bagus juga selama semua kode akses data aplikasi dipisahkan dengan benar dari lapisan lain, dan kode akses data itu dapat di-refactored untuk bekerja dengan skema baru
maple_shaft
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.