我們大部分程式設計師編寫一個程式，總是要先進行一番構思，然後就一邊寫程式碼一邊除錯。可是，這種方法一般只適用於非常小的程式，根據軟體工程的特點，如果對所有程式都還按這種方法進行設計，是很不合理的。設計程式就像我們大樓，首先要設計圖紙，然後才動工。所以，對於個人編寫程式來說，基本應該遵循以下步驟：

　　1、問題分析：對我們要使用程式設計手段去解決的問題進行系統地分析，瞭解程式是要做什麼，要達到一種什麼樣的效果等。

　　2、結構設計：也就是對程式的整體框架進行設計，設計出我們需要使用的模組等等，並畫出流程圖（當然現在公司裡邊一般分工都很明確，一般有架構師來設計整體框架，但是我想我們每一個程式設計師也不會僅僅想一輩子做程式設計師吧！）

　　3、使用者介面設計：在此，我們要設計出用於與使用者互動的輸入輸出介面。（儘管在軟體開發中介面是由美工來完成的）

　　4、程式碼設計：在這個步驟中，我們要進行程式碼的編寫。（程式設計師往進去填寫程式碼，但不是就是讓你複製黏貼噢）

　　5、除錯：對程式中正在發生或可能發生的各種錯誤進行處理。（軟體測試工程師，有專門的測試工具，編寫測試指令碼）

　　6、維護：通俗地說，維護就是對程式進行升級，對原有錯誤進行修改。（運維）

　　對於以上幾個步驟，我想大多數人會認為程式碼設計最為重要，但如果程式的結構尚未清楚，我們在編寫程式碼的時候就會發生混亂，一個程式效能的好壞，主要還是取決於它的結構是否合理。因序設計中，我們要儘可能注意這一點，這樣才能使我們的程式更加完善。

　設計環境

　　一個良好的程式設計環境可以使我們在編寫程式時，不至於造成各種資源的混亂，還可以避免資源的浪費。建議大家要在放源程式的目錄下建立“Programs”資料夾；然後再以你要編寫的程式名和版本為名建立一個資料夾，用於存放整個源程式以及各種資源；最後，分別建立幾個資料夾，“Documents”：用於存放程式文件，包括流程圖等；“Resource”：用於存放圖片，聲音，影片等資源；“Debug”：用於存放除錯的程式。“Release”：用於存放最終釋放的程式。

  另外，最好再建立一個專門的資料夾，用於存放各種模組，以便能實現程式碼的重用，這樣，我們就不用在每次寫程式時，都重寫所有的模組，程式設計速度會有很大的提高。

　設計技巧

　　程式碼如果寫得很亂，程式便不易被閱讀與修改，所以，在編寫程式碼時要注意以下幾點：

　　(1)註釋：寫註釋雖然要佔用一定的時間，但在閱讀和修改程式碼時卻會節省很多的時間。所以，建議大家在定義一個函式時，在函式的第一行寫出函式的作用，再用一行解釋函式的引數，並在每個變數的定義語句後註釋出其作用。

　　(2)變數和函式的命名：每個程式都會使用很多的變數和函式，如果隨意命名變數與函式，每次使用時還得在變數或函式的定義語句處查出它的資料型別及名稱，而且隨意命名還會造成變數與函式重複定義。

　　建議大家使用匈牙利命名法，方法是：每個變數或函式的開頭都以其資料型別的縮寫命名，然後再加上代表這個變數或函式的作用的英文單詞簡寫共同組成變數或函式的名稱。例如：要定義用於計數的整型變數count，其定義語句為java：int icount;。以這種方法定義，不僅可以有效地避免變數與函式的混亂與重複定義，還可以保證資料型別的匹配。

　　(3)控制元件命名：如果在Windows下程式設計，你有可能會大量地使用控制元件，如果不對控制元件名嚴加管理，會造成很大程度的混亂，因此，建議在給控制元件命名時，以控制元件型別縮寫再加上代表這個控制元件作用的英文單詞的簡寫共同組成此控制元件的名稱。例如：你要命名一個按鈕控制元件，作用是進行刪除操作，那麼控制元件名可以命名為cmdDel。

  以下是一些總結技巧：

1.避免將多個類放在一個檔案裡面； 

2.一個檔案應該只有一個名稱空間，避免將多個名稱空間放在同一個檔案裡面;

3. 一個檔案最好不要超過500行的程式碼（不包括機器產生的程式碼);

4. 一個方法的程式碼長度最好不要超過25行;

5. 避免方法中有超過5個引數的情況。使用結構來傳遞多個引數;

6. 每行程式碼不要超過80個字元;

7. 不要手工的修改機器產生的程式碼;
        ( a)  如果需要編輯機器產生的程式碼，編輯格式和風格要符合該編碼標準;

       ( b)  Use partial classes whenever possible to factor out the maintained portions. 

8. 避免利用註釋解釋顯而易見的程式碼。

     (a)  程式碼應該可以自解釋(好的程式碼由可讀的變數和方法命名因此不需要註釋);

9.  Document only operational assumptions, algorithm insights and so on.   

10.  避免使用方法級的文件。

    (a)  使用擴充套件的API文件說明之。

   （b)  只有在該方法需要被其他的開發者使用的時候才使用方法級的註釋。（在C#中就是///）

11.  不要隨便使用final，構造一般用函式設定其值。只有固定的不改變的值才設為靜態變數，比如一個星期的天數；

12. 程式碼的每一行都應該通過白盒方式的測試;

13.  只丟擲已經顯示處理的異常。

14.  在捕獲(catch)語句的丟擲異常子句中(throw)，總是丟擲原始異常維護原始錯誤的堆疊分配。

catch(Exception exception) 

{    

    MessageBox.Show(exception.Message); 

    throw ;  //和throw exception一樣。 

} 

15. 避免方法的返回值是錯誤程式碼。

16.  儘量避免定義自定義異常類，當需要定義自定義的異常時：用面向物件的理論(而不是結論)，照搬結論不一定能提到質量或效率，可能適得其反；

下面是我自己的一些心得：        

          1.面向物件可以是面向物件特徵(屬性)，也可以是面向服務(方法)，服務要比特徵更加穩定；
          2.降低耦合(隔離)，我認為耦合分為程式碼耦合和工序耦合，通常構建了一大堆物件,結果並沒有感到輕鬆,往往程式碼弱耦合了，工序強耦合了；
例如方法的引數設計成了類,引數是減少了(呼叫介面也變得穩定了,這就是程式碼耦合降低了)，可是如果不借助文件,程式設計師很難弄清方法需要什麼又改變了什麼(工序耦合增加了)，開發專案時時這種情況，後期維護就更不用說了。應該使用程式碼自動化降低程式碼耦合，增加自動化工序降低手工工序減少工序耦合；
         3.面向修改封閉，面向擴充套件開放。設計應該儘可能以不修改原有程式碼的方式滿足需求變更，通過程式碼自動化以替換方式代替修改方式改進專案；
         4.MVC三層開發體系中：從M層驅動是最差的驅動方式，從C層驅動是最佳驅動方式，這跟前面的第一點是相輔相成的。

 總之，在開發過程中，軟體文件、需求分析、概要設計和詳細設計要齊全。 文件齊全了，後期維護和完善就比較容易，我認為這是最重要的。 程式碼編寫要符合一定的規範； 註釋一般要佔程式碼行數的20%； 每個函式最好不要超過100行； 並且對函式的輸入輸出使用等方面要有註釋。你可以看看 ”軟體工程“ 方面的書籍，會對你很有幫助的。

　　並不是每個人都能夠成為頂級程式設計師，但我們都在程式設計師之路上要不斷進步，追求更完美、更專業化的程式。不妨嘗試著改變一下，會讓你受益多多！