软件复杂度
2024-12-31 11:29:57 0 举报AI智能生成
对软件复杂度全方位的总结，软件工程师通过阅读对此有一个清晰的认识。
作者其他创作
大纲/内容
什么是复杂性
理性度量
从代码状况(结构化、复杂、不可读)、测性成本、维护成本考量
感性认知
任何使得软件难于理解和修改的因素
引起复杂性的因素
模糊性
模糊性产生了最直接的复杂度，让我们很难读懂代码真正想表达的含义，无法读懂这些代码，也就意味着我们更难去改变它
依赖性
依赖性又导致了复杂性不断传递，不断外溢的复杂性最终导致系统的无限腐化
复杂性的表现形式
变更放大
看似简单的变更需要不同地方的修改
认知负荷
开发人员需要多少知识才能完成一项任务；（不要增加学习和理解成本，该简单的时候简单）
未知的未知
不知道必须修改哪些代码才能完成任务
产生复杂性的原因
想简单图省事，没有及时治理不合理的内容
缺少匠心追求，对肮脏代码视而不见
技术能力不够，无法应对复杂系统
交接过渡缺失，三无产品几乎无法维护
软件固有的复杂性
软件的复杂性是固有的，包括问题域的复杂性、管理开发过程的困难性、通过软件可能实现的灵活性与刻画离散系统行为的问题。
治理复杂度
软件架构
引入软件架构治理复杂度，所以软件架构就是解决部分的软件复杂度的。
架构本质：是约束； 不告诉我们应该怎么做，而是教会我们不该做什么
递增的复杂度：
软件的复杂性不会凭空消失，并且会逐级递增
软件的复杂性不会凭空消失，并且会逐级递增
模糊性创造了复杂，依赖性传播了复杂
复杂性往往不是由单个灾难引起的
我们可以容易地说服自己，当前变更带来的一点点复杂性没什么大不了
编程思维论
（不可取但快）
（不可取但快）
战术编程
（不可取但快）
（不可取但快）
当前一定是最快的
不会花费太多时间来寻找最佳设计
每个编程任务都会引入一些复杂度
重构会减慢当前任务速度，所以保持最快速度
战略编程
（建议采用）
（建议采用）
工作代码远远不够
引入不必要的复杂度不可接受
不断对系统设计进行小幅改进
投资心态（每位工程师都需要对良好的设计进行连续的少量投资 10~20%）
架构伪论
好的代码自解释（还是需要有注释的）
永远追求优雅
架构终极目标
架构终极目标，用最小的人力成本来满足构建和维护该系统的需求。架构始终是我们解决复杂度的一个工具，如果当前系统并不复杂，我们不需要为了所谓的优雅去过分改造与优化它，持续将成本置在一个较低水位，就是软件最好的解决办法。
业务简单的系统不应用 DDD 架构，弱交互场景也无需进行前后端分离，哪怕是邓总设计师在规划新中国的发展上，也是制定了一套‘中国特色社会主义’制度。不要盲从一些教条的观念，选择适合自己的，控制在可控制范围内，既不过度也不缺失。毕竟没有绝对的优雅，甚至没有绝对的正确。
业务简单的系统不应用 DDD 架构，弱交互场景也无需进行前后端分离，哪怕是邓总设计师在规划新中国的发展上，也是制定了一套‘中国特色社会主义’制度。不要盲从一些教条的观念，选择适合自己的，控制在可控制范围内，既不过度也不缺失。毕竟没有绝对的优雅，甚至没有绝对的正确。
结束语
很多人认为做业务开发显得没那么有挑战性，但其实正好相反。最难解决的 bug 是无法重现的 bug，最难处理的问题域是不确定性的问题域。业务往往是最复杂的，面向不确定性设计才是最复杂的设计。软件工程学科最难的事情是抽象，因为它没有标准、没有方法、甚至没有对错。如何在软件固有的复杂性上找到一条既不过度也不缺失的路，是软件工程师的终身课题，或许永远也无法达到，或许我们已经在路上了。
0 条评论
下一页
