![](https://img-blog.csdnimg.cn/20201014180756780.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
可维护性代码
文章平均质量分 78
小么么么york
这个作者很懒,什么都没留下…
展开
-
编写可维护软件的不朽代码随想-11
编写简洁的代码 代码坏味道是指隐含问题的代码风格。 不留痕迹 童子军军规:离开营地时,要让它比来时更干净。应用在软件开发中,表示一旦编写或修改了一段代码,就有机会进行小的改进,结果就是你让这段代码比之前更简洁、更具有可维护性。 如何使用本原则 1. 不要编写单元级别的代码坏味道: 过长的代码单元(第2章),复杂的代码单元(第3章),长接口的代码单元(第5章)。需要及时重构“坏味道”的代码。及时就是尽可能快,但必须在代码被提交到版本控制系统之前。在开发过程中是允许有少许违反的,一个...原创 2021-06-15 09:51:20 · 86 阅读 · 0 评论 -
编写可维护软件的不朽代码随想-10
自动化开发部署和测试 在之前章节中有一个IsValid方法,检查银行账号是是否符合校验码要求,由于这种方法很容易出现代码错误,都会写一个短小的程序来测试验证此方法。原创 2021-06-11 14:55:26 · 141 阅读 · 4 评论 -
编写可维护软件的不朽代码随想-9
保持小规模代码库 控制代码库增长,主动减少系统的代码体积。 代码库是存储在一个仓库中的所有源代码的集合,可以独立地进行编译和部署,并且由一个团队进行维护。 以大型代码库为目标的项目更容易失败 项目体积和项目风险关系紧密,一个大型项目会导致大型团队、复杂的设计以及长时间的项目周期,会出现更复杂的沟通和协作,很难看清软件设计的整体情况,而且会出现大量的需求变更,这些都增加了质量下降、项目延期以及失败的可能性。 大型代码库更加难以维护 大型系统会出现更密集的缺陷 如何使用本原则 当其他条件都一样的原创 2021-06-11 14:51:13 · 59 阅读 · 0 评论 -
编写可维护软件的不朽代码随想-8
保持架构组件之间的平衡 构建封装边界是设计软件架构的重要技能。 原则: 平衡代码中顶层组件的数量和体积。 保持源代码中组件的数量接近于9,并且这些组件的体积基本一致。 平衡的组件可以帮助定位代码,并且允许独立对组件进行维护。 四种情况: 1. 所有修改都发生在一个单独的巨大的组件中 2. 大多数修改都发生在一个单独的巨大的组件,也有几个小组件存在 3. 许多修改分散在多个组件中,多个组件,大小参差不齐。 4. 对一两个范围有限的组件独立修改,体积比较一致的多个组件。 平衡组件的好处:原创 2021-06-11 14:50:39 · 112 阅读 · 1 评论 -
编写可维护软件的不朽代码随想-7
架构组件松耦合 有两种构建软件设计的方式:简单到明显没有缺陷;复杂到没有明显的缺陷。 原则 顶层组件之间应该做到松耦合 尽可能减少当前模块中需要暴露给其他组件中模块的相关代码 模块耦合度关注于单个模块对系统其他部分的暴露程度,组件耦合度关注的是一个组件中的模块,对其他组件中模块的暴露程度。 如果从组件层面来考虑,相同组件中模块之间的调用会被认为是一个内部调用,但是如果从模块层面来考虑,就变成了模块之间的耦合。 将组件级别的松耦合称为组件独立,与其相反的称为组件依赖。当发生组件依赖时,组件.原创 2021-06-11 14:50:05 · 117 阅读 · 1 评论 -
编写可维护软件的不朽代码随想-6
分离模块之间的关注点 原则: 避免形成大型模块,以便能达到模块之间的松耦合。 不同的职责分给不同的模块,隐藏接口的内部实现细节。 之前说的是代码单元层面,这里开始说模块层面。对应C#的类的概念。 一个真实的案例,先说明类之间的紧耦合是什么样子,为何对导致可维护性问题。 一个UserService类,位于某web应用程序的服务层,在开发过程中变得越来越庞大,最终违法了本章的原则。 第一次迭代中,该类只有三个方法,如下 ...原创 2021-06-11 14:47:33 · 116 阅读 · 1 评论 -
编写可维护软件的不朽代码随想-5
保持代码单元的接口简单 限制每个代码单元的参数不能超过4个。将多个参数提取成对象。 为了保持代码的可维护性,需要限制参数的个数,避免使用过多的参数(也称为代码单元接口) 之前的JPacman项目中,BoardPanel类的render方法,拥有许多参数的典型,此方法在一个由x,y,w,h表示的矩形中绘制一个方块以及方块的占有者(例如表示一个幽灵或一个豆丸) ...原创 2021-06-11 14:42:54 · 106 阅读 · 1 评论 -
编写可维护软件的不朽代码随想-4
不写重复代码 不要复制代码 编写可重用的、通用的代码,调用已有的代码 如果复制代码,就需要在多个地方修复BUG。 举例 一个管理银行账户的系统,通过Transfer类对象来表示钱在不同账户之间的流转过程。 CheckingAccount表示银行提供的支票账户,如下 ...原创 2021-06-11 14:38:34 · 134 阅读 · 1 评论 -
编写可维护软件的不朽代码随想-3
编写简单的代码单元 每个问题的内部都有许多更小的问题。 原则: 限制每个代码单元分支点的数量不超过4个 评测复杂度的一个常用方式是计算一段代码中可能路径的数量,也就是分支数量,在C#中具体是if和switch语句。 分支覆盖率:一个代码单元分支点的数量,就是覆盖所有分支点产生的分支路径的最小数量。 执行路径:所有分支组合起来就是该代码单元的执行路径,也称为单元路径的最大数量。 分支点的数量是路径的最小值,执行路径是所有路径的最大值,衡量复杂度的标准采用的是分支点数量+1,圈复杂度。 没有任何原创 2021-06-11 14:33:32 · 95 阅读 · 0 评论 -
编写可维护软件的不朽代码随想-2
编写短小的代码单元 代码单元的长度应<=15行,将长的代码分解成多个更短的代码单元;短小的代码单元易于理解、测试和重用。 代码单元:可独立维护和执行的最小代码集合。 例如在C#中,一个方法或者构造函数就是一个代码单元。 短小的代码一般是只有一个职责,比如列举的例子有一个方法,根据URL中的一个客户标识,生成该客户的所有银行账户以及收支明细列表。 方法体伪代码如下: { 处理一个HTTP GET请求 访问数据库并返回所需数据 银行账户的校验 拼接返回的JSON结果原创 2021-06-11 14:27:11 · 89 阅读 · 1 评论 -
编写可维护软件的不朽代码随想
初探 谁写的这段代码?我实在受不了了! 可维护性:系统可以被修改的难易程度。 后面提到的SIG是一个软件管理咨询公司 ISO 25010 将软件质量划分8个特征:可维护性,功能可适性,性能效率,兼容性,可使用性,可靠性,安全性,可移植性。 软件的维护四种方式:纠正性维护(也就是发现修复BUG),适应性维护(比如操作系统升级或者使用的技术升级),完善性维护(也就是需求变更或者增加新需求),预防性维护(预防将来可能会产生的BUG)。 重要性: 可维护性低的代码会对业务造成严重影响:软件在交付使用后原创 2021-06-11 14:25:11 · 81 阅读 · 0 评论