优雅写代码的心得

最近,公司有培训如何写单元测试。外面请的老师,重点讲了下单元测试应该怎么写,以及一些代码规范。以此以及之前踩过的坑,记录一些心得。


写代码前的思考

一般需求都是由产品规划,极少数需求可能直接来自于客户。

  1. 理解需求,明白对方想要什么东西:

    这一步至关重要,很多时候返工,都是因为产品想让你做的是a,你理解的是b,纯粹的牛头不对马嘴。

    一般正常的开发流程,都是提早告知开发下一个版本的迭代需求,开发应该提前去理解需求的具体含义,针对需求不明确,需求和历史逻辑冲突,需求实现困难的,和产品沟通协商。

    针对复杂的逻辑,一定要提前做好流程图,找产品和业务负责确认。如果时间充分,数据结构也需要设计。

    缺乏这一步骤,由于开发局限于自己的业务功能,或者曲解需求,做出来的产品十有八九做不到闭环。

  2. 评估时间,如何能大致估准时间:

    这里主要针对后端,后端实现需求,主要包括:数据结构设计,接口设计,单元测试创建,接口具体实现,自测。

  3. 具体设计:

    数据结构设计,影响到日后功能的扩展。记得大学接触编程的时候,有一门课程就是数据结构与算法,代码 = 数据结构 + 算法。好的数据结构就需要深入理解业务,甚至行业。当然很少有一步到位的完美结构,业务系统的数据结构,在不同阶段多多少少会变更升级,涉及到数据迁移,所以设计的时候一定要考虑能否将你的数据快速导入导出。

    接口设计,从开发效率上来说,约定接口和数据结构之后,前后端能同时开始开发,有自动化测试的也可以同步进行;从代码书写的逻辑来说,先确定自己要实现什么,一一列出,有助于自己合理安排时间,并方便接下来的单元测试构建。

    接口设计的时候,一个接口需要对应用户的一个原子性操作。在书写时需要注意命名规范,好的命名规范能让其他开发一眼识别出这个接口是干什么的。同时也需要提供api使用手册,来详细描述接口的入参,出参,请求方式等。

    接口定义后,不忙着先去实现,应该先去构建单元测试。针对复杂的接口,我们可以根据测试提供的用例,去构建单元测试。先构建单元测试,有助于理清业务逻辑,让我们实现接口的时候,避免踩坑。

显示 Gitment 评论