外观
01.CodeQuality Promote
约 2855 字大约 10 分钟
项目管理数据结构devops个人
2022-08-19
在软件开发中也是一样,干净的地板能减少事故发生,归置到位的工具能提升生产力。软件质量,不但依赖于架构及项目管理,而且跟代码质量息息相关。
1、整洁度
① 谨慎命名
名副其实,见文知意、避免误导、去掉冗余、严谨
② 函数和类
1)单一权责原则。保持高内聚,低耦合。隔离会让系统每个元素的理解变得容易。
2)尽量不要在参数中传递状态值
3)同一个函数中的代码应该属于同一层级
③ 坏注释与好注释
④ 良好的格式
⑤ 数据结构
得墨忒定律(The Law of Demeter):模块不应该了解它所操作对象的内部情形。
⑥ 错误处理
⑦ Code Review
⑧ 规范性、可读性、可维护性(高内聚低耦合、面向对象原则、实现复杂性等)、可变更性(扩展性等)、安全性/健壮性、输入检查、异常处理边界检查、性能、依赖合理性
2、工作习惯
① 当你拿到需求时,分析下自己的需求功能点的重要性设计时多花点时间思考, 编码通常是比较快的
② 单元测试一定要写, 这是底线(除非这个成本非常大)
在团队中寻找比你代码质量要求更高的同学来review自己的代码,一起探讨问题,这能帮自己很快的提升。有疑义的地方一定要达成共识,立刻执行,并告知团队,并形成规范。
③ 写代码就难免会有bug/故障发生,另外一种避免故障的方案是如何尽快知道异常情况(比如做好监控), 在用户投诉之前尽快解决掉,或者提前做好预备方案(通常是比较重要的需求)。
④ 不要因为错小而放置不理,那会成为你的习惯。
⑤ 周四尽量减少发布, 你可能没有足够时间去观察/验证,发布时尤其需要重视。
⑥ 读源码是我比较喜欢做的一件事情。一方面能够熟悉一些技术原理/业务,开发时更胸有成竹,bug的几率当然也越少,当然你花费的时间可能就会多(你得去衡量). 这个做法也是不得已而为之: 一些部门的文档/代码注释都有问题,沟通又可能不便,读源码反而解决问题比较快.
⑦ 当别人向你提建议时, 心胸开阔点, 你会获取他人更多的帮助机会/建议
3、低耦合
耦合是衡量一个程序单元对其他程序单元的依赖程度。耦合(或高耦合)是应该极力避免的。如果你发现自己正在复制和粘贴代码并进行小的更改,或者重写代码,因为其他地方发生了更改,这就是高耦合的体现。
耦合会严重影响代码的复用性及可扩展性,让后人维护时不得不修改甚至重写这部分代码,不仅浪费时间还会导致仓储中又多出一块类似的代码,很容易让人迷惑。
同时,修改耦合度高的代码时经常会牵一发而动全身,如果修改时没有理清这些耦合关系,那么带来的后果可能会是灾难性的,特别是对于需求变化较多以及多人协作开发维护的项目,修改一个地方会引起本来已经运行稳定的模块错误,严重时会导致恶性循环,问题永远改不完,开发和测试都在各种问题之间奔波劳累,最后导致项目延期,用户满意度降低,成本也增加了,这对用户和开发商影响都是很恶劣的,各种风险也就不言而喻了。
4、高内聚
① 不应该将没有任何联系的东西堆到一起。
② 内聚是一个类中变量与方法连接强度的尺度。高内聚是值得要的,因为它意味着类可以更好地执行一项工作。低内聚是不好的,因为它表明类中的元素之间很少相关。每个方法也应该高内聚,大多数的方法只执行一个功能,不要在方法中添加‘额外’的指令,这样会导致方法执行更多的函数,同时也违反了上文的单一职责原则。
低内聚的体现:如果属性没有被类中的多个方法使用,这可能是低内聚的标志。同样,如果方法在几种不同的情况下不能被重用,或者如果一个方法根本不被使用,这也可能是低内聚的一个标志。
高内聚有助于缓解高耦合,高耦合是需要高内聚的标志。
5、健壮性/鲁棒性(Robustness)
健壮性是指在异常情况下,软件能够正常运行的能力。(如硬件发生故障、输入的数据无效或操作错误等)
健壮性有两层含义:一是容错能力,二是恢复能力。
容错是指发生异常情况时系统不出错误的能力,对于应用于航空航天、武器、金融等领域的这类高风险系统,容错设计非常重要。
而恢复则是指软件发生错误后(不论死活)重新运行时,能否恢复到没有发生错误前的状态的能力。
例如:因输入数据不正确,引起系统异常,这是容错能力不高引起的健壮性问题;操作系统死机了,重启后能够正常使用,说明具有一定恢复能力,具有一定的健壮性;数据库发生故障后,再次启动时一般能够恢复到正常的状态,恢复能力比较好。
6、性能(Performance)
性能是指软件及时提供相应服务的能力。具体而言,性能包括速度、吞吐量和持续高速性三方面的要求:
● 速度往往通过平均响应时间来度量;
● 吞吐量通过单位时间处理的交易数来度量;
● 持续高速性是指保持高度处理速度的能力。
7、效率(Efficiency)
指软件对CPU处理能力和存储能力这两大类计算机资源的使用效率。效率和性能反映了同一问题的“表”、“里”,性能为“表”,效率为“里”。
如系统运算一个报表,需要很长时间,这就是性能问题。
8、安全性(Security)
指软件同时兼顾向合法用户提供服务,以及阻止非授权使用软件及资源的能力。
安全性既属于技术问题又属于管理问题。一般地,如果黑客为非法入侵花费的代价(考虑时间、费用、风险等多种因素)高于得到的好处,那么这样的系统就可以认为是安全的。
例:有人可以访问非授权的资源,这就是安全性问题。
9、可扩展性(Extensibility)/灵活性(Flexibility)/适应性(Adaptability)/可伸缩性(Scalability)
反映软件适应“变化”的能力。调整、修改或改进正在运行的软件系统以适应新需求、变化了的需求的难易程度。
例:如报销系统原来不需要总经理审批,现在要改为总经理审批,可扩展性强的系统不需要作太多调整;如用户和数据量增加时,通过增加服务器来提高系统性能,这样可伸缩性比较强。
10、规范
① 规范有3部分:设计、编码、安全生产。
② 设计: 先有优秀的方案 设计推荐多用图表达,图比文字有更直观的传达能力:
首先是业务流程图,它能快速构建起我们对业务的认知,带着对业务的理解再来看代码,事半功倍。
然后是用例图,清晰地表达出我们系统的职责、边界、服务对象,结合业务流程图,能快速构建起我们对系统职责的认知。
接着是架构图,从我们日常的设计需求来看,架构图是需要的。好的架构图能快速给人搭建起理解的框架,再来看系统的细节部分,就很好理解。架构图推荐 C4 规范,它是我目前接触的表达最清晰的架构图规范。
接着再用时序图、状态图、ER图等把关键和复杂部分的设计表达出来。
③ 日常的需求有大有小,方案也不需要都遵循统一的范本,为了设计而设计,就徒增加工作量了。以按需为第一原则,能把要做啥,怎么做的表达清楚即可。这里按场景推荐各个图的使用场景:新建应用/对原有应用进行重大修改/复杂项目业务流程图(交代业务背景)C4的系统上下文、容器、组件这3张图用例图:有多个外部参与者类图:关键模型超过5个状态图:对象状态超过3个时序图:关键流程或复杂链路的参与对象超过3个ER图:涉及数据库变更(包含数据表结构文档)一般项目/重大日常业务流程图时序图(复杂功能、关键流程) 日常按需
④ 分层规范合理的代码分层,能控制各层的复杂度,以分层的思路去设计,也能提高代码的复用性。对于分层,我认为熟悉的就是好的,能满足工作中的大部分情况就好,这里不谈六边形架构、清晰架构、DODAF等概念,自己驾驭不了,还不能拿出来吹。我推荐DDD最基础的4层分层架构,如下:
用户界面/接口层
↓
应用层
↓
领域层
↓
基础设施层
11、其他
l 代码质量审核和管理工具:https://developer.51cto.com/art/201912/607936.htm
lhttps://baijiahao.baidu.com/s?id=1654313325850883156&wfr=spider&for=pc
l http://www.360doc.com/content/18/0914/13/441458_786608676.shtml
l 架构图推荐 C4 规范
l 回调函数
l 多看启发思路的书,多看开源代码,用辅助工具(lint、findbugs等)
lfindbugs,pmd这些工具在前几年我用的比较多,但近几年用的已经很少了,原因是发现的问题少,误判的几率还高,现在只是少数情况才会使用。但是新人建议还是多使用一下。
l Code Review
