Seberapa jauh kita harus mengganti nama kode dan data ketika nomenklatur pengguna akhir berubah?

Beberapa waktu yang lalu kami menambahkan fitur di mana pengguna kami dapat "Terima" gambar setelah ditambahkan ke antrian alur kerja. Ternyata, kami menggunakan istilah yang salah, dan pengguna sebenarnya "Menyetujui" gambar.

Mengubah Accept to Approve pada antarmuka kami mudah, cukup ganti satu kata. Tapi kami memprogram semua layer dengan kata "accept", dari nama kelas CSS ke nilai database.

• Kelas CSS yang mengubah tombol menjadi hijau: ".accepted";
• Metode model yang memverifikasi dan mengikat atribut kelas pada simpul DOM: "isAccepted";
• Atribut status JavaScript: Array dengan "tidak direview", "diterima" dan "diterbitkan";
• Kolom status Mysql: ENUM dengan "tidak ditinjau", "diterima" dan "diterbitkan";
• Nama uji;

Itu sepele (khususnya ketika Anda memiliki tes) untuk menggantikan sebagian besar penerimaan untuk menyetujui. Sedikit lebih sulit adalah untuk memigrasikan data, khususnya karena perlu disinkronkan dengan penyebaran.

Kasus spesifik ini sederhana, tetapi saya pernah menghadapi kasus serupa, namun lebih kompleks, selama karier saya. Ketika file juga diganti nama dan penyebaran terjadi di puluhan server, atau ketika caching proxy, memcached dan mysql terlibat.

Meninggalkan "diterima" di setiap lapisan lain kecuali antarmuka adalah ide yang buruk, karena pemrogram baru yang bergabung dengan tim mungkin tidak mempelajari alasan historis yang menyebabkan keputusan ini, dan ketika menerima -> setujui adalah kata-kata dekat dalam hal makna, jika itu diubah namanya menjadi "antrian untuk pertemuan status manajerial berikutnya", itu tentu tidak masuk akal. Dan rasanya jika kita berkompromi di sana-sini, dalam beberapa iterasi konsep antarmuka pengguna tidak akan memiliki kaitan dengan sistem internal, dan saya pasti tidak ingin bekerja pada sistem di mana setengah dari output tidak memiliki koneksi ke jeroan.

Jadi, apakah Anda selalu mengganti nama semuanya saat dibutuhkan? Jika ini terjadi pada Anda, dan Anda memutuskan bahwa pertukaran itu tidak layak, apakah itu kembali menggigit Anda? Apakah komentar kode atau dokumentasi pengembang cukup untuk menghindari masalah ini?

Bagi saya, yang terbaik adalah mengubah segala sesuatu yang terkait dengan item tersebut.

Ini adalah bentuk degradasi kode, dan sementara 1 item tidak diubah mungkin bukan masalah besar, itu menetapkan nada untuk basis kode.

Ini juga dapat menyebabkan kebingungan di masa depan dan mempersulit pengembang baru untuk memahami basis kode / domain.

Dari konten pertanyaan dan tag, saya akan anggap Anda menggunakan bahasa di mana-mana.

Dalam pengalaman saya UL sangat bagus tetapi, seperti yang Anda sebutkan, dapat menyebabkan tugas-tugas pemeliharaan tambahan seiring perkembangan bahasa. Ini, dengan sendirinya, bukan hal yang buruk. Tentu, itu tidak nyaman, tetapi juga diharapkan.

Apa yang biasanya saya lakukan (dan terlihat selesai) adalah:

• Refactoring 1-shot dimuka: Refactor semua lapisan aplikasi untuk mengadopsi bahasa yang diperbarui; atau
• catat hutang teknis: Anda dapat mengubah kode yang menghadap pengguna segera, dan kemudian catat tugas-tugas hutang teknis untuk membawa sisa lapisan aplikasi sejalan dengan bahasa yang diperbarui. Ini biasanya menghasilkan beberapa tugas yang membosankan (tetapi dapat dikelola). (Sempurna untuk 5 sore!)

Saya pikir kuncinya di sini adalah apa yang Anda gambarkan adalah utang teknis dan harus diakui.

Saya memiliki manajer yang berpendapat bahwa kita seharusnya tidak membuang waktu untuk tugas sepele seperti itu yang tidak menambah fungsionalitas yang terlihat. Inilah saat analogi hutang benar-benar berguna. Intinya begini:

Tim memilih untuk melakukan DDD dengan Bahasa yang Tidak Sama. Menyimpang dari pendekatan ini dengan membiarkan kode dalam keadaan tidak konsisten menambah kebingungan dan menghilangkan banyak manfaat yang diberikan DDD dan UL. Dalam istilah manajer, ini menambah biaya pada proyek. Kode menjadi lebih sulit (mahal) untuk dikelola, dan lebih membingungkan bagi pengembang baru (mahal).

Anda mungkin ingin melihat opsi Pelokalan (l10n). Meskipun mungkin tidak sedrastis pergi dari Inggris ke Spanyol, Anda berhadapan dengan istilah yang berbeda untuk konsep yang sama. Jika ini tampaknya biasa terjadi, maka menggunakan l10n dapat memungkinkan Anda untuk dengan cepat mengubah apa yang ditampilkan di antarmuka pengguna tanpa harus mengubah istilah yang digunakan dalam kode.

Dengan itu, cukup gunakan istilah dalam kode Anda yang paling banyak dipahami. Pilih nama dari domain sesuai keinginan pengembang dan mungkin mengharapkannya.

Ketika Anda menggambarkan ini dengan tepat, melacak perubahan nomenklatur pengguna akhir di setiap bagian sumber adalah investasi yang cukup. Namun itu pasti sepadan, terutama untuk produk berumur panjang yang dikembangkan oleh infrastruktur lengkap (dengan hotline, penguji, dll.)

Melacak nomenklatur pengguna akhir dalam sumber adalah investasi karena ada begitu banyak tipe komponen di mana ia muncul dan tidak ada tongkat ajaib yang bekerja secara bersamaan pada semua komponen ini. Mungkin mengembangkan tongkat ajaib, komponen demi komponen, adalah investasi yang menarik yang dapat Anda encer selama masa proyek.

Saya bekerja pada basis kode berusia 30 tahun di mana pergeseran antara nomenklatur pengguna akhir dan nomenklatur internal tumbuh sangat besar. Berikut adalah beberapa kelemahan dari situasi ini, yang semuanya menambah overhead pekerjaan semua orang:

1. Dengan tidak adanya kebijakan yang memadai, pengembangan baru cenderung menggunakan nomenklatur pengguna akhir saat ini. Dengan demikian, konsep yang sama dapat memiliki dua atau lebih nama dalam komponen yang berbeda. Karena komponen berinteraksi bersama, ini menghasilkan beberapa nama sinonim yang ada secara simultan di beberapa bagian kode lokal.

2. Ketika hotline / help desk dipanggil, mereka menuliskan cerita pengguna menggunakan nomenklatur pengguna akhir. Pengembang yang bertugas memperbaiki masalah harus menerjemahkan nomenklatur pengguna akhir untuk mencocokkan nomenklatur sumber. Tentu saja itu tidak diarsipkan, dan tentu saja berantakan. (Lihat 1.)

3. Ketika programmer debug kode, dia ingin mengatur breakpoint dalam fungsi yang relevan. Sulit menemukan fungsi yang sesuai jika nomenklatur pengguna akhir dan nomenklatur sumber tidak setuju. Bahkan mungkin sulit atau tidak mungkin untuk yakin bahwa daftar fungsi yang relevan bahkan lengkap. (Lihat 1.)

4. Dengan tidak adanya kebijakan yang memadai, pemeliharaan sumber menggunakan nomenklatur usang akan dari waktu ke waktu menempatkan nomenklatur usang ini di depan pengguna lagi. Ini menghasilkan kesan buruk dan menyebabkan overhead.

Saya sudah melacak dua hari lamanya tempat di mana beberapa data dibaca dari database dan disuntikkan dalam beberapa komponen basis kode ini. Karena apakah saya atau siapa pun di perusahaan tempat saya bekerja dapat menemukan nama yang mengarah ke tempat ini, saya akhirnya menolak dan memutuskan untuk mencari solusi lain untuk masalah itu.

Meskipun biaya lebih dari [1] dua hari pemeliharaan tanpa menghasilkan apa-apa (tidak ada pengetahuan, tidak ada perbaikan, tidak ada) mungkin seburuk yang bisa didapat, perbedaan antara nomenklatur pengguna dan nomenklatur sumber menambah overhead pada banyak tugas rutin dalam pemeliharaan sebuah perangkat lunak.

Penting untuk berkomentar bahwa biaya overhead tumbuh dengan perusahaan yang memproduksi perangkat lunak, di sebuah organisasi besar, laporan masalah tidak akan tiba di meja Anda sebelum dipertimbangkan oleh beberapa rekan kerja dan perbaikan mungkin akan diuji.

[1] Karena lebih dari satu pengembang terlibat.

Saya tidak selalu mengganti nama kode dan data karena beberapa paket dibagi di antara pelanggan. Mereka pada dasarnya menggunakan hal yang sama tetapi menyebutnya berbeda. Contohnya, dalam CMS, satu klien memanggil pelanggan mereka "Pelanggan" dan yang lain menggunakan "Klien". Jadi kami mengganti Pelanggan dengan Klien di permukaan untuk satu klien, tetapi CMS akan selalu menjadi Sistem Manajemen Pelanggan.

Contoh lain adalah manajemen Pengguna dengan ketentuan seperti izin vs daftar kontrol akses, admin vs manajer, dll. Ini dapat membingungkan bagi pendatang baru tetapi untuk komponen inti seperti itu, biasanya ada pengembang inti yang memastikan bahwa komponen tersebut bekerja untuk semua klien dan juga mudah diterapkan oleh pengembang lain (misalnya dengan membuat label yang dapat dikonfigurasi).

Mungkin membantu untuk berpikir bahwa jika Anda melakukan perubahan ini, mudah-mudahan Anda tidak perlu melakukannya lagi jika bagian yang sama digunakan oleh pelanggan lain, pada dasarnya mengubahnya menjadi suatu produk.