我的編程認知：多思考、多編碼、多測試

標籤：http   strong   2014   art   問題   演算法   

在我的程式員生涯中，悟出了以下的一個程式編碼流程；期間也接觸了很多其它的理論和想法，但是我還是覺得這是最適合我的。

大致的樣式是這樣的：

 

• 多思考（Think a bit）
• 多編碼（Code a bit）
• 多測試（Test a bit）
• 再來一遍（Go to Step 1）

 

第一步：多思考

有多少朋友會覺得，劈劈啪啪鍵盤節奏的快慢代表了程式生產力的高低？如果你也是這樣想的，我希望你能在遇到問題時，先放一放，靜心想一想。

如果思考的時候，覺得無從下手，不妨先問問自己：究竟要做什嗎？ 一旦安靜下來，這個問題的答案將會使我們辨清方向或者重新考慮問題的處理方法。

下一步，我會建議思考這個問題：自己是否把簡單問題複雜化了？ 嘗試用最簡單的辦法來解決問題是每個程式員應該為之努力的目標。但當我們掌握了足夠多的學識時，用如此簡單的方法來解決問題是否大材小用了？如果這樣想，或許最後找上我們的卻是一堆堆越來越複雜的問題。嘗試轉一下思路，用簡單的辦法解決問題會導致最壞結果是什麼呢？是比不能解決問題更差嗎？學會跳出牛角尖，這一點很重要。

因此，在遇到問題時，不妨多問問自己以上幾個問題。而當進行到一個瓶頸位置，進退維穀時，我會考慮進入下一步。

第二步：多做

我覺得這是最有趣的一步。因為很多時候，編程對於我們來說更像是打遊戲，不是嗎？但是要避免過猶不及。正如前述，當發覺做了無用功時，應該適當轉變思路，並再次提醒自己：是否朝著既定的方向前進。

然後，我們接著做下一步。

第三步：多測試

實不相瞞，這一步不僅沒有編碼那麼趣味盎然，甚至還十分讓人煩惱。

但是，沒有測試環節的項目，我建議還是在個人的開源項目中進行吧；因為不經過測試而發布的，應該沒有多少人敢用。

除了煩惱，測試可能也是編碼過程中最複雜的一個環節了。有別於編程那樣的所見即所得 (WYSIWYG)，要找出最優的測試方案可得花上成倍的努力。測試的特點就是充滿不確定性。

有的朋友採用的是測試驅動的開發方法，我的看法是：這是好的，但請堅持到底。對於我來說，如果是高度演算法集中的項目，我也會採用該方法。

第四步：再來一遍

問題的解決很多時候都不是一蹴而就的，一遍下來的迴圈和反饋是至關重要的。打造軟體的過程是一個不斷學習的過程，不斷學習加強技術和問題處理的能力。一個好的策略是遵循計劃->執行->反思的過程來進行。

小結

以上就是我個人的一些有關編碼流程的見解。時至今日，隨著越來越多的便捷開發工具的推出，以上這四步流程走得更順暢了。所以，請不妨試試吧。