"5 minutes from the student to the programmer" Lesson 11.
Finally started to do a feature, I believe that the novice will be some excitement and tension, we took such a wonderful feeling to start the code journey. Many beginners get the function, I began to copy the code, not tired of their music when code porters, start this way is wrong, let's look at a common newbie mistakes.
1. The common mistakes novice
1) When a happy codes porter
This is the most common. General functions are relatively simple novice, will be the display category, features a list of classes, there is little most simple interaction. Like a lot of this functionality in the project, engineers will find similar functions, and then copy the code over the entire whole, display elements on the screen to change the point, basically functional development on the same subject, see for yourself, no problem, He threw the test engineer.
Junior engineer is the code porters Yes, but this operation is in question, he did not understand the function and code, the code copied, almost feeling on the matter, anyway, is to develop to the feeling.
Share cases: Before you have to do a project, when hair iterative version, I tried a little, a feature not found, the text content displayed on H5 wrong, I know, the man copy the code made a mistake, I business process deliberately ask him, he spoke for a long time do not know about, and finally he told me that he copied the code, he also do not understand, ask him to call the relationship is also confused, I look inside the copied code there is a lot of junk code that is pre-function business processes, where less than. I let him spend half a day to re-master to teach again.
2) Xianpu interface, find the interface, to spell out functional tests
Many beginners see the function, he did not know how to understand the function, and there in interface design, regardless of the other, began to write interface, finished the interface, the interface and then ask around, half-day tune the interface process also leads to nowhere, and finally transfer pass, also found with the interface is not on, but naughty and a half days, and finally the data on. Yes, with the interface, data has also been, functional development is over, they threw the test. Then, the test came complaints: "That so and so, to submit half functional development tests, is simply a joke."
This development approach, not only novice like to use, I have seen many years of work engineers like to use.
分享个案例：一个有四年经验的H5工程师特别离谱，他做功能是分三步的，先按产品原型把所有的界面都铺出来，然后对接接口，把数据调通，最后根据UI交互设计图，再重新调整界面。我估算过他的开发速度，比正常的多出30%，而且bug率也特别高，关键还天天加班。
3）理解个大概就开始动手，然后打补丁，把功能完整性交给测试
这种也比较常见，不过犯这种错误的，都是新手中的高手，普通的还犯不上。一个功能比如有十个点，他懂得去分析，得出来五六个点，然后就开始开发，开发出来之后跟产品原型一比对，发现少东西了，就开始加，加了一两个点，然后感觉完美，就提交测试。
这种是有一定的产品理解能力，但是理解不到位，所以功能的完整性是没有保证的。
我们分析了常见的错误方式，接下来我们看正常的要怎么做。
2. 正常的做功能流程
我们都用过微信，那现在给你分配的功能就是聊天时发文字这个功能，那要怎么做？
1）步骤一：知道功能做什么
首先，知道功能做什么？发文字功能，是给好友发送中英文、数字、符号等信息。
其次，谁会用，怎么用？发文字功能，每个人都会用，可以给好友发，可以在群里发。
最后，功能跟其它功能有没有关系？暂时这个功能跟其它功能没关系。
通过前面的这些分析，我们就知道功能大概做什么了。接下来，就要看怎么做。
2）步骤二：知道功能实现的流程、步骤
简单的讲就是整理功能的实现思路，它大概有哪些主要的步骤。把这些步骤列出来，这个功能要实现的目标能达到了。
APP端：
* 聊天界面有个 输入框，用户点输入框可以输入文字，发送；
* 如果没有网络，提示用户没有网络；
* 如果连接正常，就把文字内容异步发给服务器；
* 收到服务器返回，成功：把菊花去掉，不成功：显示个红色“！”。
后台接口：
我们再来看后台java端，同样的功能，后台思考的就跟前端不一样。后台大概是：
* 消息发送方告诉服务器有新消息
* 服务器方接收发送消息方数据
* 服务器告诉消息接收方有新数据要接收
* 接收方取得数据器端数据
* 接收方告诉服务器数据已经拿到，消息可以作废
像这样基本上就把一种事讲通了。
3）步骤三：问师傅或领导
像前面这样想一想，把它写下来，可以用思维导图，可以用文字，也可以用UML图，或大学时学的流程图。你确定对功能的理解和实现思路的理解都是对的吗？我相信你不敢确定。所以，整理完思路，不是直接开发，要先问下师傅，让他看你的理解对不对。师傅以他的经验，如果有问题，他能帮你指出来，你再把思路修改一下。两人再切磋一下，基本上就把功能点都找出来。
实际上，我前面讲的这三部分，分别是需求分析、概要设计和设计评审。如果你是在大企业或有流程的企业，都有专门的流程节点和编写要求，正常是用UML图来画分析设计图，评审有专门的分析设计评审会，就按公司的要求来做就是了。如果是在专业性要求不高的公司，可以采用这种简化的分析、设计和评审方法，至少自己的专业水平不会太差。
我这种简化了的分享，主要是用来帮助理解分析和设计的原理。通过这种简化了的分享，应该感觉分析、设计很简单吧！不然很多人认为分析、设计是很高大上的，很难的事，就很抗拒去做，结果专业能力一直提升不上去。
实际上，分析、设计还是比较简单的，难的是UML图不懂得画，而往往把分析、设计理解成画UML图和写文档。分析、设计是用来整理思路、辅助理解需求，UML图是用来辅助分析、设计的，而现在UML图把分析、设计难住了。《大学》里有句话：“物有本末，事有始终。” 而把分析、设计理解成画UML图，就是本末倒置。
4）步骤四：写代码 （做个快乐的代码搬运工）
到前面这个阶段，基本上就很清楚功能做什么，怎么做了。那就可以当个快乐的代码搬运工，找到每个步骤的实现代码，把它搬过来，所有的步骤和功能点都实现到了，那这个功能就开发完了。
5） 步骤五：测试
Code development finished, I do not think it is over, threw a test on it. Generally junior engineer will not do the test and run test cases, so the company did not ask, we do not do. However, we have to lower themselves to use this function, if they developed features that he will not use, do you think users will know how to use it?
Process to try this yourself, if useful not smooth, the user will use not smooth; if you feel that the function looks ugly to see, that the customer is feeling. So pay out of function, it is their satisfaction with the features. That the test, basically a few BUG.
3. Development of the supreme principle
[On time]
Speaking in front of so many, through analysis, design, evaluation, so that you have a full understanding of the functional requirements, the integrity of this write function can only be guaranteed, own trial functions, in order to reduce the bug, all of these operations are let you do the function of reducing the bug and rework, to ensure that development progress.
We do have a crucial development principle is "on time." I brought the team, a mandatory requirement that the project must be on time on-line, can not have any delays. If you can do it on time, than watching ten books of executive power are to have effect.
4. Summary
This lesson do we share a common functional development of the wrong way, we try to avoid making these mistakes. Simple shared analysis, design, design review of the principles and steps to discourage programmers to analyze, design psychological resistance, improve the professional programmer, but also so that we do function better grasp the methods and habits, to ensure that development can function completed on time.