软件开发中的注意事项(常见问题整理)

一、函数定义原则

1、一个函数/方法只做一件事情,不能将多个事情放在一个函数中处理(单一职责原则 SRP)

函数/方法的最小粒度是功能,函数在设计/定义的时候,不能将多个功能柔进一个函数里面,这样函数会变得得膨胀,增加了函数的耦合性,不便于函数管理维护。

例如,有这么一个业务逻辑:用户每天来网站阅读文章,当阅读完毕不同的10篇文章之后,就给他增加10个用户积分。

这个业务逻辑可以拆分为4个功能,也就需要定义为4个函数/方法来实现。

1)、用户阅读文章增加阅读计数(按照文章);

2)、统计指定用户当日阅读的不同文章数量;

3)、给指定用户增加积分;

4)、写入用户积分日志;

这四个功能函数也可以再封装到一个函数统一进行管理调用,这个函数用来封装处理当前的业务需求(内部单独调用4个函数来实现),但是却不能将4个功能都定义到一个函数中。

这样拆分之后的好处是:

1)、程序结构清晰,易于阅读;

2)、函数耦合性低,易于维护;

3)、函数可重用性高,减少代码冗余;

试想一下,假如又有新的需求:用户每个月在网站阅读完毕不同的100篇文章之后,就给他增加100个用户积分

假如处理之前的需求时没有对业务逻辑进行功能拆分,仅用一个函数来实现,面对现在这个新需求你将会怎么做呢?

2、在设计函数/方法时,应当尽可能考虑到定义的通用性,而不是仅仅为了解决当前业务需求本身

通用性设计的目的,是为了提高代码的可重用性,减少代码冗余,提高代码编写的质量。

拿上面的两个需求举例:

1)、统计用户阅读数量的函数,需求是要求统计当日的,因此我们设计的时候只提供了当日的统计数量。后面的需求又要求统计了每个月的数量,于是我们不得不再定义一个统计指定月份的统计数量的函数,然而这两个统计函数内部的统计逻辑相似度很高,这样就造成了代码的冗余(大多数的冗余代码就是这么产生的)。于是我们回过来想一想,当时设计统计函数的时候为什么不这样设计呢:

这样的设计既满足了当前业务的需求,也提高了设计的扩展性和可重用性,即使后续有不同时间段的统计需求,我也不用再新增加任何统计函数,减少了代码冗余。

2)、目前的需求是要求增加积分,但是有没有考虑过既然有增加就会有减少的情况,假如遇到减少积分的情况怎么办?例如,积分兑换奖品的需求,这个时候我们需要对用户积分进行减少,按照之前的设计,我们是不是必需再增加一个函数,用于减少用户积分?那我们为何一开始不这么开设计呢:

同样场景的还有列表分页函数等等。

二、函数注释原则

函数注释必需阐述清楚函数功能(不嫌长而嫌阐述不清),并且不能出现有歧义或者功能与描述不符的情况。

函数的注释是为了让开发者在最短的时间内弄清楚这个函数的作用,如果注释没有合理填写,那么开发者(特别是不同模块的开发者或者后续的功能维护者)会进入到该函数内部进行查看,并梳理函数内部的业务逻辑甚至会需要结合相关业务需求进行分析才能看明白这个函数是干什么用的,这样的工作效率势必会影响到整合项目的协作开发及维护效率。

三、缓存使用原则

如果不是物理长期存储的,必需设置过期时间;如果是可以物理存储的,考虑为何不写到数据库中(如:MySQL)。

常用缓存服务器如Redis和Memcache,如果设置缓存的数据不过期,那么久而久之里面的数据将会越来越多,很容易产生垃圾数据长期占用内存且不易清理。因此,在日常的开发中,对于缓存的操作,都尽量设置过期时间,以便在人为忽略或者操作失误的时候,有缓存服务器这一层可以保证缓存数据能自动得到及时清理。

四、团队分工协作

1、模块维护采用模块责任制。当开发中需要操作某个自己不熟悉的模块时,不能直接修改,而应该找到对应的模块负责人提供相应的接口(并且该接口的定义应当考虑通用性)。

为什么需要这样做:

1)、开发过程中独立开发,互不影响,并且版本管理中也不易产生分支冲突;

2)、开发过程中对于不熟悉的模块进行操作,由于对该模块的业务、功能、数据库等上下文环境不熟悉,需要花费更多的时间去理解,且容易产生问题;

此外,模块维护采用AB两人责任制,一人负责,一人后备。

 

2、关于git的模块维护问题。比如在一次迭代开发中有若干任务(分支例如:A、B、C),任务之间有部分耦合,多个任务需要其他模块的责任人员提供API支持,为了避免代码冲突及设计冗余,怎么做?

1)、首先,在使用git进行版本管理的时候,不同的分支应当保持独立性,这样互不影响,以便在分支部署的时候也可以单独部署。因此,需要考虑到耦合的任务是否需要保证独立性?

2)、如果是,那么任务的开发者需要找到对应耦合模块的负责人,由他来协调好耦合部分的方法定义,并且由他来新建独立的分支(例如:D)定义这些需要的API,然后开发者再合并API分支(D)到开发任务分支(A、B、C)中,继续开发;

3)、如果否,那么任务的开发者也需要找到对应耦合模块的负责人,共同协商耦合部分的方法定义,由其中一个任务的分支(例如:C)负责定义所需的全部API,其他任务的分支分别合并该任务分支即可

 

 

 

 

 

 

Leave a Reply

Your email address will not be published.