1.清晰的分析問題

2.三思而后行如何解決這個問題

3.收集完整的需求。

花點時間，想好產品的目標形態和最終的用戶群。在這個階段思路清晰會給以后節省很多時間。

4.寫一個執行計劃

對于比較大的項目，將工作拆分成多個模塊來做，并考慮以下幾點：

1）每個模塊都會用到的功能；

2）數據在各個模塊之間如何傳遞；

3）數據在每個模塊中如何使用；

收集需求和做計劃比編碼乏味，甚至比花幾個小時調試代碼更繁瑣。如果前期你能花時間正確設計項目的流程和結構，寫代碼的部分只是體力活。

5.注釋你的代碼。

每個函數都應該有1-2行的注釋，標明參數和返回值的含義。注釋應該是告訴你“為什么”而不是“什么”。在修改代碼的時候記住更新注釋。

6.使用一致的變量命名規則。

這將有助你跟蹤各個類型的變量，了解這個變量的作用。使代碼易于調試和維護。一個比較流行的約定是匈牙利命名法---以變量類型作為名字的前綴。例如：整型變量使用“intRowCounter”，字符串變量使用“strUserName”。無論你是用什么命名約定都沒關系，最終保證你的變量名稱是描述它的作用的就行。

7.組織你的代碼。

按照一定的代碼規范組織代碼，該縮進的縮進，該加空格的加空格。這樣會使代碼看起來更優雅，流程看起來更加清晰。

8.測試一切。

首先，在模塊內部測試，使用你所期望的輸入和輸出測試。然后使用可能出現的輸入輸出測試。按照上述方法會測試出隱藏的bug。測試也是一種藝術，通過實踐，你會逐漸鞏固自己的技能。在接口的測試用例中需要包括以下幾項：

a.邊界值：0和超出預期的最大值，文本值，空字符串，空參數；

b.無意義的值：假設用戶輸入的是亂碼；

c.不正確的值：如參數要求數字，使用字符串測試。

9.實踐，實踐，實踐。

編程不是一個停滯不前的行為。應該活到老，學到老。反復學習一些舊的知識是很重要的。

10.準備接受需求變更。

在現實工作環境中，需求是會變更的。開始時需求越清晰，排期越清晰。

a.在寫代碼之前，需求文檔或者實現計劃會讓整個項目的過程更加清晰。

b.將工程分為一系列的里程碑，為每個block做一個demo。一次管理一個里程碑過程。

11.從簡單到復雜。

當設計的東西比較復雜時，先設計一個簡單的demo，然后把功能一個一個加上去。

大家如果對編程感興趣，想了解更多的編程知識，解決編程問題，我們這里有java高手，C++/C高手，windows/Linux高手等，請關注我們的微信公眾號：腳本之家（jb51net），期望您的關注。