《5分鐘從學生到程序員》第11課。
終於開始要做功能了，我相信新手都會有些興奮和緊張，我們就帶着這種美妙的感覺開始代碼之旅。很多新手拿到功能，就開始複製代碼，樂其不疲的當個代碼搬運工，這種開局方式是不妥的，我們先來看下新手常犯的錯誤。
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. 總結
這節課我們分享了做功能開發常見的錯誤方式，大家儘量避免犯這些錯誤。簡單分享了分析、設計、設計評審的原理和操作步驟，打消程序員對分析、設計的抗拒心理，提升程序員的專業性，也讓大家掌握做功能比較好的方法和習慣，確保功能開發能準時完成。