Kami sudah memiliki produk yang tahan lama selama sekitar 8 tahun sekarang. Seiring waktu, nama konsep dan entitas berubah. Haruskah kita memasukkan pekerjaan untuk mengganti nama semua basis kode dan tabel dan kolom basis data agar sesuai dengan nama baru ini?
Apakah ada studi yang dilakukan tentang ini atau beberapa praktik terbaik yang diterbitkan?
Terima kasih
Jawaban:
Ketidakcocokan antara nama internal dan eksternal pasti berbau. Seperti yang ditunjukkan Rinzwind, homofon dan sinonimnya berbau paling buruk.
Pertanyaan nyata yang perlu Anda jawab adalah: Berapa biaya / manfaat tradeoff dalam melakukan perubahan?
Biaya tidak berubah adalah kurva belajar yang lebih curam untuk anggota tim baru dan peningkatan kemungkinan bug di masa depan. Biaya perubahan adalah waktu yang jelas terlibat, kurva pembelajaran baru untuk orang-orang tua pada proyek, dan kemungkinan bug baru.
Jika Anda berharap memiliki jumlah anggota tim baru yang relatif besar, lebih masuk akal untuk melakukan perubahan. Jika Anda tidak mengharapkan pergantian, tim saat ini tidak cenderung bingung, dan tim puas dengan status quo, maka tidak masuk akal untuk mengubah nama hal-hal.
Jika kode ini diharapkan dapat hidup untuk waktu yang lama dan akan ada pengembang baru yang mengerjakannya, saya akan melakukan perubahan.
Ini bisa sangat membingungkan dan memakan waktu bagi pengembang baru untuk masuk ke dalam proyek dan menemukan nama-nama entitas menyesatkan.
Ada juga argumen yang valid dari ... Jika tidak rusak, jangan memperbaikinya.
Sehubungan dengan pertanyaan kedua Anda, saya tidak mengetahui adanya studi yang dipublikasikan atau praktik terbaik. Sehubungan dengan pertanyaan pertama, saya dapat menawarkan beberapa pengamatan dari pengalaman pribadi dengan produk yang tahan lama serupa di mana nama-nama 'internal' dan 'eksternal' kadang-kadang berbeda.
Nama yang ingin saya perbaiki adalah "homofon", di mana satu nama digunakan baik secara internal maupun eksternal untuk hal-hal yang berbeda . Ini dapat benar-benar membingungkan, terutama jika kedua hal tersebut tidak sepenuhnya berbeda (sehingga konteks tersebut membantu ambigu). Salah satu (abstrak) contoh itu dalam pengalaman pribadi saya adalah di mana secara internal Anda memiliki sesuatu seperti Fooyang merupakan kumpulan dari banyak FooEntity; secara eksternal, hanya yang terakhir yang terlihat dan disebut "Foo". Butuh beberapa saat untuk mencari tahu bahwa ketika manual pelanggan berbicara tentang beberapa "Foo" itu sebenarnya berarti banyak FooEntity(dalam satu Foo), jika itu masih masuk akal bagi Anda.
Kedua, saya ingin memperbaiki "sinonim" di mana beberapa nama eksternal telah digunakan secara internal. Seperti dalam nama variabel, bagian dari nama metode / fungsi dan sebagainya. Ini sering terjadi ketika pengembang mengimplementasikan sesuatu secara langsung dari deskripsi persyaratan pelanggan dan lupa untuk "menerjemahkan" nama-nama tersebut. Begitu itu terjadi, nama 'salah' juga cenderung menyebar, karena pengembang lain kebetulan menyalin / menempelkan beberapa kode untuk digunakan sebagai templat untuk kode baru misalnya. Sinonim-sinonim ini tidak terlalu membingungkan, tetapi dapat mengganggu karena jika Anda mencari kode untuk referensi apa pun, BarAnda harus ingat bahwa beberapa bagian dapat merujuknya sebagaiQux, jadi Anda harus mencari dua kali. (Ini mungkin lebih buruk dalam bahasa yang diketik secara dinamis daripada yang statis, karena Anda harus mencari pada bagian nama variabel / fungsi / ... daripada pada nama jenisnya.) Adapun kasus sebaliknya “sinonim ", Di mana nama internal telah digunakan secara eksternal: ini cenderung tidak sering terjadi, karena pelanggan mendukung karyawan dan sebagainya biasanya kurang mengetahui nama-nama internal, meskipun saya menganggap itu membingungkan bagi pelanggan ketika itu terjadi.
Jika Anda dapat menghindari atau memperbaiki setidaknya dua situasi di atas, saya tidak yakin apakah Anda harus sejauh membuat semua nama internal sama dengan yang eksternal. Mungkin ada alasan bagus mengapa nama-nama internal juga tidak berubah ketika nama eksternal dibuat berbeda dari yang internal. Dalam pengalaman pribadi saya, alasan bagus itu adalah kebutuhan untuk mendukung versi produk yang lebih lama; bisa jadi sulit untuk menggabungkan perbaikan bug dari versi sebelum-nama-pembersihan-ke versi terbaru jika banyak kode harus diubah.
Ini masalah yang cukup umum. Sejumlah proyek yang saya kerjakan menggunakan nama kode alih-alih nama produk (yang mungkin belum diputuskan pada saat itu), dan menggunakan terminologi yang sangat berbeda dalam kode daripada apa yang ditampilkan kepada pengguna. Saya mungkin akan membiarkan apa-apa, kecuali jika Anda sedang melakukan re-bertujuan besar-besaran dari kode atau jika ada sesuatu yang menyebabkan masalah khusus. Tidak ada gunanya mengecewakan gerobak apel. Juga, siapa bilang 5 tahun dari sekarang tidak akan ada perubahan lagi? Dan kemudian Anda harus melalui penggantian nama lagi. Dan jangan lupa, itu juga mempengaruhi dokumentasi kode terpisah yang mungkin Anda miliki (API yang diterbitkan), yang bisa menjadi masalah yang sangat mahal jika dicetak (hard copy).
Saya menemukan bahwa seringkali entitas "pemasaran" tidak sesuai persis dengan entitas internal. Dalam kasus seperti itu, lebih masuk akal untuk memperkenalkan entitas pada tingkat abstraksi yang berbeda, yang membuat perbedaan terminologi menjadi titik diperdebatkan.
Misalnya, kami memiliki model yang mewakili hierarki. Setiap level dalam hierarki memiliki istilah yang terkait dengannya berdasarkan bagaimana hierarki digunakan untuk memodelkan hubungan dunia nyata, tetapi secara internal tidak ada perbedaan perilaku dari satu level hierarki ke level berikutnya. Terminologi pada dasarnya hanya nama untuk tingkat itu dalam hierarki, jadi untuk simpul tertentu di pohon nama hanya menggambarkan apa simpul itu; itu tidak menentukan perilaku tertentu.
Juga, pohon itu multi-root, jadi ada beberapa node tanpa orangtua. Meskipun secara konseptual ada root (pada dasarnya akan mewakili alam semesta), dan memasukkannya ke dalam model akan banyak operasi yang lebih sederhana, tidak ada "istilah pemasaran" untuk itu.
Tentu saja, berbagai komponen dalam sistem kami menggunakan terminologi yang berbeda. Mereka dikembangkan pada waktu yang berbeda oleh tim yang berbeda, dan kami tidak memiliki kendali atas semuanya. Sebenarnya, pada titik tertentu, seseorang menambahkan atau menghapus level dalam satu komponen, dan level lainnya bergeser relatif satu sama lain. Tiga level yang sama diwakili oleh A, B, dan C dalam satu komponen, tetapi sebagai B, C, dan D di komponen lainnya.
Mengambil langkah maju dalam abstraksi dan hanya memodelkan segala sesuatu sebagai "simpul" atau sesuatu yang sama generiknya membuat model-model ini jauh lebih mudah untuk dipertimbangkan. Setiap node tahu apa itu "istilah pemasaran", dan tipe yang mewakili istilah pemasaran tertentu bisa tahu apa arti istilah itu dalam setiap konteks.