本文是对于软件复杂度的零碎思考和记录。 内容包括，软件复杂度本身没有统一定义； 介绍常见代码复杂度，圈复杂度；比较复杂度和难度关系；最后回答从三个方面如何降低软件的难度（复杂度，能力，以及项目控制）。
前面文章介绍软件复杂度是软件最大的敌人，其对于软件开发和维护带来挑战。如果复杂度没有不能很好的控制，甚至失控，那么必然成本超出，时间延误，功能不能满足期望，那就灾难。软件危机就是这么来的。
Complexity is the enemy of flexibility. It entangles us in unintended consequences. It blocks our attempts to change. It hides potential defects, making it impossible to be sure our systems will function correctly. Performance, transparency, security — all these highly desirable attributes leak away in the face of increasing complexity.
定义
复杂度可以被感知，影响也被普遍认可，然而对于复杂度却没有统一的定义，当然也没有统一的衡量方式,可以参考不同人的理解。
但是对于软件不同的侧面，可以定义不同的复杂度，可以帮助了解某一个侧面或者一个点的复杂度。 比如衡量算法的时间复杂度，常用大O来表示； 算法的空间复杂度； 下面介绍一个常用的衡量代码复杂的 函数的圈复杂度。
- 函数圈复杂度（cyclomatic complexity）
The cyclomatic complexity of a section of source code is the number of linearly independent paths within it.
简单就可以数代码里面分叉（if），循环（for、while）的个数，当做圈复杂度。 如果圈复杂度太大，比如超过10，那么代码有 1024（2^10） 个独立路径 。 那么如何保证代码的正确，就不是一件容易的事。理论上要测试所有的路径，至少需要1024个测试用例。启发 降低函数的圈复杂度。可以通过重构，将巨型函数变为小函数。
上面介绍圈复杂度，只是衡量代码的复杂度。其实已经与软件本身的复杂度已经范围缩小很多了。
复杂度vs难度
复杂度是系统客观存在的属性，与系统组成元素，种类，数量，状态有关，同时元素之间互动，信息交换的频度有关。这些是系统本身的复杂度，而系统的实现映射到计算机里面，有会带来偶然的复杂度。同样系统的开发与维护，需要团队协作，复杂度增大。 此外，随着时间系统继续在演变，大脑对于信息的遗忘，复杂度有上一个台阶。
难度，是我们个体的一种感觉。随着复杂度的增加，会越的系统越来越难。那么对于系统中如何降低难度，我们就有下面几个思路。
-
降低客观复杂度
问题复杂度。 对于正确事情的认识，清楚的表达，以及如何验证定义清楚，减轻需求蔓延，降低问题复杂度。 USM，BDD，sbe 这些都是从软件的根源澄清价值，定义范围，避免二义性，减少折腾。
技术复杂度。 更高的抽象，分解，信息封装手段； 使用成熟的软件的框架，库，标准（http,servlet , rest, sql ...），中间件(event queue, cache, nigix...)； 更加灵活的架构，随着软件持续演化的架构； 更高界别语言，dsl; 提高代码的可读性和维护性，clean code ， simple design， 重构等。
环境的限制。 infrastructure as code 的理念，使用Docker提供的封装和标准环境， 自动化部署，持续发布，k8s 自动化的调度， 监控，这些大大降低环境复杂度和运行的复杂度。
-
提高团队个人的能力。
- 这个主要是提高团队或者开发者的技能, 所谓会者不难。
- 深化自己的技术栈.
- 团队持续学习。
-
通过项目管理，降低软件开发的干扰。
项目管理，沟通协作，降低项目的干扰，从而减少复杂度。流程，使得软件开发过程更有秩序，信息畅通，信息透明，加强信任，减少干扰。 这里暂且不谈，会在软件的生命周期里面谈到。
敏捷工程实践，提高对软件的控制力。 比如TDD， 单元测试，重构，持续集成，持续部署， 自动化。通过反馈，来提高对于系统的感知和控制力。
极限编程和ASE开发都会提高对于软件的控制力
reference
