Apakah pembuatan dan penghapusan tabel terus-menerus merupakan tanda cacat arsitektur?

Baru-baru ini saya berdiskusi dengan pengembang yang menyebutkan bahwa selama pengembangan program, mereka secara rutin membuat dan menghapus tabel dan kolom secara teratur sambil bekerja pada fitur-fitur baru dan membenarkan hal-hal dengan mengatakan bahwa ini normal ketika menggunakan proses pengembangan tangkas.

Karena sebagian besar latar belakang saya berada di lingkungan pengembangan air terjun, saya bertanya-tanya apakah ini benar-benar dianggap layak dalam pengembangan tangkas, atau apakah ini mungkin merupakan tanda masalah mendasar, baik dengan arsitektur program atau dengan mengikuti proses tangkas mereka.

Menjadi semakin jelas bagi saya setiap hari bahwa "lincah" menjadi sinonim bagi orang yang berpikiran buruk, kacau, terburu-buru, dan duduk di kursi Anda. Dan tidak satu pun dari hal-hal itu yang kompatibel dengan pendekatan Agile seperti yang saya mengerti.

Memiliki proses Agile yang efektif dan dapat diulang tidak mudah, dan saya tidak percaya bahwa itu secara inheren mengurangi jumlah total pekerjaan yang harus dilakukan walaupun mungkin sangat mengarah pada produk yang lebih baik.

Jika mereka mengatakan bahwa mereka tidak punya waktu untuk "memperbaiki" database, maka mereka mungkin juga tidak punya waktu untuk mengatur versi dan migrasi untuk database. Mereka mungkin belum meluangkan waktu untuk membuat serangkaian tes fungsional untuk itu. Semua hal itu adalah apa yang saya pikirkan ketika saya memikirkan proses Agile solid yang menuju kesuksesan.

Pada akhirnya, Agile hanya sebuah kata. Apa yang Anda lakukan sehari-hari menentukan apakah Anda akan berhasil atau tidak.

Meskipun tidak biasa membuat dan menjatuhkan tabel saat desain berevolusi, beberapa pembersihan mungkin dilakukan untuk memastikan database Anda benar-benar menggunakan semua tabel itu.

Ya, Agile adalah semua tentang refactoring, tetapi jika mereka sekarang mengatakan sistem terlalu besar untuk refactor, mereka telah berhenti melakukan Agile dan sekarang hanya pemrograman Cowboy. Tim pengembang tidak akan suka disebut demikian, tetapi itulah yang mereka lakukan. Mengendarai jangkauan menembak apa pun yang bergerak.

DBA akan membantu, pastikan Anda mendapatkan DBA yang memahami pengembangan serta pengembangan Agile. Tim pengembangan Anda perlu dikekang, bukan dijebloskan ke penjara.

Secara umum, sering membuat tabel baru dan menambahkan kolom baru sangat normal dalam proses di mana pemrograman dan administrasi basis data tidak dipisahkan secara ketat. Fitur baru mungkin membuat data baru yang harus pergi ke suatu tempat. Coba terlalu ketat untuk menghindari itu dan Anda berakhir dengan model platform dalam .

Perangkat lunak yang ditulis dengan baik hampir tidak memperhatikan objek database baru, jadi tidak ada yang rusak hanya karena kolom baru di beberapa tabel.

Di sisi lain, menjatuhkan kolom secara teratur atau bahkan tabel mencurigakan. Fitur baru tidak pernah membutuhkan tabel dihapus, jadi ini bisa menjadi tanda orang yang bekerja sepenuhnya tanpa rencana.

Jika database Anda dapat dengan mudah diversi dan dimigrasikan dan Anda memiliki tes untuk membuktikan bahwa mengubah sesuatu tidak merusak, maka Anda mungkin memiliki proses yang cukup gesit.

Mengingat komentar - umumnya akibat ini adalah sekelompok koboi membenarkan diri mereka sebagai lincah - lari menjerit. Cepat. Dan kirim semua yang Anda bisa ke thedailywtf.com agar kami semua bisa menikmati kengerian Anda.

Seperti sebagian besar jawaban di StackExchange, jawabannya harus 'tergantung'. Dalam pengembangan tangkas, persyaratan dan spesifikasi ditemukan selama implementasi.

Namun, mengingat perkembangan yang gesit, ketika model relasional dinormalisasi dengan benar, menambahkan atribut baru ke hubungan jarang menjadi keharusan, entitas baru umumnya harus merujuk pada yang lebih tua, diberikan model yang tepat.

Sebagian besar pengembang tidak menormalkan DB mereka karena kendala waktu, kemalasan, ketidakmampuan atau kompleksitas permintaan. Renormalisasi membutuhkan transfer data yang ada, modifikasi DAO, dll. Yang menghasilkan faktor risiko.

Untuk menjawab pertanyaan Anda, tidak, itu tidak normal dalam proses Agile.

Di mana tampaknya berasal dari sikap Agile adalah dari desain / pengembangan / siklus tes Agile yang pendek, dan penekanan Agile pada solusi ringan yang memenuhi persyaratan yang diketahui, tetapi terstruktur dengan baik agar dapat memenuhi persyaratan baru dengan Agile. perubahan minimal. Dengan dua hal ini, Anda mungkin mengatakan bahwa seorang pengembang, tidak tahu apa yang mungkin terjadi tetapi mengetahui perubahannya seharusnya tidak berdampak pada DB dengan cara yang tidak dapat dibatalkan, cukup buat perubahan yang diperlukan pada skema di "Teringan" cara mungkin, dan kemudian pada interval beberapa set perubahan "cahaya" akan di refactored menjadi sesuatu yang lebih permanen dan stabil.

Karena itu, saya belum bekerja dengan pengembang yang berlangganan teori dan metodologi Agile, dan juga berpikir bahwa secara rutin membuat dan menghapus tabel dalam skema diperlukan untuk alasan apa pun. Agile bukan berarti slap-dash atau bolt-on. Jika Anda diberi cerita yang membutuhkan penambahan bidang data baru milik catatan tertentu, Anda menambahkan bidang ke tabel. Jika perubahan itu merusak sesuatu, Anda mencari tahu mengapa, dan membuat perubahan lain yang mungkin diperlukan (saya bisa memikirkan beberapa hal yang akan rusak dengan menambahkan kolom ke DB yang sedang ditanyakan; jika itu pecah dengan perubahan semacam ini, Anda memiliki masalah yang lebih besar). Refactoring biasanya terbatas pada kode; mengubah skema biasanya merupakan proses yang lebih terlibat daripada mengubah kode, dan ketika perubahan skema harus terjadi mereka biasanya dibuat dengan lebih hati-hati, dan setidaknya perhatian diberikan pada pengetahuan tentang arah proyek di masa depan. Harus menyusun ulang beberapa atau semua database menunjukkan kegagalan mendasar desain; menjadi lincah tidak berarti tidak ada "rencana induk" arsitektur dasar dan aturan desain untuk diikuti saat secara organik membangun program dan struktur data.

Sekarang, ada beberapa kasus di Agile di mana apa yang Anda "tahu" sekarang akan bertentangan dengan apa yang akan Anda pelajari nanti. Katakanlah Anda memiliki persyaratan bahwa sistem Anda harus memiliki Alamat untuk setiap Orang. Karena ini adalah hubungan 1: 1 dan data akan dibutuhkan dalam sebagian besar kasus, Anda cukup menambahkan bidang Alamat ke tabel Orang. Seminggu kemudian, Anda menerima persyaratan agar Seseorang dapat memiliki lebih dari satu Alamat. Sekarang ini adalah hubungan 1: N, dan untuk memodelkannya dengan benar, Anda harus membatalkan perubahan sebelumnya, memecah bidang menjadi tabel Alamat baru. Ini tidak rutin, terutama di kalangan pengembang senior. Pengembang yang berpengalaman akan melihat bahwa Orang memiliki Alamat, menganggapnya sebagai terpisah secara konsep, dan membuat tabel Orang dan tabel Alamat, menghubungkan Orang ke Alamat dengan referensi FK ke AddressID. Skema seperti ini lebih mudah untuk diubah jika sifat hubungan berubah; tanpa membuat atau menghapus seluruh tabel data "lebar", hubungan antara Orang dan Alamat dapat dengan mudah dimodifikasi dari 1: 1 ke 1: N ke N: N.

Tidak ada banyak fokus pada desain di depan saat bekerja di bawah Agile, jadi saya tidak melihat ini sebagai masalah besar, tentu untuk rilis pertama.

Sulit untuk mengomentari sistem yang memiliki 700 tabel yang belum saya lihat, mungkin perlu semuanya, tetapi bisa juga karena database belum dikelola dengan cukup baik.

Bahkan di bawah kelincahan, untuk sistem besar, sangat umum untuk tetap memiliki seseorang / tim yang bertanggung jawab atas skema tersebut.

Jika mereka sering melakukan perubahan seperti itu - terutama menjatuhkan tabel dan kolom dalam aplikasi langsung - yang sepertinya merupakan tanda tidak berpengalaman. Itu tidak ada hubungannya dengan proses apa pun yang mereka klaim untuk diikuti. 'Agile' bukan alasan untuk tidak duduk dan berpikir tentang data yang perlu Anda simpan dan bagaimana hubungannya sebelum Anda mulai mengeluarkan kode. Jika mereka menemukan mereka mengubah lebih dari 10-20% dari struktur awal, bagi saya itu adalah indikator mereka tidak memikirkan semuanya atau mereka tidak memiliki banyak pengalaman menganalisis persyaratan dan mendesain database, sehingga mereka hanya mendapatkan terlalu banyak banyak yang salah di awal.

Walaupun kedengarannya seperti tim Anda memang hanya pengodean koboi, seharusnya tidak ada yang salah dengan kode atau basis data refactoring. Ini bukan pekerjaan yang hilang - itu beradaptasi dengan realitas yang baru dipelajari.

Saya menyarankan apa yang dibutuhkan tim adalah kotak pasir untuk mencoba perubahan, melakukan pengujian, memantulkannya dari pengguna, dan memutuskan apakah itu masuk akal. Pada titik itu, mengintegrasikan perubahan yang masuk akal - dengan pengujian regresi yang memadai - ke dalam skema Anda harus baik-baik saja.

Agile adalah tentang pengkodean, Database bukan kode. Mengubah basis data harus diperlakukan seperti merenovasi rumah. Orang-orang entah bagaimana mendapat kepercayaan bahwa tangkas berarti bertindak sekarang merencanakan kemudian, yang sama sekali tidak benar. Bahkan di bawah metode lincah waktu perlu diberikan untuk perencanaan, terutama untuk sesuatu yang sama pentingnya dengan desain database.

Pekerjaan terakhir saya adalah di tim seperti ini. Saat menggunakan proses proses tangkas berubah. Kadang-kadang perubahan berarti entitas yang ada membutuhkan atribut baru yang menghasilkan kolom baru di tabel yang sudah ada atau entitas yang sama sekali baru diperlukan menghasilkan tabel baru dengan hubungan ke tabel yang ada. Perubahan semacam ini datang bersama wilayah dan tidak dapat diabaikan hanya karena Anda tidak ingin menyentuh skema. Keberhasilan ditentukan dengan menjaga integritas data Anda saat bermigrasi dari satu versi database ke pengujian unit berikutnya dan yang tepat.

Cobalah untuk tidak membuat perubahan yang tidak perlu pada skema Anda. Misalnya, jika suatu fitur memerlukan tabel baru untuk dibuat, pastikan Anda puas dengan definisi tabel itu sebelum Anda memeriksanya dan meluncurkannya ke lingkungan pengujian Anda. Harus membatalkan perubahan ke skema basis data Anda setelah data Anda dimigrasikan bisa menyakitkan.