终于开始要做功能了，我相信新手都会有些兴奋和紧张，我们就带着这种美妙的感觉开始代码之旅。很多新手拿到功能，就开始复制代码，乐其不疲的当个代码搬运工，这种开局方式是不妥的，我们先来看下新手常犯的错误。
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. 总结
这节课我们分享了做功能开发常见的错误方式，大家尽量避免犯这些错误。简单分享了分析、设计、设计评审的原理和操作步骤，打消程序员对分析、设计的抗拒心理，提升程序员的专业性，也让大家掌握做功能比较好的方法和习惯，确保功能开发能准时完成。
