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


50

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?


6
Seperti banyak hal dalam pemrograman, ini adalah kompromi. Anda membuat keputusan berdasarkan pada keuntungan dan kerugian relatif untuk mengganti nama, atau membiarkannya seperti itu.
Robert Harvey

1
Saya akan menggunakan ini sebagai kesempatan untuk meningkatkan peralatan Anda. Mulailah dari premis bahwa ini seharusnya mudah, cari tahu mengapa tidak, dan pastikan itu akan lebih mudah saat itu terjadi. Misalnya, penyebaran otomatis akan membuat masalah seputar sinkronisasi data dan kode dalam produksi menjadi lebih mudah.
Singletoned

Saya hanya perlu berpikir tentang migrasi data dalam db. Jika 1000 rekaman, tidak diragukan lagi. Migrasikan! Jika itu 10.00000 dari yang mungkin saya pikirkan. Tetapi masih berpikir bahwa 1 juta pembaruan sederhana akan sangat cepat. Semua hal lain yang Anda sebutkan adalah ganti nama untuk saya.
Piotr Perak

Data seharusnya tidak perlu dimigrasi untuk ini, harus menggunakan ID (atau indeks untuk enum?) Dari MySQL, bukan teks ...
Izkata

Jawaban:


31

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.


8
+1. Satu-satunya hal yang akan saya tambahkan (dan telah ditambahkan dalam jawaban lain) adalah istilah "utang teknis." Anda benar mengatakan ini adalah degradasi kode. Biaya degradasi ini, bagaimanapun, bukan 1-off. Sebaliknya, itu akan membuat bekerja dengan kode semakin sulit dari waktu ke waktu.
MetaFight

14

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).


6

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.


2
Saya pikir OP berbicara tentang masalah yang berbeda. Rintangan yang ia gambarkan tampaknya berasal dari penggunaan Bahasa yang Tidak Berfungsi ( c2.com/cgi/wiki?UbiquitousLanguage ). Bila menggunakan UL Anda benar-benar tidak ingin kode Anda untuk menggunakan bahasa yang sama (kata benda, kata kerja) sebagai UI.
MetaFight

3
@MetaFight Tergantung filosofi saya. Misalkan ide Kode sebagai Komunikasi, Anda sedang menulis sesuatu yang memberi tahu sistem dan pengembang lain apa yang Anda ingin sistem lakukan. Jika klien tidak akan menggunakan kode, maka saya mengusulkan untuk menulis kode menggunakan bahasa yang paling intuitif bagi para pengembang, dan kemudian menerjemahkan UI untuk para pengguna. Ada dua audiens yang berbeda. Jika klien Anda berbicara bahasa Spanyol, dan Anda bahasa Inggris, apakah variabel Anda akan ditulis dalam bahasa Spanyol atau Inggris? Jadi saya mengusulkan l10n sebagai cara untuk melayani kedua pemirsa.
Chris

2
Kasus lain untuk l10n adalah ketika pemasaran memutuskan untuk menciptakan istilah mereka sendiri.
Bart van Ingen Schenau

@ BartvanIngenSchenau hrm, itu adalah sesuatu yang saya belum pernah berurusan dengan diri saya sendiri, tetapi jelas kemungkinan. Dalam hal ini saya dapat melihat bagaimana l10n dapat berguna ketika bahasa yang digunakan tim dan Ahli Domain berbeda dari bahasa yang dapat dipasarkan. Sangat menarik.
MetaFight

Saya ingin tahu mengapa pemasaran tidak terlibat pada awalnya, jujur. Saya juga ingin tahu di lingkungan mana Anda bekerja di mana pakar domain tidak secara langsung terlibat dengan pelanggan. Agaknya pelanggan Anda harus menggerakkan nomenklatur dan lebih lanjut departemen pemasaran Anda harus menggunakan istilah yang pelanggan Anda akui sebagai bermakna.
RibaldEddie

6

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.


0

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.

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.