編碼設計在大型專案裡常常被搞得異常複雜，大多數是人為因素增加了複雜度。小型專案則往往走向另乙個極端，忽視編碼設計，在後續維護時發現資料隨著時間的推移越來越凌亂，無意中增加了維護成本同時介面友好度大幅下降。
大多數情況，往往是因為沒有專門負責呈現和分類的字段，所以才費盡心機設計編碼，以便讓其擔負更多的任務！
1、編碼分類
a、客戶是否可能接觸到此編碼，以及以什麼樣的形式接觸，比如，是否需要記憶？
b、此編碼是否有再次分類的可能 ？
c、此編碼是否有輔助字段，比如排序字段 ？
d、此編碼數量的預估變化幅度，未來會以什麼數量級的方式增長？
2、重要性
a、客戶操作方便最重要
b、系統健壯穩定
c、效率
d、程式設計師習慣最不重要
3、具體措施
4、技巧
a、考慮到所有可能性，達到整齊。比如訂單的運輸方式應該設定，這樣避免null的使用，而且不影響列表的使用，加上條件即可。null在很多時候都要特殊處理，因此商業規則無法普適，需要不斷修正。
設計 編碼 VS 設計 編碼
在1992年，jack w.reeves發表了一篇名為 code as design的文章，這篇文章可以在 敏捷軟體開發 原則 模式與實踐 一書的附錄中找到。這是幾近20年前的文章，但時至今日，類似的爭論仍未休止。好像是在 軟體架構設計 裡，在討論架構設計時，作者就點了一句 這總不能說是設計就是編碼...
專案例會提綱》關於系統設計與編碼
一些想法，請補充，沒有問題的話就發給大家參考 1 前段時間專案組主要精力投入在需調研上，目前進入設計編碼階段請大家在設計質量 規範 單元測試方面進一步加強，不斷提高專案組的整體實力和凝聚力，由各小組組長負責落實 2 設計人員做完資料庫設計 業務介面設計後必須在組內進行討論，從設計合理性 是否符合規範...
關於字元編碼
美國人首先對其英文本元進行了編碼，也就是最早的ascii碼，用乙個位元組的低7位來表示英文的128個字元，高1位統一為0 後來歐洲人發現尼瑪你這128位哪夠用，比如我高貴的法國人字母上面的還有注音符，這個怎麼區分，得，把高1位編進來吧，這樣歐洲普遍使用乙個全位元組進行編碼，最多可表示256位。歐美人...