|
软件架构是软件系统开发生命周期中最前端的部分，也是最关键和最核心的部分。 它确定后续代码的方向； 它可以确定项目的方向； 有时它甚至可以决定公司的生死存亡。 软件架构的成功有很多要点。 这些点中的一个，两个或多个构成不同级别的业务系统或用户系统： *1 可靠性 *2 安全性 *3 可伸缩性 *4 可定制化 *5 可扩展性 *6 可维护性 *7 用户体验 *8 可快速迭代性 面向用户的系统，用户体验 、快速迭代、安全、可靠 ，这四点必不可少，这些点围绕着的基础的技术选型、管理模式、规则、流程，也就跟着对应的权重的不同去分配了。 
如果公司A需要制作工具app，xx计算器或xx笔记本。 要获得市场认可，其架构大约需要：30％的用户体验，20％的快速迭代和10％的可靠性。 根据权重的分布，管理结构的技术选择和管理模式。 工具应用程序的安全性是无可挑剔的，不会被市场认可； 电子商务网站的安全性和可靠性无法得到保证，将被市场放弃。 如果公司B具有内部管理系统，则要获得正确的结果，必须首先确保快速迭代。 业务每天都在变化。 相反，用户体验，可伸缩性，安全性和可靠性可以相对不那么紧迫。 通过可快速迭代性迅速迭代可定制化需求和可扩展性需求提升了用户体验，用户体验的提升带动用户量的增长，则对可靠性、可维护、安全性、可伸缩性提出了更高的要求。 上面是我想要表达的，软件架构的出发点，是项目所处的市场的需求决定的。需求是什么，决定了架构是什么。 架构是难以更改的。是的，架构是非常难以更改的，如果你的项目已经推出市场了，除非重头来过，承受彻底重构带来的阵痛。这里往往要面临更严峻的考验，例如人事处理：有很多c++开发，想要转java，或有很多php开发，想要转python；再例如架构的改弦更张势必要有加班的，埋头苦干一个月，再走一遍来时的路~ 举个栗子：TDD ，TDD本质过程就是要贯穿从需求分析、设计、编码、测试、整个研发过程。它其实是需求驱动，逐个满足每个的需求。 TDD的核心就在于把需求分析,设计,质量控制量化的过程，在编写测试用例时就可以规避、重构、设计需求的架构。TDD其实就是一个以需求驱动的架构模式、开发模式。 或许你已经在做相关的架构处理了，或许你已经吃到了一些苦头，这个理论或许可以帮助你认识到，要根据市场需求来制定合适的架构，推导合适的架构细节。要慎重。既不可以过度设计，也不可以设计不足，这把量尺是：市场需求。 |
|
|
来自： 嘻哈qb81bku3lo > 《播音主持》
