專案是把php改版成java。從8月份開始做。現在的規模是研發40人，測試12、產品16。以前略少一點。分成5、6個模組開發。重點是一開始就加班，每天8:30，週六不休。也就是連續加了半年多。加班算調休。很多人的調休時間累計有幾個月了。

2月中上線。趕腳資金主流程沒出什麼大問題。交易金額沒什麼影響。客服、財務雖然意見大，吵吵也就完了，貌似先前預料落空了。

在我看來，專案特別不嚴謹，程式碼特別爛，一句話：Action當Service用，Service當DAO用，Action一個方法兩百行正常，Service呢每個方法只有一行，return dao.find()。。其他模組不熟好像可能好一點。因為每個Action呼叫N個Service，事務也自然加不了了。表單驗證都是js驗證，Action不管。唉，算了。

叫我維護這種專案，不如殺了我吧。來了4個月了，開始兩三個月，當作反面教材學了很多，真是難得的反面教材，但是現在什麼都學不到了。改那些bug特麼無聊的啊。。。

-------------------------------------------------------------------------------------------------------------------------------------------------

專案改進的步驟：

完善JS的輸入校驗與Action的輸入校驗。
登入註冊優化。
檢查事務控制。
新增資料快取。
有限度的優化。
頁面訪問Action的優化與Action訪問Service的優化。
命名的規範，包括類、頁面、方法名、訪問地址。
app業務層剝離，jar包程式碼全部寫進app-service。
同時開展核心模組的重構。

規範概要：

1：手機號碼、驗證碼都提供onblur()合法驗證，驗證提示顯示在輸入框後面。
2：表單提交時，先呼叫手機號碼、驗證碼的onblur()驗證一次，進入Action後，再驗證一次。
3：表單提交使用ajaxSubmit非同步提交，Action進行輸入驗證如果校驗錯誤，提示顯示在輸入框後面，保持一致。
4：非同步提交如果成功，跳轉頁面可以使用window.location.href等等進行跳轉。
5：頁面彈出、懸浮的樣式，參考註冊傳送手機驗證碼，或者修改頭像。
6：Action儘量只調用一個Service。
7：Action傳入Service的引數，只能包括頁面引數。其他由Service設定。
8：Action丟擲異常的處理。
9：Action呼叫Service必須捕捉異常。Service中不應捕捉處理異常，而應該丟擲，除非特殊情況。
10：insert方法返回值為String。
11：操作提示由Service返回，比如‘不可重複推薦’，Action取得提示，返回到頁面，頁面直接使用。
12：命名規則。Action、Service、Model等類名使用去nwd字首的全稱。頁面命名使用全稱的簡寫比如rp為字首。
13：方法名可以使用rp為字首。定義成員變數的Service名可以用rpService。
14：儘量不交叉修改程式碼。各個人的模組分清。也利於追究責任。
15：後臺驗證在最後一步做，前幾個步驟僅僅使用onblur驗證。
16：bug誰開發誰修改。
17：組長負責監督，解決難題，框架，不寫普通程式碼。
18：如果一個頁面包含幾個子模組，子模組分別交給成員做，入口的公共頁面應該由組長做。組長首先提供入口頁。
19：頁面、類的命名可以由一個人全部確定。風格統一。
20：開發應該從頁面開始，然後才是業務邏輯開發。應該首先完成全部檢視層。包括頁面跳轉。
21：功能點應該一個一個完成，完成後固定。絕對不允許一個功能做一半留到以後。
22：登錄檔單或其他表單的校驗、提交方式。錯誤提示的方式。

一些問題：

1：所有人的開發環境應該統一併且宣告。包括jdk、tomcat、編碼格式等。
2：模組要經常做整合測試。衝突儘早發現。
3：測試及早加入。遞進式開發。
4：開發資料庫與線上資料庫應該完全一致。尤其是表字段和唯一索引，差別越多，不利於開發更不利於上線。
5：資料庫庫名的設定。
6：app-website有很多資料不必每次去資料庫查。應該放在快取中。像友情連結、合作伙伴等。
7：應該鼓勵員工提意見。藉此考察技術能力等等。但不宜獎懲。
8：頁面Jsp的規範通告每個人。形成統一的介面風格。其次確定類的規範。
9：SQL 中的 LIMIT 應該使用佔位符
10：SQL中的COUNT可以簡化為自動查詢
11：app呼叫erp模組的service，高耦合度。兩個網站應該平行不相交
12：分頁查詢需使用分頁父類
13：DAO、SERVICE都不應捕獲一般異常，ACTION呼叫SERVICE時應放入異常塊
14：SERVICE如果返回提示資訊，應使用String返回值型別或者繼承包含oprResult的父類。
15：字典表放進快取
16：表單校驗必須在js和Contoller同時使用
17：memberDTO登入後放進session
18：關鍵、複雜的部分應該最先進行，然後測試更長時間
19：功能點應該一個一個完成，完成後固定，測試，再進行下一個。而不是大量功能同時進行，一起交付
20：新版本釋出時，應提供給測試詳細的變更列表。應記錄資料表大的改動。
21：必須建立程式碼審查。
22：所有出現的問題責任都在於領導。領導有必要提高技術人員的水平。
23：日誌不規範，查錯難。
24：上線應保證一旦失敗可以回覆到從前
25：可以分段上線。一次上一部分。核心部分不立即放開。
26：負載均衡、讀寫分離，開發測試要有線上完全一樣的環境。
27：與論壇、社群的登入註冊同步、發表回覆等，開發測試要有一套論壇環境。
28：上線前模擬正式域名切換，排查域名相關的問題。
29：測試伺服器的各種環境應該與線上完全一致。
30：銀行、第三方介面、實名認證介面等需要最早進行開發測試，然後保證穩固。
31：開會的學問。
32：培訓全面業務和技術。