type
status
date
slug
summary
tags
category
icon
password
一直从工作以来，包括平时的小项目和爱好，都没有认真完整的思考过宏观一点的架构方面的问题，顶多是在某个功能或者项目初期有一些设计，但远不能称作为架构。
原因思来想去大概有如下一二;大部分可能产出急迫、亦是做到哪里设计哪里，拿来主义、经验主义、框架约束之下也不再愿意费劲脑筋的想提前量，也笃信过那句提前优化都是无用功。
我想接下来不论孰优孰劣，都围绕架构的一些方法论来做一些深入的学习或回顾，也回顾下近十年的开发中的错误与正确的实践。
软件设计，低层细节和高层决定也是软件设计的一部分。它们形成一个连续的结构，定义了系统的形状。所以你不能缺少任何一个;事实上，他们也没有明确的分界线。 只有从最高层到最低层的一体的决定。
目标
软件架构的目标是最小化需要构建和维护系统的人力资源
这里我更通俗的贴合现实的理解是： 如果我要创建一个博客系统，那么应该需要人力参与维护的过程步骤应该最小化，比如写好了文章如何在保存之后就直接发布到了线上：供大家雅正。
那么步骤除了必须要添加的内容就最好剩下保存和控制发布或草稿存档。
设计质量的衡量可以简单通过衡量满足客户需求的所需努力来体现。如果这种努力少，并且在系统的整个生命周期中保持少的水平，那么设计是好的。如果这个努力随着每个新版本的增长而增多，则设计是不好的。就这么简单。
软件系统中我们应该关注的值是什么？
行为 vs 架构
每个软件系统都提供两个不同值给利益相关者：行为和结构。开发者为保证这两个值都维持高水平负责。他们经常会重视一个而忽略另一个，甚至，他们常常很少关注这两个值，最后软件系统毫无价值。
1. 行为
软件的第一个值是行为。程序员被雇佣来使机器表现某种行为为利益相关者赚钱或节约钱。他们通过开发某种功能或需求文档，然后编写代码，使得利益相关者的机器可以满足这些条件。
大部分程序认为的工作大多数都是实现新的Feature 或 修复Bug，但这是一种误解。
2. 架构
何谓 “软件”， 软可以理解轻松改变机器行为，让机器识别我们的代码做出不同的反馈，如果我们希望的是机器不容易进行改变，就因该叫做 “硬件”。
为了满足这个目的，软件必须得“软”，也就是容易改变。
当利益相关者改变他们关于特性的想法，那实现这种改变得简单容易。 进行这种改变的难度应该只与改变的范围成正比，而不是与改变的形状成正比。
有可能是某个需求或是修复某个匪夷所思的异常，总是常常会让开发人员感觉让我们总是要把方形的木头塞子放入一个三角形的孔里 🤣
出现这个问题就是架构的问题，架构应该和形状无关才是实用性强的架构设计。
举个🌰:
比如我目前在做一个搜索组件的改造，用户可以搜索单一搜索框需要的内容。最初，利益相关者希望用户只能按照商品订单号进行搜索。因此，设计了一个简单的搜索功能，允许用户在搜索框中输入商品名称并执行搜索。
然而，随着时间的推移，利益相关者认识到用户也希望根据订单其他字段的范围进行搜索，而不仅仅是订单号。在这种情况下，改变的范围是功能的新增，因为我需要添加一个例如金额或订单归属人等搜索框。这种改变是相对简单的，因为只涉及到在现有搜索功能上将原来的搜索字段增加新字段和相应的逻辑。
相比之下，如果利益相关者决定要改变搜索功能的形状，比如要进行模糊搜索匹配多个维度的字段，这种可能涉及到完全重构搜索算法，这种改变的难度就会相对增加很多。这可能涉及重写大量代码、重新设计数据库结构等以及调整用户界面来反映这种更广泛的搜索范围，因此与仅仅新增一个功能相比，这种改变的难度更大。
🤗 总结归纳
到底功能和架构到底谁更重要？
- 如果您给我一个运行完美的程序，但不可能改变，那么当需求改变时，它将没法用了，我将无法使其工作。所以这个程序将变得毫无用处。
- 如果你给我的程序没法用，但很容易改变，那么我可以使它工作，并保持它的在工作需求的变化也能用。因此，这个程序将继续不断有用。
这也是现实中常遇到的一个问题，甚至利益相关者也会觉得功能先用，所谓“贴合实际”先用起来，但是不作一丁点的余量设计就会容易遇到“但不可能改变，那么当需求改变时，它将没法用了”，所以这也是需要反思的问题，成本有时是即时可见的，有的是延后展现的，当变更发生时，可能利益相关者的愤怒在后面。
这句古老的谚语有很多的道理。那些紧急的事情很少是重要的，那些重要的事情很少是紧迫的。
📎 参考文章
- Clean Architecture
- 艾森豪威尔的矩阵 （图1.1）
欢迎您在底部评论区留言，一起交流~
- 作者:guozichun
- 链接:https://blog.yayh.life/article/545cff30-6042-4760-ba11-e0a408efe75b
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。