关于如何改善一个质量问题很多的遗留系统

引子

==这一切都烂透了==

https://stackoverflow.com/questions/748503/how-do-you-introduce-unit-testing-into-a-large-legacy-c-c-codebase

这就是我们现在系统的现状
这是一个大的、复杂的、严重的问题
多么可悲——没有奇迹般的解决方案——只是通过大量的艰苦工作来纠正多年积累的技术债务。
你只能用很小的步骤解决它。每一个微小的步骤都涉及以下内容。。。略。。。
Michael Feathers 在这方面写了圣经，《有效地处理遗留代码》

unit testing vs module testing

What is module testing? What is the difference between unit testing and module testing?

https://www.quora.com/What-is-module-testing-What-is-the-difference-between-unit-testing-and-module-testing

模块测试比单元测试工作在更高的级别
测试最小的构建块，如应用程序的单个子程序、过程、子例程或类，称为模块测试。
单元测试和模块测试之间的区别是：-

1.单元测试由开发人员完成，模块测试由测试人员完成。

2.单元测试是对程序的各个单元进行测试，以测试单元是否按要求工作，而模块测试是测试通过集成程序的小单元制成的真实对象。

\3. 单元测试后进行模块测试。

\4. 单元测试需要代码知识，模块测试不需要代码知识。

技术负债

https://zh.wikipedia.org/wiki/%E6%8A%80%E6%9C%AF%E8%B4%9F%E5%80%BA

https://en.wikipedia.org/wiki/Technical_debt

由来

开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还

技术债务的分类

常见的技术债务的原因有：

不充足的事前定义，从而需求仍然在开发过程中被定义，开发在设计之前就已经开始。这种做法的目的是节约时间，但常不得不以后返工。
商务压力。商务角度需要在必须的改变完成之前就发布产品。因此开发的技术债务包括那些待完成的改变。[3]:4[4]:22
缺少流程或理解，从而商务上对技术债务不了解，不考虑后果就做出决策。
紧耦合组件。功能不是模块化，软件不够灵活应对商务上的变化。
缺乏测试包。这刺激了快速高风险“凑活式”的修复bug。
缺少文档。写代码但没有必要的支撑性文档。[3]
缺乏合作。知识没有得到共享，对新手缺乏监督辅导。
在两个或多个分支上平行开发而累积了技术债务。由于工作最终需要合并两个分支的代码，拖延越晚，需要工作代价越大。
拖延做重构 – 重构拖延越晚，需要修改的代码越多。[4]:29
缺少与标准对齐。工业标准的特性、框架、技术被忽视。最终也必将遵从标准，做得越早代价越小。[3]:7
缺少知识。开发者并不知道如何写精致的代码。[4]
缺少所有权。外包的软件最终要让自己的工程师去重构或重写源代码。
技术领导力差, 未深思熟虑的命令通过命令链传达下来，增加了技术债务，而不是减少它
最后一分钟规范改变。这有可能渗透到整个项目中，没有时间或预算通过文档或检查来发现它们。

处理方法

软件工程师必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。

https://ithelp.ithome.com.tw/articles/10191382

https://efacani.com/studio/%E8%89%BE%E8%8F%B2%E8%82%AF%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86%E5%B0%8F%E5%AD%B8%E5%A0%82/%E5%B0%88%E6%A1%88%E4%B8%AD%E7%9A%84%E9%9A%B1%E5%BD%A2%E6%AE%BA%E6%89%8B%EF%BC%9A%E6%8A%80%E8%A1%93%E5%82%B5-technical-debt-%E8%89%BE%E8%8F%B2%E8%82%AF%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/

https://www.jianshu.com/p/757e72768c03

Published on Jul 24, 2021 in categories sw-dev-process