前端架构前言
TIP
没有一种架构能满足未来的需求
什么是软件架构？
TIP
维基百科上说：软件架构四肢软件系统的高级结构，以及创建这种结构和系统的约束。每个结构包括软件元素、元素之间的关系，以及元素和关系的属性。软件系统的架构是一种隐喻，类如语建筑物的体系结构，它作为系统和开发项目的蓝图，列出了设计团队必须执行的任务。
开发人员需要怎么的软件架构？
TIP
不以实现为目的的架构，都是无意义的，因此，我们对系统架构的基本判断如下：
- 一个无法上线的应用架构，基本算不上好的架构。
- 一个没有人能完成开发的架构，算不上具有可行性的软件架构。
- 一个现有的技术上不可行的架构，算不上一个合理的软件架构。
架构的设计
TIP
架构设计并非只是一个技术工作，它包含了一系列的工作，其中范围包括软件工程、开发实践、业务交付等相关领域。 相关步骤：
- 收集利益相关者的需求，倾听业务人员、项目负责人等的相关者的需求，进行用户访谈，收集相关需求。
- 与相应的技术人员讨论，了解架构上潜在的限制。
- 寻找潜在的可行性激素方案。
- 整理出功能列表种得功能性需求和跨功能性需求。
- 找出影响开发的风险点。
- 和技术委员会、利益相关者反复确认方案。
- 对架构设计进行概念证明。
- 细花架构的部分实施细节等。
- 结合激素和业务，进行需求排期
寻找架构的关注点
TIP
再设计架构的过程中，各个组织、开发人员、架构师都拥有自己的关注点。在大部分项目中都会拥有象是的一些关注点。 常见的关注点如下：
- 性能（应用需要达到什么样的性能指标，可以实现用的多少用户并发）
- 安全（应用如何保障用户数据的安全、如何应对客户端的攻击、如何应对服务端的功能）
- 平台化（应用是否需要作为一个平台。来承接其他系统）
- 代码维护（是不是稍有经验的开发人员都能快速上手）
- 用户体验（用户体验是否比其他几个维度是否更重要）
TIP
不同的项目因为自身的需求，对于各种特性的优先级考虑往往是不一样的。有的项目认为安全更重要，又安全带来的用户体验下降的问题是可以允许的。而有的项目认为用户体验更重要，也便能忍受其影响到其他特性。
架构设计原则
TIP
不通的人再设计架构时会出现不同的风格，在细节的把握上也会出现特有的风格。这便是架构的设计原则。
- 不多也不少（不做多余的设计，也不缺少关键的部分）。
- 演进式（不断的演进以使架构适应当前环境）。
- 持续性（长期的架构改进比什么都重要）。
不对不少
TIP
一个好的架构设计，内容不多也不少。
- 设计过多则过度设计
TIP
即我们针对未来，提前准备好相应的世界。这些设计都是假想出来的，在实现的时候设计本身便不再适用。反而我们还要解决之前的设计带来的问题，重新修改、删除原先的设计，它们会进一步增加项目得成本。
- 设计过少
TIP
设计过少则是设计不足设计不足会使架构扩展不强，不能灵活的应对变化。职得一提的使，设计过多有可能使设计者的癖好或者使炫技，而设计不足则可能是能力有限。
- 经常做两种假设
TIP
一是未来人比我们聪明，所以少做了一些设计。二是未来的接手者会比我们稍逊一点点，那么就为他们多做一些设计。
总结：
TIP
架构都只是适合当前的情况，一谈到各种需求变化时，会发现架构设计上的各种不足，这并非时架构的问题。架构要不断的根据需求严谨变化，以瞒足新得需求。
演进式
TIP
适应环境能够生存下来的生物，并不是最强壮，也不是那些最聪明的，而是那些对变化做出快速反应的——达尔文
持续性
TIP
从某种意义上来说，持续性和演进式有些类似。两者的区别是，演进式是指架构上的一些变化，而持续性针对的式开发人员的变化。架构的持续性的意图式，敢于修正架构的错误部分，再修正过程中尽管可能会带来一些不合适的中转式的架构，但是也会很快的被纠正过来。具体的持续性包括一下几个方面
- 技能水平的持续改进
TIP
随着代码的增多，架构也在不断的变化，也需要不断的被纠正，已符合现有的需求。这就要求团队里的成员既要东得现有的架构，还要有能力来做一些改变。为此，团队成员需要再项目中进行相应的工程实践。再日常的开发总，私用敏捷方法实践相关的持续集成、持续部署。此外，还要关注与学习相关技能和实践，以协助我们改善架构。开发中善于发现抽象与模式，并借助测试驱动开发，利用重构进行导向设计。并使用一些质量改善工具，用它们产生指标来发现问题。
- 应用的持续改进
TIP
除了业务应用本身，互联网还需要一系列的配套服务日志、用户行为日志、性能监控等。如果以互联网的思维来看，这些事件都不会是一蹴而就的，“先上线，后解决问题”才是真理。再项目开始阶段，某些部分可以手动完成，然后，再项目演进的过程中不断开发相应的功能，以瞒住自己的需求。（如常见的日志功能，开始时可以手动进行相关查询。而后将其暴漏给后台服务应用中，在针对性的对数据进行展示。多数组织对于这些完善时抱着一种持续改进的态度来进行的）
- 设计能力的持续提升
TIP
如果出于人力、物力所限，设计的架构不够合理，也没关系——人的能力是在不断提升的。若是有机会回到之前的场景，再慢慢思考这个问题，仍然有可能感受当时的方案是最合适的。因此，对于方案而言，不存在最佳答案。建议大家在设计的时候为未来的改进留下一定的空间，以便于在未来隔离出这部分设计。
- 延迟决策
TIP
如果架构上有多个可演进的方向，无法做一个合适的决策，那么可以再条件更加充分的时候在做解决，而不是花费大量的实践盲目的修改架构，那样只会照成资源浪费。