《美國新聞與世界報道》(U.S. News & World Report)網站27日以“‘尼德蘭’(Netherlands)不想讓你再叫它‘荷蘭’(Holland)”爲題報道稱，自2020年1月起，“荷蘭”這一名稱將被停用。
作爲一個旅遊愛好者，第一個想到的是：以後買機票去"荷蘭"要找"尼德蘭"了。
作爲一個教育從業者，第一個想到的是：以後所有需要回答"荷蘭"的題都要寫"尼德蘭"了。
作爲一個資深程序員，第一個想到的是：我的程序還能正常運行嗎？用戶填寫“尼德蘭”是否會報錯？查詢的結果中是否還是有“荷蘭”？
經過深思熟慮，我得出結論：我的程序可以正常運行。因爲我的程序裏面“荷蘭”使用NL表示，只是一個Code。感謝Code Name的設計，讓我在荷蘭改名的時候可以安心回家。
不過這個讓我想到了另一個東西BU:Business Unit，這個系統內有三個BU：PCG、DCG、MBG。系統在處理BU信息的時候直接將PCG寫到了數據庫中。我不擔心萬一哪天PCG變成PCSD怎麼辦，因爲——已經發生了(!_!)。現在每個特性都會出現這樣的問題：
-
用戶選擇PCSD查詢條件，結果查不到結果。
-
用戶下載了一堆文件裏面出現了PCG，而不是想要的PCSD。
-
用戶上傳了一個PCSD的文件，結果查不到PCSD的數據。
整個項目深陷BU的問題，不能自拔，每個交付的特性，不在BU上出兩個問題都不正常。
我深刻的體會到：無論業務看起來多麼簡單，數據量多麼少，一定要分析一下——這個會變嗎？會變一定給它一個Code。
有人可能會想：下載的時候用戶可不想看Code，爲了下載方便，我把Name和Code一起存起來。
這個嘛，讓我們從長計議。先請用戶回答一個問題：您看歷史的時候到底想看到什麼？類似發往荷蘭的快遞，2019-12-01收貨，2020-01-01查看這個快遞的時候，到底應該看見“荷蘭”還是“尼德蘭”？
-
如果用戶的答案是“尼德蘭”，咱們還是不要存Name了，畢竟我們使用Code就是爲了隔離變化，如果我們把Name也存起來 ，豈不又回到了最初。而且，增加更新Name的功能也不簡單，執行更新過程還需要時間。
除了Code的Name不建議存起來，還有一些關係信息也不建議存起來，類似國家所屬的地區。說到這裏，我一下子想到了很久很久以前，項目上的人都以爲一個國家所屬的區域不會變，然後爲了搜索方便，我們把國家所屬的區域編號也存了起來。就是怎麼巧，兩年後，歐洲一些國家所屬的子區域調整了。開始用戶反映數據不準確，後來我們發現是國家所屬區域變化了，我們花了一週時間更新完所有歷史數據。用戶表示對我們的反映速度不滿意。
-
如果用戶的答案是“荷蘭”，那我們就要考慮一下，這個是一個快照吧？是否應該給“尼德蘭”一個新的Code更好呢？這個時候“尼德蘭”和“荷蘭”可能根本就不是一個東西。
假如“荷蘭”改名“尼德蘭”的原因是：一小撮有組織有預謀的不法分子，在某某廣場，高呼XXXXX，並最終奪得了政權。雖然國土還是那些國土，但是新政權可不承擔原來政府的承諾，類似舊政府爲了鎮壓不法分子在國際上的借債，新政府肯定不認。作爲一個國際借款公司，必須給“尼德蘭”一個新的Code。當然如果是一個物流系統，還是採用方案1比較合適。
總結下來就是：
-
一定要給可變內容一個Code。麻煩一小步，省事一大步。
-
不要輕易採用冗餘存儲方案。
-
如果冗餘存儲要提供更新機制。