作为一个写代码时间极长的开发，对于架构总是有那么一点小小的心得。
心得
抛开单纯的 技术因素 和 业务因素，在绝大多数开发的职业生涯中，大部分时间通常在于同丑陋的框架做斗争、或是在试图延缓一个优美的框架逐渐劣化为一个丑陋的架构。
受限于精力，我们没有机会一睹真正 优美的架构 是怎么样的。
在我不算长也不算短的编码生涯中，我目睹过 最丑陋的架构 导致整个项目无法维护直接夭折，这一惨痛的经历直到今日还历历在目。
什么是架构？
首先把前端从架构中剔除:
提问
那么单纯的架构是什么呢？
我个人认为软件架构是指设计软件的人为软件赋予的形状。
这个形状是指系统如何被划分为组件(Components)，各个组件如何排列（Arrangement），组件之间如何沟通（Communication，通讯）。
有的文章会将 程序设计 和 软件架构 分离开来，认为程序设计相对于软件架构更底层一点，软件架构在思考的过程中通常 不应该考虑程序设计的因素。但是在我观点来看，这种做法 大错特错。一个真正做过软件架构的同学多数情况下是 没有办法脱离底层实现， 单独考虑上层架构 的。
我们类比一下造房子：新房子的确需要搭框架没错，但是你搭框架的同时必然是需要考虑整体房间的布局，还需要预先考虑水电排布，甚至插座排布，内饰的位置预留等等。
这些设计细节导致整个房子的架构图里面其实在事实上就已经包含了底层的设计细节1。
那么回到程序世界，在我自己的认知里面 底层设计细节 同 高层架构设计 是无法分离的，也就是说，在做架构设计的同时，你已经要对底层程序设计的抽象概念有所考虑，而且这一决策通常是 连续的，没有清晰分界的。
架构的目的是什么？
下面要讨论的一个问题就是架构的核心目的是什么？
软件架构的终极目标是用 最小的人力 来满足构建和维护整个系统的需求
是的这个目标听起来就很 资本家，但是事实就是这样，作为一个具体实现者，我们能期望架构能做的事情就是在修改他的时候，不要让我一个功能改几千个文件 —— 这首先就非常符合每个人的期望 —— 可以早点下班。
那么下面一个问题就自然而然的可以回答了： 如何评价一个框架的优劣？
- 这个框架能否在满足目前成本的情况下开发
- 这个框架能否以合适的成本持续
如果两者都能满足，那么他就是一个相对好的架构。
注意我这里用的是相对好的架构!
古怪的逻辑
一个相对好的架构不代表是一个优美的架构，而一个丑陋的架构并不等于他是一个不好的架构。
架构加上前端
那么我们在讨论完什么是架构和架构的目的后，终于可以加上前端两字来限定一下架构的组成范围了——也就是前端。
同后端架构不同，后端架构上是 相对比较容易抽象 出一个个具体的实体边界，并做出相对良好的区分的。前端面临的问题通常和后端有着 显著的差别：
- 大量多变、且部分相似的 ui 设计
- 抽象溢出 —— 框架（指 vue、react 这种）实现同交互实现有绑定关系
- 数据于逻辑行为耦合 —— 有些操作行为无法完全的将操作和逻辑分离
- 难以权衡的“重复”
- 实体关系复杂
除了前端本身的问题以外，另外就是非常常见的一个问题，前端非常容易写成一个乱麻系统。
由于前端是一个新生代的领域，在前端这个领域快车道式的发展才不过10年不到，对于 顶层的设计 远没有后端来的稳定。
绝大部分场景下，团队的项目管理者通常会倾向于后端设计而忽略前端设计，这导致的直接结果就是 —— 他在业务上总是被赶鸭子上架。
一切都是匆匆忙忙被构建起来的，没有经过设计，或者实践中沿用了之前的设计。
整个项目组为了加快发布速度，要么疯狂的向内使用耦合的方式新增功能。
要么通过疯狂的加入新人，同时由于决策层的忽视2，整个架构最终会变成难以为继。
混沌终局
没有办法维护，也没有办法停下来，停下来重构时间不够，不重构等死的绝境。
脚注
本文标题：软件架构
永久链接：https://iceprosurface.com/code/software-architecture/
作者授权：本文由 icepro 原创编译并授权刊载发布。
版权声明：本文使用「署名-非商业性使用-相同方式共享 4.0 国际」创作共享协议，转载或使用请遵守署名协议。