写在前面
2019悄悄溜走一半，无论是离别的忧愁，还是成长路途的艰辛，都在心中滚烫。
距离上一篇文章已经很久了... 懒惰的博主不能将这一切归结于我的时间、我的规划、我的工作，只能怪自己懒......正所谓学如逆水行舟，不进则退，不进到最后就只能退了。
今天突发一些关于架构的感悟，执笔记录下来。
软件架构的出发点
软件架构是一个软件系统开发生命周期中最前端的部分，也是最关键、最核心的部分。它决定了后续代码的走向；能够决定项目的走向；有时候甚至能够决定一家公司的生死。软件架构的成功要素，有很多点，这些点的一两个或更多个，组成了不同级别的业务系统或用户系统：
*1 可靠性
*2 安全性
*3 可伸缩性
*4 可定制化
*5 可扩展性
*6 可维护性
*7 用户体验
*8 可快速迭代性
面向用户的系统，用户体验 、快速迭代、安全、可靠 ，这四点必不可少，这些点围绕着的基础的技术选型、管理模式、规则、流程，也就跟着对应的权重的不同去分配了。
假如公司A需要做一个工具app，xx计算器、或xx记事本。 想要获得市场认可，它的架构就需要大约 ： 30% 用户体验 、20%快速迭代、 10%可靠。按照这个权重的分配去管理架构的技术选型、管理模式等等。一个工具app的安全性做的无懈可击，是不会得到市场认可的；一个电商网站的安全性可靠性不能保证，会被市场所抛弃。
又假如公司B有一个对内的管理系统，想要正确的结果，首先就得保证 可快速迭代性 ，业务每天都在变化，相反的用户体验、伸缩、安全、可靠，都可以相对不那么迫切。
通过可快速迭代性迅速迭代可定制化需求和可扩展性需求提升了用户体验，用户体验的提升带动用户量的增长，则对可靠性、可维护、安全性、可伸缩性提出了更高的要求。
上面是我想要表达的，软件架构的出发点，是项目所处的市场的需求决定的。需求是什么，决定了架构是什么。
架构是难以更改的。是的，架构是非常难以更改的，如果你的项目已经推出市场了，除非重头来过，承受彻底重构带来的阵痛。这里往往要面临更严峻的考验，例如人事处理：有很多c 开发，想要转java，或有很多php开发，想要转python；再例如架构的改弦更张势必要有加班的，埋头苦干一个月，再走一遍来时的路~
举个栗子：TDD ，TDD本质过程就是要贯穿从需求分析、设计、编码、测试、整个研发过程。它其实是需求驱动，逐个满足每个的需求。 TDD的核心就在于把需求分析,设计,质量控制量化的过程，在编写测试用例时就可以规避、重构、设计需求的架构。TDD其实就是一个以需求驱动的架构模式、开发模式。
或许你已经在做相关的架构处理了，或许你已经吃到了一些苦头，这个理论或许可以帮助你认识到，要根据市场需求来制定合适的架构，推导合适的架构细节。要慎重。既不可以过度设计，也不可以设计不足，这把量尺是：市场需求。
架构以人为本
架构设计必须要考虑人在其中的重要因素，合适的人做合适的事情。一个好的架构，首要的就是要考虑所在团队的人的情况，我们往往倾向于抓技术层架构，忽略了怎么将合适的人放到合适的位置，已有的团队人员能不能合理的在架构中发挥应该有的作用。
抽象的处理、框架的引进很重要的一点是，如何解决人员素质、想法、环境的不一致。框架通过封装复杂的东西，简化业务的复杂程度，让对应的人能够专注对应的事情。抽象通过可以被共同理解的概念，简化复杂的内部处理逻辑，将人的目标聚拢在一起。
软件架构应该以人为本，将最高效的人放在最高效的地方能够取得最大化的成果，架构设计也就必须考虑人的因素。
例如我们有一个5人团队做一个项目，团队成员比例大约是： 1个leader ， 2 个核心， 2个实习，在设计这个项目的架构的时候，你必须要考虑的是，如何设计能把2个核心成员的力量放在合适的地方，如何设计能让2个实习成员能够完成既定的任务。 假如将2个核心与2个实习放在一起看待，过不了多久会出现一个情况，核心成员感觉做的东西技术含量太低，实习成员可能感觉东西难、累、赶，长此以往，项目会频繁面临人员变更。
我们倾向于集中精力做技术层架构，而不是人员层架构方面工作的主要原因，不是因为技术更重要，而是因为技术更容易做。人际交往是很复杂的，并且就效果而言从来都不会是很明晰和清楚的，但是它们比工作的任何其他方面都更重要。写代码并非只是写代码而已，而是与人有关——需要理解的东西包括那些人是谁，他们能作出什么贡献和需要什么东西，以及是多数派还是少数派等，诸如此类。“如果你把架构重点放一部分在人员安排的身上，那么就会发生更好的事情。
从人的角度衍生出的信息的交互
信息的交互其实是软件开发过程中需要重点关注的事情。信息的完整性、真实性，影响着开发过程中风险的暴露。风险则决定了项目的成功与否，所以我认为它是架构其中的一部分，它常常被人忽略，因为它既不属于技术，也不属于人员，更像管理工作，但其实它也跟架构有明显的关系。
软件项目的风险无非体现在以下四个方面:需求、技术、成本和进度。任何信息的不对等都有可能导致需求完成有误、技术设计偏离、成本过大、进度延迟。怎么样规划合理的信息交互、制定合理的反馈机制是架构需要考虑的问题之一。
总结和感悟
架构的目的是贴合市场需求指定合理的技术规划、人员规划、信息交互规划，架构是不仅仅局限于技术层面的。一个软件架构师，你需要统筹全局，深入了解需求，了解业务的走向，了解技术的价值所在。也需要制定或迎合人员的搭配，制定信息交互的流程。
核心观点
就是不可以忽略市场需求在架构设计中的力量，
更不可以忽略人在架构处理中所占的比例大小。
过度关注技术本身是一个本末倒置的行为。
这是我现阶段比较深刻的感悟，执笔记录，也是最近吃的教训的结果。我的观点不一定正确，感谢大家观看，如有疑问，欢迎留言。
原文链接：https://www.cnblogs.com/ztfjs/p/10941458.html
