程式設計認知：多思考、多編碼、多測試

每位程式設計師都有自己獨特的程式設計方式，原文作者Ben Teese在他的程式設計師生涯中，悟出對編碼流程的一些見解：多思考、多編碼、多測試。打造軟體的過程是一個不斷學習的過程，一個好的策略是遵循計畫-執行-反思來進行的。

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

大致的樣式是這樣的：

a：多思考（Think a bit）

b：多編碼（Code a bit）

bit）

一遍（Go to Step 1）

第一步：多思考

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

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

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

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

第二步：多做

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

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

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

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

第三步：多測試

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

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

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

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

第四步：再來一遍

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

小結

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