外观
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