架构整洁之道(一)-良好架构的作用

架构整洁之道(一)-良好架构的作用

一、软件架构的目标

1. 软件架构的终极目标

   使用最小的人力成本实现软件的构建和维护。

   衡量一个架构足够好，其实就是看维护代码需要的成本很低，并且长时间维持比较低的状态。

   否则，就是不好的架构。

2. 技术债务

   为了容易解决问题，使用短期的方法。而这种方法在长期对软件产生不好的影响。也就是欠下的技术债务。最终总是要偿还的。

   不好的架构将使得技术债务不断地被积累。

3. 不好的软件架构的问题。

   当你中途加入一个团队，发现他们的代码是一个大型的耦合的系统。你又不了解每一个工作的细节，就不太敢修改之前的代码。因为不知道会产生什么影响。

   你不真正的了解系统，就不会觉得是代码的主人。你会犹豫是否要重构，过时的代码累积。长此以往，开发变的越来越不愉快，总不让人满意。最终导致人才流失。

   而后来的人，更不敢修改代码了。

二、案例

1. 这是一个真实的要求匿名的案例。

• 这是团队工程师数量的增加。

  

  你可能觉得这是好事。

• 于此同时，软件的生产效率如图。

  

  看得出来，到后面，代码越来越改不动了。

• 这是每修改一行代码付出的代价。

  

  显然，这种现象是不可持续的，随着成本的不断增加，公司的利润会被榨干，整个公司都会陷入困境，甚至倒闭。

• 工程师的生产力

  

  这个很容易理解，工程师每次修改都要小心翼翼。而且很可能出现side-effect(副作用)。往往就变成了一个问题反反复复。

• 对于我们工程师而言，往往非常挫败。 不管投入多少时间，不管救火多少次，加班多少次。

  产品质量一直上不去，只能在现有系统修修补补。问题反反复复。 只能在有空的时候，偶尔加个小功能。

• 或许程序员已经很惨了。管理层视角。

  

三、软件工程师职责

1. 为什么出现上述情况？

   正是因为没有注意到软件架构的价值。相比较每次救火，每次火烧眉毛的需求，软件架构虽然很重要，但是却不紧急。

2. 工程师的职责。

   软件工程师不是每天解决两个客户报的问题就完事了。

   软件的可维护性有我们来维护。作为软件工程师，要准备好长期的抗争。公司内部的抗争永远不会停止

   和其它部门进行平等的争吵。争取到优化软件架构的时间和空间。公司雇佣我们，是需要有人来做这件事。

   如果公司代码最终变得无法维护，那是软件工程师的失职。

四、参考文献

1. 《架构整洁之道》

2. http://www.ruanyifeng.com/blog/2021/05/scaling-problem.html