写在前面
2019悄悄溜走一半，不管是离别的忧愁，仍是成长路途的艰辛，都在心中滚烫。php
距离上一篇文章已经好久了... 懒惰的博主不能将这一切归结于个人时间、个人规划、个人工做，只能怪本身懒......正所谓学如逆水行舟，不进则退，不进到最后就只能退了。前端
今天突发一些关于架构的感悟，执笔记录下来。java
软件架构的出发点
软件架构是一个软件系统开发生命周期中最前端的部分，也是最关键、最核心的部分。它决定了后续代码的走向；可以决定项目的走向；有时候甚至可以决定一家公司的生死。软件架构的成功要素，有不少点，这些点的一两个或更多个，组成了不一样级别的业务系统或用户系统：python
*1 可靠性c++
*2 安全性安全
*3 可伸缩性架构
*4 可定制化app
*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个实习放在一块儿看待，过不了多久会出现一个状况，核心成员感受作的东西技术含量过低，实习成员可能感受东西难、累、赶，久而久之，项目会频繁面临人员变动。
咱们倾向于集中精力作技术层架构，而不是人员层架构方面工做的主要缘由，不是由于技术更重要，而是由于技术更容易作。人际交往是很复杂的，而且就效果而言历来都不会是很明晰和清楚的，可是它们比工做的任何其余方面都更重要。写代码并不是只是写代码而已，而是与人有关——须要理解的东西包括那些人是谁，他们能做出什么贡献和须要什么东西，以及是多数派仍是少数派等，诸如此类。“若是你把架构重点放一部分在人员安排的身上，那么就会发生更好的事情。
从人的角度衍生出的信息的交互
信息的交互实际上是软件开发过程当中须要重点关注的事情。信息的完整性、真实性，影响着开发过程当中风险的暴露。风险则决定了项目的成功与否，因此我认为它是架构其中的一部分，它经常被人忽略，由于它既不属于技术，也不属于人员，更像管理工做，但其实它也跟架构有明显的关系。
软件项目的风险无非体如今如下四个方面:需求、技术、成本和进度。任何信息的不对等都有可能致使需求完成有误、技术设计偏离、成本过大、进度延迟。怎么样规划合理的信息交互、制定合理的反馈机制是架构须要考虑的问题之一。
总结和感悟
架构的目的是贴合市场需求指定合理的技术规划、人员规划、信息交互规划，架构是不只仅局限于技术层面的。一个软件架构师，你须要统筹全局，深刻了解需求，了解业务的走向，了解技术的价值所在。也须要制定或迎合人员的搭配，制定信息交互的流程。
核心观点
就是不能够忽略市场需求在架构设计中的力量，
更不能够忽略人在架构处理中所占的比例大小。
过分关注技术自己是一个本末倒置的行为。
这是我现阶段比较深入的感悟，执笔记录，也是最近吃的教训的结果。个人观点不必定正确，感谢你们观看，若有疑问，欢迎留言。