大家好，我是寒草😈，一只工作一年出头的草系码猿🐒
如果喜欢我的文章，可以关注 ➕ 点赞，与我一同成长吧~
加我微信：hancao97，邀你进群，一起学习交流，成为更优秀的工程师～

「这是我参与2022首次更文挑战的第3天，活动详情查看：2022首次更文挑战」。

系列开篇词

《架构整洁之道》这本书我已经想要阅读很久了，最早是去年年初，某位领导离职前在公司做了一次关于组件治理的分享，那段时间她对《架构整洁之道》这本书算是如获至宝。我也是在她那里知道了这本书，从那以后，这本书也长时间停留在我的书单里，却从未正式品读。

从未正式品读的原因之一是当时的我对于架构理解太过于浅薄，无法很好的理解书中内容。二是当时的我更需要学习的是如何写出更加优质整洁的代码，而非研究架构整洁之道。所以去年我选择更细致的阅读《代码整洁之道》以及《重构：改善既有代码设计》，我自然从这两本书收益良多，但是我并不能将自己对“整洁”追求止步于代码层面之上，于是现在我打算开始阅读《架构整洁之道》。

现在的我并不能说自己写的代码足够整洁，但是渴望阅读的心情已经停不下来✨

我还记得去年在那位领导离职前要我们写年终总结，我写了很多关于技术的渴望以及未来的追求。她在那一天夜晚（大概是一两点钟？），微信和我说，看了我写的总结和展望感觉非常好，并给我鼓励与肯定。我的眼泪刷的一下子就下来了，既有不舍，祝愿，还有一种我努力想打开一扇大门，这时旁边有一位前辈给了我十足的鼓励的强烈认同感。

但是她欠我一本《架构整洁之道》实体书，我该 diss 还是要 diss 一下。

现在 2022，我以这本书为开始，也祝愿 2022 的寒草（我的 id 叫寒草🌿，谁敢问寒草是谁，我打你哦），以更快的速度，大踏步向前。

给我高高的飞起来啊，新时代的前端工程师 —— 寒草🌿

概述

首先需要陈述一个事实：我们编写并调试一段代码直到成功运行并不是一件很困难的事情，但是将软件架构设计做好就完全另当别论了。

软件架构设计是一件非常困难的事情，这通常需要大多数程序员所不具备的经验与技能。

并不是所有人都愿意花时间来学习和钻研这个方向，且做一个好的软件架构师所需要的自律和专注程度也会让大多数程序员始料未及。

软件架构一旦做好了就会体会到其中奥妙：

维持系统正常运转再也不需要成群的工程师
每个变更的实施也不再需要巨大的需求文档和复杂的任务追踪系统
程序员们也不需要疯狂的加班了

采用好的架构可以大大节省软件项目构建与维护成本，使得每次变更都短小简单，易于实施，并且避免缺陷，用最小的成本，最大程度满足功能性和灵活性的要求。

设计与架构究竟是什么

书中阐述设计与架构并没有任何区别：

架构这个词一般用在高层级的讨论中，这类讨论一般都把底层的实现细节排除在外。
而设计一词，往往用来指代具体的系统底层组织结构和实现细节。

但是这个区别是不成立的，底层设计和高层架构信息是不可分割的，他们组合在一起，共同定义了整个软件系统，缺一不可。所谓底层和高层本身就是一系列决策组成的连续体，没有清晰的分割线。

目标是什么

软件架构的终极目标是：用最小的人力成本来满足构建和维护该系统的需求。

一个软件架构的优劣，可以用它满足用户需求所需要的成本来衡量，如果该成本很低，并且在系统的整个生命周期内一直都能维持这样的低成本，那么这个系统的设计就是优良的。如果每次发布都会提升下一次变更的成本，那么这个设计就是不好的。

现在的软件研发工程师都有点过于低估那些好的，良好设计的，整洁的代码的重要性。且忽视了一个自然规律：胡乱编写代码的工作速度其实比循规蹈矩更慢。

不管怎么看，研发团队最好的选择是清晰的认识并避开工程师们过度自信的特点，开始认真的对待自己的代码架构，对其质量负责。

要提高自己软件架构的质量，就需要先知道什么是优秀的软件架构。而为了在系统构建过程中采用好的设计和架构以便减少构建成本，提高生产力，又需要先了解系统架构的各种属性与成本和生产力的关系。

而如果想要了解什么是优秀的，整洁的软件架构与设计。各位可以去阅读《架构整洁之道》或者持续关注我的文章～

两个价值维度

对于每个软件系统，我们都可以通过行为和架构两个维度来体现它的实际价值。软件研发人员应该确保自己的系统在这两个维度上的实际价值都能长时间维持在很高的状态。不幸的是他们往往只关注一个维度，而忽视了另外一个维度。更不幸的是，他们常常关注的还是错误的维度，这导致了系统的价值最终趋降为零。

行为价值

让机器按照某种指定方式运转，给系统的使用者创造或者提高利润 架构价值
软件的灵活性

软件系统必须保持灵活。软件发明的目的，就是让我们可以以一种灵活的方式来改变机器的工作行为。对机器上那些很难改变的工作行为，我们通常称之为硬件。

为了达到软件的本来目的，软件系统必须够 “软”一一也就是说，软件应该容易被修改。当需求方改变需求的时候，随之所需的软件变更必须可以简单而方便地实现，变更实施的难度应该和变更的范畴成等比关系。

哪个价值维度更重要？

书中阐述业务部门通常认为系统正常工作更加重要，系统开发人员常常也就跟随采取了这种态度。但是他们是错误的，并举了这样一个例子：

如果某程序可以正常工作，但是无法修改，那么当需求变更的时候它就不再能够正常工作了，我们也无法通过修改让它能继续正常工作。因此，这个程序的价值将成为 0。
如果某程序目前无法正常工作，但是我们可以很容易地修改它，那么将它改好，并且随着需求变化不停地修改它，都应该是很容易的事。因此，这个程序会持续产生价值。

而我想着世事无绝对，作为一个买断制无需更改的产品来说，行为价值肯定更加重要。而在需要不断迭代的产品中，业务方从行为价值考量并没有什么问题，但是作为开发者理应从架构价值考量，提供专业的能力以支持业务不断迭代。

艾森豪威尔矩阵

我们从这个矩阵来看行为价值和架构价值：

系统行为，是紧急的，但是并不总是特别重要
系统架构，是重要的，但是并不总是特别紧急

业务部门原本就是没有能力评估系统架构的重要程度的，这本来就应该是研友人员自己的工作职责！所以，平衡系统架构的重要性与功能的紧急程度这件事，是软件研发人员自己的职责。

如果忽视软件架构的价值，系统将会变得越来越难以维护，终会有一天，系统将会变得再也无法修改。如果系统变成了这个样子，那么说明软件开发团队没有和需求方做足够的抗争，没有完成自己应尽的职责。

所以，请大家为好的软件架构而持续斗争！

结束语

本篇文章主要是我的《架构整洁之道》的开篇，也简单介绍了架构整洁的意义。未来会有更多精彩内容，还请各位读者持续关注。

✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨

少年向来不识天高地厚
放眼处皆自负才高八斗
虽是自命风流
倒也坦诚无忧
我爱这样的少年
谦和而狂妄
骄傲又坦然☀️