終于開始要做功能了，我相信新手都會有些興奮和緊張，我們就帶著這種美妙的感覺開始代碼之旅。很多新手拿到功能，就開始復制代碼，樂其不疲的當個代碼搬運工，這種開局方式是不妥的，我們先來看下新手常犯的錯誤。

[[283242]]

1. 新手常見的錯誤

1)當個快樂的代碼搬運工

這種是最常見的。一般新手的功能都比較簡單，都會是顯示類、列表類的功能，最多有一點簡單的交互。像這種功能在項目中很多，工程師就會去找類似的功能，然后整篇整篇的復制代碼過來，改點界面上的顯示元素，基本上功能開發就差不多了，自己看看沒問題，就丟給測試工程師。

初級工程師是代碼搬運工沒錯，但這種操作是有問題的，他沒有理解功能和代碼，代碼復制過來，感覺差不多就不管了，反正是把開發交給感覺。

分享個案例：之前有做一個項目，在發迭代版本的時候，我試用了一下，就發現一個功能不對，H5上顯示的文字內容不對，我就知道，這位老兄復制代碼搞錯了，我就故意去問他業務流程，他講了半天講不清楚，最后他告訴我代碼是他復制過來的，他也搞不懂，再問他調用關系也搞不清楚，我看復制過來的代碼里面，有很多是垃圾代碼，是前個功能的業務流程，這里用不到。我就讓他師傅花半天時間重新教一遍。

2)先鋪界面，再找接口，拼出個功能交給測試

很多新手看到功能，他也不懂得去理解功能，就看到有界面設計，其它也不管，就開始寫界面，寫完界面，再到處問接口，調個半天接口流程還走不通，終于調通了，還發現跟界面對不上，又鬧騰個半天，終于把數據對上了。不錯，界面有了，數據也有了，功能開發完了，就丟給測試。然后，測試就來投訴：“那個某某，功能開發一半就提交測試，簡直是開玩笑。”

這種開發方式，不僅新手喜歡用，我見過很多工作多年的工程師也喜歡用。

分享個案例：一個有四年經驗的H5工程師特別離譜，他做功能是分三步的，先按產品原型把所有的界面都鋪出來，然后對接接口，把數據調通，最后根據UI交互設計圖，再重新調整界面。我估算過他的開發速度，比正常的多出30%，而且bug率也特別高，關鍵還天天加班。

3)理解個大概就開始動手，然后打補丁，把功能完整性交給測試

這種也比較常見，不過犯這種錯誤的，都是新手中的高手，普通的還犯不上。一個功能比如有十個點，他懂得去分析，得出來五六個點，然后就開始開發，開發出來之后跟產品原型一比對，發現少東西了，就開始加，加了一兩個點，然后感覺完美，就提交測試。

這種是有一定的產品理解能力，但是理解不到位，所以功能的完整性是沒有保證的。

我們分析了常見的錯誤方式，接下來我們看正常的要怎么做。

2. 正常的做功能流程

我們都用過微信，那現在給你分配的功能就是聊天時發文字這個功能，那要怎么做?

1)步驟一：知道功能做什么

首先，知道功能做什么?發文字功能，是給好友發送中英文、數字、符號等信息。

其次，誰會用，怎么用?發文字功能，每個人都會用，可以給好友發，可以在群里發。

最后，功能跟其它功能有沒有關系?暫時這個功能跟其它功能沒關系。

通過前面的這些分析，我們就知道功能大概做什么了。接下來，就要看怎么做。

2)步驟二：知道功能實現的流程、步驟

簡單的講就是整理功能的實現思路，它大概有哪些主要的步驟。把這些步驟列出來，這個功能要實現的目標能達到了。

APP端：

• 聊天界面有個 輸入框，用戶點輸入框可以輸入文字，發送;
• 如果沒有網絡，提示用戶沒有網絡;
• 如果連接正常，就把文字內容異步發給服務器;
• 收到服務器返回，成功：把菊花去掉，不成功：顯示個紅色“!”。

后臺接口：

我們再來看后臺java端，同樣的功能，后臺思考的就跟前端不一樣。后臺大概是：

• 消息發送方告訴服務器有新消息
• 服務器方接收發送消息方數據
• 服務器告訴消息接收方有新數據要接收
• 接收方取得數據器端數據
• 接收方告訴服務器數據已經拿到，消息可以作廢

像這樣基本上就把一種事講通了。

3)步驟三：問師傅或領導

像前面這樣想一想，把它寫下來，可以用思維導圖，可以用文字，也可以用UML圖，或大學時學的流程圖。你確定對功能的理解和實現思路的理解都是對的嗎?我相信你不敢確定。所以，整理完思路，不是直接開發，要先問下師傅，讓他看你的理解對不對。師傅以他的經驗，如果有問題，他能幫你指出來，你再把思路修改一下。兩人再切磋一下，基本上就把功能點都找出來。

實際上，我前面講的這三部分，分別是需求分析、概要設計和設計評審。如果你是在大企業或有流程的企業，都有專門的流程節點和編寫要求，正常是用UML圖來畫分析設計圖，評審有專門的分析設計評審會，就按公司的要求來做就是了。如果是在專業性要求不高的公司，可以采用這種簡化的分析、設計和評審方法，至少自己的專業水平不會太差。

我這種簡化了的分享，主要是用來幫助理解分析和設計的原理。通過這種簡化了的分享，應該感覺分析、設計很簡單吧!不然很多人認為分析、設計是很高大上的，很難的事，就很抗拒去做，結果專業能力一直提升不上去。

實際上，分析、設計還是比較簡單的，難的是UML圖不懂得畫，而往往把分析、設計理解成畫UML圖和寫文檔。分析、設計是用來整理思路、輔助理解需求，UML圖是用來輔助分析、設計的，而現在UML圖把分析、設計難住了。《大學》里有句話：“物有本末，事有始終。” 而把分析、設計理解成畫UML圖，就是本末倒置。

4)步驟四：寫代碼 (做個快樂的代碼搬運工)

到前面這個階段，基本上就很清楚功能做什么，怎么做了。那就可以當個快樂的代碼搬運工，找到每個步驟的實現代碼，把它搬過來，所有的步驟和功能點都實現到了，那這個功能就開發完了。

5) 步驟五：測試

代碼開發完，不要認為就結束了，丟給測試就可以了。一般初級工程師都不會做測試和跑測試用例，所以公司沒有要求，我們也不做。但是，我們要自己去用下這個功能，如果自己開發出來的功能，自己都不會用，你覺得用戶會懂得用嗎?

自己試用的過程中，如果有用的不流暢的，用戶也會用的不流暢;如果你覺得做的功能看起來看丑，那客戶也是這種感覺。所以交出去的功能，是自己滿意的功能。那測試的時候，基本上是很少BUG了。

3. 開發的無上原則

【準時完成】

前面講了這么多，通過分析、設計、評審，讓你對功能需求有充分的理解，這樣寫出來的功能的完整性才有保證，自己試用功能，才能減少bug，所有的這些操作，都是讓你做的功能，減少bug率和返工，確保開發進度。

做開發有個至關重要的原則，就是“準時完成”。我帶團隊，硬性要求就是項目必須準時上線，不能有任何的延期。如果你能做到準時完成，比看十本執行力的書都來的有效果。

4. 總結

這節課我們分享了做功能開發常見的錯誤方式，大家盡量避免犯這些錯誤。簡單分享了分析、設計、設計評審的原理和操作步驟，打消程序員對分析、設計的抗拒心理，提升程序員的專業性，也讓大家掌握做功能比較好的方法和習慣，確保功能開發能準時完成。