您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 业务知识 > 正文

写代码的五个步骤,你会几个?

发表于:2019-11-22 作者:金刚小书童 来源:今日头条

终于开始要做功能了,我相信新手都会有些兴奋和紧张,我们就带着这种美妙的感觉开始代码之旅。很多新手拿到功能,就开始复制代码,乐其不疲的当个代码搬运工,这种开局方式是不妥的,我们先来看下新手常犯的错误。

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. 总结

这节课我们分享了做功能开发常见的错误方式,大家尽量避免犯这些错误。简单分享了分析、设计、设计评审的原理和操作步骤,打消程序员对分析、设计的抗拒心理,提升程序员的专业性,也让大家掌握做功能比较好的方法和习惯,确保功能开发能准时完成。