1. 在頁面中，如果一組控件的狀態是互相關聯的。比如，如果隱藏就同時隱藏等。那麼就把它們放在同一個Panel中，這樣隱藏的時候直接對Panel操作就可以了。
2. 在編寫程序的時候，一點要進行數據合法性先判斷，避免一切可以避免的異常。特別是對Session,Application這些值爲null的時候的判斷。
3. 在ASP.NET頁面中，有些頁面由於被多種情況調用(比如，一個頁面可以爲多個角色使用，但是不同得角色可能顯示的內容有所不同)，那麼就很可能出現Page_Load中有大段的判斷代碼。這樣對測試和維護都造成了困難。可以考慮建立爲每種用戶建立一個特定的界面。然後通過將相同的控件全部用UserControl來替代，這樣就實現了頁面局部的重用和減輕了後臺代碼的複雜度。
4. 如果一個已有的類不能滿足要求，那麼有兩種方式。一種是繼承這個類，並重寫/添加一些新的方法；一種是新建一個類，這個類組合了幾個已有的類，通過這幾個類的協作來滿足要求。後者優先考慮。
5. 在使用“門面模式”的時候，應該根據一定的分類分別爲每個分類建立一個“門面”，而不應該整個子系統或者模塊只有一個統一的門面。這樣一個統一的門面裏面會很亂，方法會很多。而且當開發週期長的話，有一些方法可能你已經寫了，但是由於實在記不住，所以可能重複的開發了具有同樣功能的函數。比如Duwamish的結構中，其中BusinessFacade類庫中就分別爲客戶，訂單和產品三個實體建立各自的“門面”
6. 在顯示錶格的時候，有時候用戶要求數據一定要實時的更新。比較普遍的做法就是在更新了數據以後，再到數據庫把最新的數據取出來，重新的綁定到控件中(如：DataGrid)。但是如果數據量很大的話，這樣的話會造成網絡的傳輸負擔。所以你可以通過更新函數傳回一個標誌符。這個標誌符用來表示更新的操作是否成功。如果成功。我這裏用DataGrid來舉例，你就可以在ItemCommand命令中直接對顯示的信息進行修改。這樣就可以在不抓取新數據的情況下來實時的更新狀態。
7. 系統上線以後，用戶會對發現的問題和需要改進的地方進行反饋。而用戶使用的語言與程序員使用的語言肯定是有差別的。特別是對系統出現問題的描述上，用戶無法準確的描述出現問題的環境和具體的現象。這個時候系統就需要一個異常處理模塊。通過這個模塊，將系統出現的異常時的環境和錯誤信息保存起來。這樣可以有效大的幫助程序員來排除系統的缺陷。
8. 對於系統“容易改變的部分”和“使用廣泛”的部分一定要集中管理。這樣將便於維護工作。
9. 危險操作,如：刪除操作。一定需要有提示，讓人再審查一下自己操作是否正確。
10. 充分利用控件的ToolTip屬性(在HtmlControl中對應的是Title屬性)，這樣當用戶的鼠標指針懸停在控件上的時候就可以出現簡單的提示。這是很方便的，可以增加系統的友好程度。
11. 在進行數據驗證的時候，首選是Microsoft提供的驗證控件。
12. 如果不希望用戶使用多線程的下載工具，可以使用按鈕(Button)而不是超鏈接的方式進行下載。
13. 默認的情況下在下拉菜單中選擇一個值後，下拉菜單依然佔據着焦點。而現在的鼠標大都是帶滾輪的3D鼠標。在從下拉菜單選擇了值以後，如果用滾輪來翻頁有可能回改變下拉菜單中的值，從而導致了誤操作的可能性。這裏目前的解決方案是利用下拉菜單的onchange屬性。在從下拉菜單選擇了不同的值以後，自動將焦點轉移到另外的控件或者一個行藏控件上。這樣可以從一定程度上減少用戶失誤操作的次數。具體的代碼如下：
<script lanuage=javascript> function setFocus()
{
document.all.HIDDENCONTROL.focus(); //這裏HIDDENCONTROL是指在下拉菜單失去焦點以後得到焦點的 控件
}</script><select onchange = "setFocus"> <option>...</option> <option> ... </option></select>14. CheckList 是一個簡單而有效的檢查方式。頭腦風暴是必要的，但是一張優秀的CheckList不僅可以減少頭腦風暴的重複勞動，而且可以減少錯誤的發生。
15. 系統在進行需求開發的時候一定需要明確的問題：
A) 系統邊界；(可以通過對系統需要實現的功能點來描述系統應該完成什麼樣的內容。但是如果能在需求說明書中通過一段文字明確對系統的邊界進行說明是一種好的方法);
B) 系統的功能。(系統需要實現哪些功能點，每個功能點的操作者是誰一定需要明確，具體的操作對象);
C) 系統邊界檢查。(既然系統有邊界，系統需要正常運行需要有初始數據，這些數據如何從邊界外進入系統。系統需要產生數據，如何將這些產生的數據結果提供給邊界外的系統都需要明確，無論是webservice, 導出文檔的方式。)
D) 界面原型。(2008-7-28)
16. 我們寫需求，做設計(包括：概要設計、詳細設計)都是一個自上而下的過程。其實寫代碼也是，也是自上而下的過程，以ASP.NET爲例，先頁面，然後分解到業務邏輯和數據操作，並且逐層實現。這樣可以驗證代碼的完整性(可以覆蓋所有需要完成的功能)，並且不會應爲憑空想象而產生一些根本就不會引用的方法。至於產品和項目的關係，我覺得是相互關係，產品來源於項目，並且對項目產生影響。昨天和一個學Java的朋友聊天，他說在他們的源碼管理器(CVS)中存在主線和支線的概念，主線就是一個產品，而支線就是一個個具體的項目，那麼具體項目中的功能模塊經過分析以後可以被反射到主線(產品)中，然後再後續的項目中就可以使用主線對應的功能了。我覺得這個描述是一個很形象和具體的說法了。(2008-10-27)
17. 一個核心繫統能做什麼不能做什麼需要限定清楚，這樣才能知道那些是需要藉助核心完成的那些是需要重新根據項目寫的，否則會在寫函數的時候由於不知其歸屬而畏首畏腳。(2008-10-28)
18. 如果是涉及相對昂貴的操作，如：文件處理、數據庫訪問等。那麼在對應的方法中需要先儘量的對傳入的參數進行有效性的驗證，如果發現輸入參數存在非法值那麼需要通過異常的方式拋出。如果不是這樣的操作，如：純粹的邏輯處理，並且不需要對異常進行處理，那麼在編碼時就可以僅僅關注於邏輯，因爲如果參數存在非法值那麼系統也會以你預想的方式來拋出異常。(2008-11-6)
19. 在進行系統分析的時候，最主要的關係是分離對象(對象的職責)以及對象之間的關係。特別是在多人合作的基礎上，更需要先確定對象模型(比如：存在哪些對象，這些對象有哪些屬性和實現哪些方法)，然後確定對象的關係。這樣可以避免一些多人開發中可能僅僅看到自己當前業務對應對象一方面的信息的片面性。(2008-11-7)