1. 服務器端必須提供輸入數據正確性的驗證，客戶端的Javascript驗證可以沒有。這是基於安全性的考慮，因為Javascript是很容易被繞過的，增加客戶端驗證只是為了減少服務器壓力、界面更加容易使用。
2. 適度使用Session，盡量不要在Session裏放很大的集合對象，以免內存消耗過大，因為很多用戶訪問的時候會產生很多的Session。參數傳遞應該盡量通過Request。熟悉HTTP有助於更好的理解Session、Cookie、Request等的機制。
3. 在帶有分頁的查詢界面，盡量不要使用POST方法來傳遞參數，POST傳遞的參數在地址欄裏是看不到的，刷新後會有重新提交表單的提示。使用GET方法傳遞參數要註意URL的長度不能超過1K。
4. 分層應該清晰，壹般目前我們分為View（Jsp或FreeMarker加上Action）、Bean（Service）、DAO這麽三層，即顯示層、業務層、數據層。記錄集ResultSet這種只能出現在DAO層中的對象不能出現在Bean（Service）層中，同樣HttpServletRequest這種只能出現在View層的對象也不應出現在Bean（Service）層中。這並不是絕對的。
5. 盡量使用簡單SQL，避免兩表以及多表聯查。多表聯查會導致數據庫壓力大幅增加，而且不利於在內存中對部分記錄進行緩存，代碼的重用性也難以提高。
6. 避免在循環裏執行findXXById這樣的方法，不如執行壹個findXXByIds這樣的方法壹次性把記錄取到Map裏。大部分有實際對象對應的表應該提供這樣壹個方法。
7. 如果使用最原始的jdbc編程的話需要註意資源的正確釋放，在循環裏new出來的Statement或者ResultSet就要在循環裏關閉。
8. 在編寫SQL進行查詢的時候，需要能夠判斷這個SQL是否已經使用了索引，避免全表掃描，必要的時候增加索引。
9. 在寫壹個方法前，首先查看有沒有相同功能或者很類似功能的方法已經有了，尤其是工具類方法，往往已經寫過了，避免重復代碼的產生，發現重復代碼及時進行處理。如果壹段代碼被重復使用兩遍或以上，那麽可以考慮專門寫個方法來放這段代碼，同樣多次使用的常量也應該專門定義出來。
10. 在壹個方法裏並不壹定只能有壹個return，如果已經有結果了盡早return，沒必要增加嵌套的層次，那樣會導致代碼可讀性不佳，但也不能return太多，代碼看起來比較舒服就可以了。
11. 不要滿足於能夠熟練的編寫DAO和Bean（Service）的代碼，相比較而言，後臺如果在成熟框架的支持下，編碼是沒有太大難度的，也不值得沾沾自喜，因為這是對Java研發工程師基本的要求。適當的培養壹下前臺的編碼能力，學會使用Dreamweaver。不要輕視界面，也別認為這是界面設計的事情，界面對用戶來說就是軟件，學會編寫CSS和調整界面對妳沒有壞處。
12. 非常明確Java和javascript作用的範圍，明確它們能做的事情。
13. 壹般很奇怪的現象都是由壹些低級錯誤引起的，如果妳查了壹段時間也沒有結果，那麽讓別人來查吧。
14. 不要用可能被修改的字段來做主鍵，那樣會讓相關記錄的更新成為壹個大麻煩。
15. 如果被迫使用Hibernate和jdbc混合操作數據庫的話，不要用Hibernate來做復雜查詢和統計。Hibernate用的不好的話，帶來的便利是非常有限的。
16. 數據庫中經常被讀取，但是很少修改的話，應該把這樣的數據讀到內存中用OSCache之類的緩存起來，然後定期或者觸發的去更新，有助於減少讀數據庫次數，提升性能。
17. 編碼的時候應該註意部署環境帶來的影響，這種影響包括操作系統不同帶來路徑的差異；應用服務器和數據庫服務器之間時間的差異；外網可能部署在多臺服務器上，放到Session裏的對象因為需要復制所以要實現java.io.Serializable接口等。
18. 盡量不要在jsp上編寫太多代碼，保持jsp的整潔很重要，用Dreamweaver打開不至於壹塌糊塗，根本看不出來這是個什麽界面。
19. 目前我們的項目壹般都使用Spring來管理數據庫事務，而且壹般都配置在Bean（Service）即業務層這壹層，應該註意要保持事務的完整性，不要把壹些應該放在壹起的操作分散在Action這壹層。相關的更新操作可以認為是壹個事務，比如：增加壹個家長，同時更新學生是否有家長的字段。
20. 在Spring的配置中，對於有些需要保持獨立事務的方法操作，比如生成主鍵等，應該聲明該方法為獨立事務ROPAGATION_REQUIRES_NEW。Bean（Service）裏如果拋出checked exception，事務默認是不會回滾的，需要加以聲明，比如<propkey="*">PROPAGATION_REQUIRED,-PassportException</prop>。
21. 在壹個Bean（Service）中引用其他Bean（Service）的時候盡量引用Bean（Service），而不是DAO。因為其他的Bean（Service）往往封裝DAO的操作後，又做了進壹步的完善，比如增加校驗等，所以應該重用這些方法，而不必要去引用DAO的方法來重寫這些操作。
22. 至少在Bean（Service）的接口定義上增加註釋，方便他人引用妳寫的方法。
23. 好好利用集合框架裏的Map、List、Set。尤其是HashMap、ArrayList、HashSet用的最多，這些類是多條數據操作的基礎，它們都不是線程安全的。
24. 現在跑的快的頁面，隨著數據量的增加，可能會變的很慢，所以應該意識到頁面可能變慢的原因，而不是現在看起來很快。影響速度的大部分原因是對數據庫的壓力太大了，在java代碼執行上花費很多時間的情況是不常見的。
25. 避免不必要的跳轉，如果頁面執行的足夠快，那麽中間的載入進度提示頁是不必要的，那樣會讓用戶覺得閃爍。
26. 註意頁面的文件大小，並不是每個用戶的帶寬都是非常理想的，文件小壹點，速度快壹點，總是感覺更好壹點。
27. 不要去修改用戶的瀏覽器，比如隱藏他們的地址欄、菜單、右鍵菜單等，這可能會引起部分用戶的反感。盡量不要使用彈出窗口，可能會被攔截。
28. 網站的權限控制至少應該保證有訪問權限的用戶才能訪問頁面，通過隱藏鏈接之類的方法是很不安全的，用戶看不見了並不表示安全了。權限的控制盡量使用框架裏的攔截器這樣的機制，而不是把權限控制代碼寫的到處都是。過濾器不宜過多的使用，不僅因為過濾器的作用範圍很難控制，而且容易引起頁面執行效果的混亂，錯誤不易排查。
29. 頁面裏大部分情況使用相對路徑，保持Action路徑層次和頁面壹致，這樣應用就可以發布在各種目錄下。