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

[[283242]]

1. 新手常見的錯誤

1)當(dāng)個快樂的代碼搬運工

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

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

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

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

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

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

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

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

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

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

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

2. 正常的做功能流程

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

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

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

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

最后，功能跟其它功能有沒有關(guān)系?暫時這個功能跟其它功能沒關(guān)系。

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

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

簡單的講就是整理功能的實現(xiàn)思路，它大概有哪些主要的步驟。把這些步驟列出來，這個功能要實現(xiàn)的目標(biāo)能達(dá)到了。

APP端：

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

后臺接口：

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

• 消息發(fā)送方告訴服務(wù)器有新消息
• 服務(wù)器方接收發(fā)送消息方數(shù)據(jù)
• 服務(wù)器告訴消息接收方有新數(shù)據(jù)要接收
• 接收方取得數(shù)據(jù)器端數(shù)據(jù)
• 接收方告訴服務(wù)器數(shù)據(jù)已經(jīng)拿到，消息可以作廢

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

3)步驟三：問師傅或領(lǐng)導(dǎo)

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

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

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

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

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

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

5) 步驟五：測試

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

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

3. 開發(fā)的無上原則

【準(zhǔn)時完成】

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

做開發(fā)有個至關(guān)重要的原則，就是“準(zhǔn)時完成”。我?guī)F隊，硬性要求就是項目必須準(zhǔn)時上線，不能有任何的延期。如果你能做到準(zhǔn)時完成，比看十本執(zhí)行力的書都來的有效果。

4. 總結(jié)

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