1.首先仔細分析問題編程
總結:需求分析
2.接着好好想一想如何解決這個問題模塊化
總結:把項目拆分爲幾個單獨問題,主要仍是難點問題,根據所掌握的知識和收集知識先解決難點問題
3.收集整理全部需求。
花點時間將最終產品要實現的目標寫下來,而且明確哪些是咱們的目標用戶羣。若是這一步能作好的話,將會給後面節約大量的時間,正所謂磨刀不誤砍柴工。
4.寫一個全面的實施計劃(或模型)。
若是是個小項目,這一步出來的可能只是一個基本的流程或者一個簡單的等式。
若是是個比較大的項目,這一步有助於咱們將它切割成幾個模塊,而後再按下面的問題思考:
各個模塊須要執行什麼任務
模塊之間如何傳遞數據
如何調用模塊中的數據
雖然比起直接入手去寫代碼,收集和規劃需求又枯燥又無趣,可是若是這一點沒有作好,後面的調試工做就會特別繁瑣。若是咱們能花點時間,設計出一個正確的程序流程和結構,那麼咱們其實在寫第一行代碼以前就至關於已經成功了一半。
5.註釋咱們的代碼。
若是你認爲你的代碼可能須要作個解釋,那就去註釋它。每一個函數都應該提早一兩行就先描述一下它的參數和返回結果。比起告訴你what,註釋應該說明的是why。還有記得在更新代碼的時候也要更新註釋。
6.使用統一的命名規則定義變量。
這將有助於咱們追蹤各個類型的變量,而且對每一個變量的用途一目瞭然。這一條的好處可不只僅是方便咱們打X = A+ B * C這麼簡單,它會讓咱們的代碼更便於調試和維護。目前廣泛受歡迎的一種命名方法是匈牙利命名法,它採用的是類型前綴於變量的作法。例如,對於總體變量,咱們可使用intRowCounter,字符串就是strUserName。不管你的命名規則是什麼都不要緊,只要保持一向,並能簡單描述變量就行。
7.格式化編輯代碼,代碼結構可視化。
例如,碰到條件語句(if、else等)和循環語句(for、while等)縮進代碼。還有,能夠在變量名和運算符號之間加個空格,運算符號指的是「+」、「-」、「*」、「/」,以及「=」(舉例,myVariable= 2 + 2)。這不但讓你的代碼更直觀更優雅,還能使得咱們的程序流程更加一目瞭然。
8.全面測試。
首先經過輸入咱們指望的值來測試每一個模塊可否獨立運做。而後試着輸入一些可能可是不多見的值,繼續測試。這基本上能暴露全部隱藏的bug。測試也有所謂的技巧,經過練習和實踐,咱們誰均可以逐步創建起適合本身的技能。測試應包含下列狀況:
極端值:正值用0和大於預期的最大值;文本用空字符串,參數用null。
無心義的值。雖然用戶不大可能會輸入亂碼,可是咱們本身不管如何先測試一下爲好。
不正確的值。在除法中輸入0,或者在預期是正數以及開平方根的狀況下輸個負數。當輸入類型是一個字符串的時候,輸入非數字,而後看看是否會被解析爲數字值。
9.練習、練習、仍是練習。
編程也會隨着時代的前行而不斷進步。因此總有新的東西須要咱們學習,——甚至更加有用、更加劇要——固然,也總有一些內容值得咱們溫故而知新。
10.減小需求改變的風險。
在現實的工做環境中,需求老是在不斷變化的。然而,若是前期咱們對需求收集得很是全面,一開始的實施計劃就頗有針對性,那麼後期因需求改變致使的計劃不周和雙方產生誤會的可能性就會小得多。
咱們能夠在開始寫代碼以前,經過展現需求文檔和實施計劃,以提升進程的清晰度。這將有助於確保咱們的計劃是真正按照客戶的要求去完成的。
若是將項目比做是一系列的里程碑,那麼一次只要完成一個就能夠了。記住,在任何特定的時刻須要考慮的東西越少,那麼咱們想得就越詳盡越完美。
11.由易到難,從簡入繁。
若是你的軟件複雜,那麼我建議你最好先從簡單的模塊入手。例如,有這樣一個項目:請設計一個程序,要求能出現一個跟着鼠標方向走的漸變圖形,而且還能根據鼠標滑動速度改變形狀。
首先,設計一個正方形,寫一段能作到讓它跟隨鼠標的代碼,這樣就把運動追蹤問題先單獨拎出來解決掉了。固然這纔是第一步。
接下來,將這個正方形的大小與鼠標的速度相關聯,即解決了形狀隨速度而變的問題。
最後,建立你想要的實際形狀,並把這三個組件鏈接在一塊兒便可。
運用這種方法天然而然地就編寫出來了模塊化的代碼。而且每一個組件都有它本身獨立的功能。這對代碼重用是很是有用的(例如,你徹底能夠在其餘項目中應用第一步驟(用於實現鼠標跟蹤)的代碼),並讓咱們的程序更容易調試和維護。函數