-2：一張單據和表的每條數據最好能夠有生命線，什麼時候來的，什麼時候變得，誰變得，怎麼變的，一直到他的使命完結（比如審批完成，那麼他就成爲歷史單據，以後只會有人查詢他了，關注點少了）
-1：開發應該知道每個表（每個頁面）都是那些值，什麼時候有值，什麼時候沒有值。不同角色，不同部門的人可以輸入什麼值以及怎麼控制。這種文檔如果清晰的話，會給後面接手項目的人很多方便。
0：最好有模板頁面功能，如果用戶輸入單據重複性比較高，那麼應該做一個 模板頁面功能，將每個用戶的單據按照他們的想法創建爲模板頁面，下次填寫頁面的時候直接選擇該模板頁面，然後修改裏面的字段即可，這裏要考慮好權限問題，簡單考慮，直接按照用戶控制，只能選擇自己創建的模板，或者別人分享給自己的模板。
1：一個網頁考慮後期維護，應該儘可能單一，最好不要很多功能服用一個頁面
2：頁面當中每個控件應該考慮到隱藏與顯示，可用不可用，每個控件最好應該可以提示出怎麼輸入，輸入錯誤應該有校驗信息告知用戶錯在哪裏
3：頁面的基本狀態應該是4個，insert，update，query，audit（審批）
3.1 insert頁面，要把最初的單據創建出來，
a.頁面字段的校驗問題
b.頁面每個控件的可輸入值的控制（比如不同角色的人或者不同部門的人下拉列表看到東西不一樣）
c.當然特殊情況可能也會有不同人輸入不同的字段值。比如領導直接填寫單子的話，金額只寫領導建議價格，此時審批流可能直接往後走，那麼此時下屬員工的建議價格字段可能就是空的。如果是財務直接分配預算金額的話，那麼可能員工建議價格和領導建議價格都不填寫，此時這條數據之後財務建議價格有值。
3.2update頁面
a.能不能改，那些能改那些不能改。每個控件的可輸入值是否需要和創建人的可輸入值一樣，如果不一樣，那麼創建人查看頁面的時候如何才能看到這個不在他可用範圍內的值，這些都得特殊處理
3.3query頁面
a.數據控制，行級控制和列級別的控制。比如按照部門控制，按照角色控制，按照用戶控制，能查看哪些單據。列級別的控制，打開單據查看後，能看到哪些字段，一般這點不用怎麼考慮，單據每次查看一般都是可以查看所有的。
b.普通的查看頁面是不應該能後修改單據字段的。
3.4audit頁面
a.每個審批節點人可能需要補充一些自己需要補充字段，也有可能會直接修改單據的所有字段。當然只要能夠改字段，補充字段都會涉及到值域的問題，就是可以輸入那些值。
以上所有的東西都儘量在項目初始，或者需求開始的時候把功能儘量封裝好，
目的：
a.前臺頁面寫起來儘量少寫邏輯判斷,或者有判斷的話，儘量封裝到一塊寫，比如js，body裏面的內容儘量乾淨純潔，可以寫一些註釋。比如採購合同和銷售合同80%字段一樣，但是儘量做成兩個頁面錄入。
b.代碼要很方便的根據頁面狀態和用戶角色部門等控制控件的各種屬性特效，不要每個頁面都是一大段控制代碼，將代碼提煉出來，封裝，每個頁面調用，這樣代碼更加好看。總結：讓前臺頁面的代碼更加好改，更加好開發，更加好閱讀，開發規範起來（具體在細寫），後續接手項目的人學起來也方便，否則頁面代碼越來越爛，每個接手的人都抱怨，然後自己又不得不繼續打補丁。