[請益] 欄位或是變數改名

看板Soft_Job作者 (漫步在雲端)時間2年前 (2021/08/13 01:18), 2年前編輯推噓15(16推 1噓 33→)
留言50則, 20人參與, 2年前最新討論串1/1
這邊想請問各位前輩系統維護上常常遇到的一個問題 就是程式中的變數或是資料表欄位命名的"變更" 我不確定是不是一開始我的設計的想法就錯了 通常我在設計時，會將使用者的操作"畫面"與系統中的命名盡量保持一致， 討論起來比較有共通的語言，尤其是在一些專有名詞的欄位命名上。 Ex: 客人提到要記錄XXXX No.，欄位或是變數的名字就會是xxxx_no ---------------------------------------------------------------- 但是系統維護久了，使用者想要變更"顯示名稱"的需求肯定是會出現 有的關聯已經散到各處，要把系統變數或資料表欄位都修改太勞師動眾。 我通常都只把i18n顯示的文字改掉就算了。 只是日積月累的修改，最近發現反而原始的用意消失了，還造成了一些另類的困擾 比較麻煩的例子是，畫面上原本有OOO ID & OOO No. 因為各種理由，他們想要把 OOO ID 跟 OOO No.的Label文字對換 (原本的ID想改為稱做No., 反之No.想改叫做ID) 對使用者來說，只是改個顯示文字而已，應該可以"秒改"。 但這種狀況在後續維護的困擾就非常大... 尤其是新成員加入專案時，非常容易出現以下狀況 使用者：請你可以幫我查一下資料庫 OOO ID 是 "0003"的修改時間嗎？ 新成員：資料庫查不到這筆資料喔！ 使用者：怎麼可能！我畫面現在就正在看阿#$%^&*( 新成員：@#^*($$，這欄位是哪個白癡命名 但是不可能系統整天隨著變更名稱的需求，就一起進行變數或欄位名稱修正。 我相信修改顯示文字的需求應該是很常見。 想請教各位有經驗的前輩們 是我在一開始的設計方向就錯了嗎？ 或是有建議什麼其他的方法可以解決或避開這種問題呢？ 感謝~ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.173.219.85 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1628788691.A.350.html
推
08/13 01:45, 2年前 , 1F
visual studio 可以全部改名. 如果你是要這個得話.
08/13 01:45, 1F
→
08/13 01:54, 2年前 , 2F
map
08/13 01:54, 2F
推
08/13 01:54, 2年前 , 3F
資料庫名稱要修改不是掛個維護更新就好了? 不難吧
08/13 01:54, 3F
→
08/13 01:55, 2年前 , 4F
你講的ID換NO這種狀況我會選擇拒絕這個需求
08/13 01:55, 4F
推
08/13 01:58, 2年前 , 5F
你要設計的是人 不是程式
08/13 01:58, 5F
推
08/13 02:29, 2年前 , 6F
domain driven design 看一下 統一語言的重要性
08/13 02:29, 6F
→
08/13 02:31, 2年前 , 7F
id跟no調換的需求聽起來就很有問題 你怎麼能保證id是
08/13 02:31, 7F
→
08/13 02:31, 2年前 , 8F
連續遞增的
08/13 02:31, 8F
→
08/13 02:32, 2年前 , 9F
一開始就不應該為了配合 XXXX No. 而把欄位或變數命名成 xx
08/13 02:32, 9F
→
08/13 02:32, 2年前 , 10F
xx_no
08/13 02:32, 10F
→
08/13 07:58, 2年前 , 11F
id可以換no？ 這通常是key值，你該電的是user
08/13 07:58, 11F
→
08/13 08:46, 2年前 , 12F
這需求根本不合理，換了只是自找麻煩
08/13 08:46, 12F
推
08/13 09:06, 2年前 , 13F
你們客戶的程式不是寫中文嗎…
08/13 09:06, 13F
→
08/13 09:06, 2年前 , 14F
我也覺得i18n改掉就好
08/13 09:06, 14F
→
08/13 09:06, 2年前 , 15F
新成員教育一下就好
08/13 09:06, 15F
推
08/13 09:30, 2年前 , 16F
改顯示名稱為什麼要改資料庫欄位名啊?
08/13 09:30, 16F
→
08/13 09:30, 2年前 , 17F
通常顯示名稱都寫死在前端，或是用一個欄位另外存
08/13 09:30, 17F
→
08/13 09:31, 2年前 , 18F
這樣要改名時改那個欄位就好了
08/13 09:31, 18F
推
08/13 12:02, 2年前 , 19F
多國語系本來就是分開的，客戶說字串就去查多國語系
08/13 12:02, 19F
推
08/13 12:22, 2年前 , 20F
名稱儘量一致是對,但前端的顯示名稱要另外存
08/13 12:22, 20F
推
08/13 12:43, 2年前 , 21F
把 id 弄給使用者知道往往就會有這些狗屎事情發生
08/13 12:43, 21F
→
08/13 12:59, 2年前 , 22F
id和no調換這種事永遠不該發生，發生了代表你一開始做錯
08/13 12:59, 22F
→
08/13 13:05, 2年前 , 23F
在你第一次聽到XXX No.時，你就該確定這是那個domain通用的
08/13 13:05, 23F
→
08/13 13:06, 2年前 , 24F
名詞還是只是那個人的習慣說法，這個XXX No.實際指的東西是
08/13 13:06, 24F
→
08/13 13:10, 2年前 , 25F
什麼性質，你是對domain設計不是在幫特定人拉資料庫
08/13 13:10, 25F
推
08/13 15:01, 2年前 , 26F
上面說的對，欄位名稱應該是針對 domain 來命名
08/13 15:01, 26F
→
08/13 15:02, 2年前 , 27F
前端要顯示成什麼名稱，是另外的事情，你把它弄成同件事情
08/13 15:02, 27F
→
08/13 15:02, 2年前 , 28F
才會有現在的困擾
08/13 15:02, 28F
噓
08/13 15:11, 2年前 , 29F
簡而言之，設計不夠抽象，你反而將實作綁死在UI上，
08/13 15:11, 29F
→
08/13 15:11, 2年前 , 30F
這就是你犯錯的地方。
08/13 15:11, 30F
首先感謝各位的回覆與建議，其實我顯示的文字與程式結構是有分開的 可以在不用變動程式碼的情況下，修改i18n設定檔，就可以調整顯示的文字。 不過有兩件事情我的確沒有做到，或是比較難做到... (1) 拒絕ID <-> NO 這個需求，我可能會被電爆 Orz (2) 常常因為需求的急迫性，我的確沒有去確認這個"名詞"到底是代表 Domain還是該使用者的習慣用法 (Ex: 這個需求很急，下午就要用) 不過也想請問一下，回文中有提到的所謂欄位名稱應該跟著Domain， 而前端顯示是另外的事情。有點不太明白這個含意，是否有什麼例子呢？ 再次感謝大家的解答！ ※ 編輯: cloudgoogle (1.173.219.85 臺灣), 08/13/2021 21:14:16
→
08/13 21:43, 2年前 , 31F
畫面顯示完全跟DB不會有關聯阿
08/13 21:43, 31F
→
08/13 21:44, 2年前 , 32F
簡單說你用同樣DB 可以刻出完全不同介面的前端
08/13 21:44, 32F
→
08/13 21:45, 2年前 , 33F
所以前端怎麼取名怎麼會被資料欄位影響呢
08/13 21:45, 33F
推
08/13 21:48, 2年前 , 34F
不可能系統整天隨著變更名稱的需求，就一起進行變數
08/13 21:48, 34F
→
08/13 21:48, 2年前 , 35F
或欄位名稱修正 確實是這樣 但你的案例不只是改個名
08/13 21:48, 35F
→
08/13 21:48, 2年前 , 36F
字 兩個欄位都對調了 你不覺得這就反應了後端沒有正
08/13 21:48, 36F
→
08/13 21:48, 2年前 , 37F
確消化domain的知識？你又何必一定要抱著設計錯誤的
08/13 21:48, 37F
→
08/13 21:48, 2年前 , 38F
資料庫dchema
08/13 21:48, 38F
推
08/14 11:38, 2年前 , 39F
NO跟ID顯示就應該是字串，為什麼跟資料庫有關
08/14 11:38, 39F
推
08/14 12:26, 2年前 , 40F
改顯示名也不會差到天南地北呀，所以變數欄位不用改
08/14 12:26, 40F
推
08/14 13:17, 2年前 , 41F
我猜資料庫關聯沒設計好，照理說你要有一個 系統ID
08/14 13:17, 41F
→
08/14 13:18, 2年前 , 42F
再來才是客戶要求的ID，之後客戶有什麼需求就不會動
08/14 13:18, 42F
推
08/15 02:27, 2年前 , 43F
兩個欄位Label互換，但資料卻不用互換，不是你搞錯
08/15 02:27, 43F
→
08/15 02:27, 2年前 , 44F
就是客戶弄錯，你搞錯的話讓新人抱怨一下也就認了，
08/15 02:27, 44F
→
08/15 02:27, 2年前 , 45F
客戶搞錯的話就笑笑就好，反正改天可能又有各種理由
08/15 02:27, 45F
→
08/15 02:27, 2年前 , 46F
要改回來
08/15 02:27, 46F
推
08/15 03:25, 2年前 , 47F
推原PO，這問題蠻有趣的。能否更詳細的描述一下xxx_no和
08/15 03:25, 47F
→
08/15 03:25, 2年前 , 48F
xxx_id所儲存的內容和格式是什麼、以及後來決議調換的理
08/15 03:25, 48F
→
08/15 03:25, 2年前 , 49F
由是什麼？我覺得這個問題的詳細細節可以幫助討論，因為
08/15 03:25, 49F
→
08/15 03:25, 2年前 , 50F
這樣兩個變數名稱完全調換的例子真的蠻少見XD
08/15 03:25, 50F
‣ 更多 cloudgoogle 的文章
文章代碼(AID): #1X5LVJDG (Soft_Job)