系統設計

1.一定要注意日志機制，并在項目設計之初就指定日志的方式，哪些地方記錄什麼樣的日志。

2.為什麼要适用全局的css，為什麼要設計類，來囊括所有的操作或者部分的操作，這些其實都在做一件事：控制。盡量多的内容在控制範圍之内，而不是随意散落，讓各個單體來自己決定是一件很難控制也很可怕的事情，越大的項目/機構這樣也就越危險。

3.做系統設計，一定要從劃分的子產品中跳出來，而是從子產品的内在的關系和對象的角度中來做分析和設計。所謂子產品是深層業務邏輯的表面展現，換言之是給客戶使用的，不是你設計師設計的東西。設計師關注的是根本的東西。比如成本系統中被劃分了成大學目管理，發票，項目，成本核算等子產品，但是我們看到究其核心是什麼？我們先來捋一下思路：成本系統的核心對成本的核算，核算來自于兩部分：成本系統本身的發票以及外系統（财務&ME），其實整個系統的處理核心，或者說源頭就在這裡，無論是項目管理，還是成本核算，歸根到底用的就是這些資料。不過還沒完，資料是有的，那麼這些資料的粒度是怎樣的呢？計算口徑是深層次了解資料源的關鍵。對于資料源的了解有很多元度，不同的項目有不同要求，對于成本系統而言，以飛機為機關的成大學目（維修任務級别）和費用類别（工時/材料/其他）是關鍵。基于此來如此設計，無論是資料庫設計，還是應用層設計都将會非常清晰。

4.系統設計和資料庫設計關系緊密，其中一個用處，如果你想要修改一處設計想要知道會影響那些業務，那麼你可以參看資料庫的設計，這個業務的表關聯那些表，這些表用都是和哪些業務關聯，即可知道受影響的業務了。

5. 對于操作的執行分析，要有一個Sense:執行這個操作有什麼限制。比如删除一張發票，如果這張發票已經放入了付款通知書那麼就不能删除。除非它首先從付款通知書裡面删除了，再回過頭來删除發票。在比如每月執行數的修改，一定要校驗執行數不能超過預提總額，至于這一點是否要校驗呢？值得商榷，限制很多情況是越少越好，伴随着業務的開展，會有很多意想不到的情況發生，限制這種限制反而會影響系統的易用性和健壯性。是以添加限制這一點，要慎行，要有确認的添加，而不是拍腦袋。

6.在需求分析階段，業務群，轉化為故事群，在設計階段将故事群轉化為對象群，再将對象群轉化為表群，總之要建立一個“群”的概念，群的概念就是既是單獨的個體，也是互相關林的個體，都是有背景的，被使用，同時也使用别人。群的概念提出目的是讓設計者，調研者在腦海中要對整體的設計，需求建立畫面，反複推演。

7.做業務分析一定要一條線（主幹），一棵樹（全貌），能夠了解整個系統的全貌，然後了解各個組成部分之間的關系，而不要有遺漏，是以作分析前提是做好全局認識，建立好系統樹，再來談系統分析。

8. 狀态-功能矩陣

對于彙總顯示的查詢，是不能通過點選一條記錄進行修改的（因為你不知道要修改那一條）。是以頁面有很多狀态，對于和一個狀态的改變要周遊其他的業務，是否狀态的改變導緻其他業務不能正常進行，加以校驗。是以細化頁面的時候需要兩張清單，狀态清單，業務（功能）清單，看看兩者的影響情況，姑且稱之為狀态-功能矩陣。接上，什麼叫做狀态，狀态就是不同将會導緻業務（操作）不同，屬性，就是不同不會導緻業務（操作）不同.

9. 修改/ 添加的設計

對于修改的方式有兩種：一種是下面是表格，然後點一下表格某一項，内容反倒上面去，然後修改；還有一種方式就是一堆的輸入框，直接修改，添加就是直接增加一行，這樣做的好處是對于使用者操作比較便利，但是對于背景程式處理而言怎是每一次都是先删除所有的項目（因為跟蹤字段修改本身就比較麻煩，而且無疑是頁面又增加了一種機制，增加項目的複雜性），然後重新建立。這樣做成本比較高，而且如果是需要記錄記錄檔的情況下，這種方式也不便于記錄真實操作。還有一種處理方式就是完全交給後來來判斷，傳回過去的資料是修改還是新增，但是這種機制造成背景的處理邏輯變得複雜，對于開發不利，一個儲存方法的職責太多了，處理太多，不易于維護，最好還是區分開來，由前台的分狀态處理比較好。

10. 異常處理和日志現行

異常處理和日志處理這兩部分十分重要，一定要重視起來，這兩個子產品應該是先行者。而且日志的内容應該分為兩部分：一部分是目前日志，應該隻有一條，友善開發者跟蹤本次異常，還有一個就是日志清單，記錄曆史資訊。因為我們看到開發人員發現了異常還需要首先重新運作，而且還不确定那裡除了問題，如果能夠先看日志，大緻确定問題點，然後再調試會提高開發效率。

另外，日志的輸出應該是可以打開關閉的，在測試開發階段，部分向文檔中寫日志的方式應該被打開，部署之後就關閉。

11.資料庫的寫操作處理

1）一定要對操作（修改，删除）的資料進行版本比較，避免髒資料問題；這個需要通過在架構中添加處理；

2）對于所有的寫操作一定要判斷傳回值，因為對于資料庫并發的情形，異常的情形很可能會出現修改/删除失敗的情況，是以需要讓使用者知道自己的操作是否成功了。這些都是封裝在架構裡面；

3）對于建立者，建立時間修改者，修改時間等等資訊有架構來處理更新；

4）要進行事務的設計；

12.業務邏輯裡面一定不能有長串的ifelse的判斷，這樣會阻擋業務的清晰，對于後來加入和維護閱讀代碼都很困難，對于這樣長串的處理需要抽象為對象進行封裝，再次抽離/分離到單獨的業務類中，或者一個單獨的私有方法。不要放到處理邏輯的主方法中，這樣會污染業務處理邏輯。

13.删除有兩類，對于有的過往的資訊，這類資訊将不再被使用（例如核算，歸類），可以采用邏輯删除的方式，這樣檢索的資料真實的反應當時的情況，比如工作流裡面的審批人；還有一類是要做限制：比如角色，如果一個角色配置設定給人了，如果你想要删掉一個角色，一定要把所有的該角色的使用者的角色重新指定，才能删除，無論是邏輯還是實體，因為這些人以後還是需要使用的。對于這一類元素可以考慮添加批量修改的功能。

 14.基于插拔設計的必要性：客戶想要把老空調的更新業務和消息推送業務，實作方式替換為黑水晶方式，我突然發現插拔式設計和好處了。插拔式需要接口統一，清晰，設計的重要性。