程式設計王道，為「慢」不破

最近一段時間，在團隊中我發現好多程式員，尤其是初級或者新手程式員常常犯得的錯誤都很初級，經常犯一些程式設計中的大忌。不是沒有能力做好，而是做事不細心，我一直在給他們灌輸一個思想，其實程式設計的核心和王道就是：慢就是快。都說天下武功，唯快不破。但是在程式設計的道路中，天下代碼，而是：唯「慢」不破。

今天，我們就來談談新手程式員或者經驗少的程式員常常犯得大忌是哪些，表現形式有哪些，以及如何避免的問題。

1、兵馬未動，糧草先行

所謂兵馬未動，糧草先行，就是講做一件事之前一定要做夠充分的準備工作。而很多程式員犯得大忌和表現形式就是：原型需求和整個産品的業務邏輯都沒有搞明白之前，就開始動手了。邊做邊開始捋需求，對于前端程式員來講，這還好說一點，但是對于後端的程式員來說，真的是大忌了。因為架構的設計，資料庫的設計都是要依據這個産品的業務邏輯來實作的。

這裡講的程式設計王道，唯「慢」不破，指的是前期一定要花大量的時間來搞明白産品的需求和業務邏輯，不要着急動手去做代碼的實作。

我感覺作為一個程式員來講，在正式敲代碼實作之前，搞明白産品需求和業務邏輯到确定資料庫的設計和架構的設計，至少得占這個項目所有時間的 1/3 左右才合适，甚至有的難度大的 ERP 式的系統，占到一半時間也有可能。隻要這些确定都想通了，剩下的就是噼裡啪啦的敲代碼了。

之前，有個朋友開玩笑的說：

我看你們程式員敲代碼都喜歡使用機械鍵盤，噼裡啪啦的敲代碼的聲音很大，感覺你們是在做體力活似的。

我想說：我們其實喜歡的是噼裡啪啦敲代碼的那種感覺，鍵盤的敲擊聲能夠給人帶來一種爽感。但是我們程式員最動腦的工作其實就是前期的準備工作，是設計的思考，後期确實就跟體力活也差不多。

2、程式設計中慢在細節，快在編碼

兵馬未動，糧草都已經先行了，前期我們準備工作都做好了，剩下的就是敲代碼了。雖然在編碼的過程中确實很快，但是也要注意一些細節。

很多程式員編碼習慣的問題，或者是為了追求速度的問題，導緻在一些該注意細節的地方沒有注意到。比如程式設計的大忌和表現形式就是：背景程式員邏輯判斷考慮不周全，有的甚至不寫，直到測試測試出來，才會寫；而前端程式員不注意細節的體驗問題，出現錯誤不彈窗處理，不告知使用者，有些該提示的地方，不給使用者提示，不是不知道，就是懶得寫。

快在編碼不假，但是要慢在細節。後端程式員一定要把邏輯判斷想周全，前端程式員一定要注意使用者體驗。這都是經驗。

3、程式設計大忌：不要抱有先實作，後完善的幻想

有很多程式員都有這樣的借口，項目比較着急，我先實作這個功能，能用就行，後期我再回來完善就行。背景程式員可能會想，這個接口先寫完，給前端用着，一些判斷不先加，等 過後我統一回來完善。前端程式員想這個彈框不先寫，等做完了，再一一加上。項目太急了，先做完再說。

這樣能叫做完嗎？程式設計的大忌，這是大忌。不要抱有先實作後完善的幻想。敲代碼最重要的就是「一步到位」。

你告訴我：有多少程式員能有時間回來完善和重構的？你這樣想了，後期不出 bug 或者測試不提，你可能都忘了，都可能記不起來這件事了。因為你可能在你心中永遠都認為你在忙。

再者，一個程式員最讨厭的一件事是什麼？修改代碼，不管是修改你自己的，還是修改别人的。回來修改代碼的時間是極大的浪費，以為你要在你寫的忙忙代碼中找到你當時寫的不好的地方，完善它。你找代碼的過程是非常浪費時間的。

有多少人能夠回來完善？又有多少人會重構代碼？反問一下自己。

總結

說完這些之後，我們再來算一下時間成本，為什麼慢就是快呢？因為如果你前期花足了時間準備和設計，在程式設計的時候，又盡量完善的注意到了細節，你項目最終完成的時候，bug 就會少很多，就可以及時傳遞。如果你認為先實作，後完善，你項目傳遞測試的時候，bug 會很多，很多，你修改 bug 的時間絕對會大量的浪費時間，最後很容易導緻項目不能按時完成和傳遞。

很多人算不過這個成本，慢就是快，看似你的快，其實并不是快，是僞快。是以，作為一個程式員切勿犯到上面提到的程式設計大忌。這是一個程式設計習慣和風格養成的問題。如果有一個好的變成習慣，你将會受益終生。

最後，程式設計王道，唯「慢」不破。

原文釋出時間為：2018-11-25

本文作者：loonggg

本文來自雲栖社群合作夥伴“

非著名程式員

”，了解相關資訊可以關注“

”。