一、現在的公司有一部分電商業務，由於時間倉促，開始的設計原則就是，先有東西再說，做完了後期再優化。所以導致了現在很多的問題。
二、整體情況一時半會兒也說不清，單獨先開個文章記錄問題，後續再加東西。
三、首先是規範。
1. 資料庫。表的命名規範很隨意，開頭用t、tk、ts等等，英語和拼音混雜。表內的字段命名也很隨意，大小寫摻雜，英文和拼音摻雜。時間的問題，現在儲存的是varchar型別的，yyyy-mm-dd型別，這樣資料庫遷移性不高，其實一般是儲存毫秒數，即1970s到現在的毫秒數。索引什麼的也沒有利用。mybatis功能只用到了基礎功能，多表關聯或者子查詢關聯什麼的也沒有用上。在歷史版本的問題，沒有很好的記錄，當初想著搭建類似於flyway，不了了之。powerdesigner等工具也沒有利用起來。
2. 業務層的結構設計。
a. 先從最基本的角色和許可權來說。現階段其實只有角色沒有許可權，或者說許可權的作用表現得不那麼明顯。最近做的是店主和店員的角色設計，這是電商最基礎的功能，遠一點還有部門，這些都是要分配許可權的。但是現在的業務還沒有那麼複雜，但是一直以來店員的問題就存在。現在的設計只是為了解決問題而解決問題，單純的只是申請賬號，繫結到某個店鋪下，成為店員，區分業務，然後區別這個賬號下的操作屬於哪一角色。其實支付寶也有店員的功能，無非是切換一下操作頁面，是個人版還是商家版，或者，個人版還是店員版，這樣就能更簡單的解決操作問題。
關於入口設計，可以選用一些設計模式的東西，例如工廠模式，會簡化很多業務**。
這其實是小廠的通病，沒有規範化的流程，有時候就是拍腦袋想出來的功能，或者產品也在探索之中，在根據市場不斷地調整產品方向和功能。產品很急，那麼**端的資料模型設計就很急，乙個功能分幾個人寫，如果不能提前溝通好，在業務邏輯端就會產生很多重複**。（後期我們採用了mybatisplus，減少了一部分基礎的增刪改查的工作量）
c. 安全性
d. 單一登入問題
e. 推送問題
f. 文件問題
g. 論壇功能
未完....
關於場景服務的一些想法
最近由於遇到一些問題，老大們決定把場景顯示相關的 拆分出來用乙個獨立的執行緒去做 大概是實現乙個獨立的場景服務吧 感覺這樣挺好的，畢竟這部分功能本來就較為獨立。我對這部分內容還挺感興趣的，思考了一下，心裡有乙個感覺是比較好的解決方法，遂提筆記錄下來 先簡單說說背景 地圖場景是按格仔劃分的，每個格仔有...
關於資料許可權設計的一些想法
在各種系統中，要保證資料物件的安全性以及易操作性,使企業的各業務部門 職能部門能夠方便而且高效的協同工作，那麼乙個好的資料許可權管理設計就成為乙個關鍵的問題。雖然企業中各個單元的工作流程有所不同，處理的資料物件也有所不同，但是在組織結構 資訊的處理方式上具有很多相同的地方，這就為設計資料物件的許可權...
關於OCR，一些想法
ocr一般分為兩種 1，根據給定的字元特徵集合，提取未知字元的特徵進行匹配識別 典型例子 gocr 2，不知道字元特徵，但給出提取特徵的規則，通過機器學習training來獲取某個字符集的特徵集，對未知字元進行匹配識別。典型例子 tesseract 第一種方法簡單，在某些場合很高效，但比較侷限，字符...