what

什么是架构？

架构就是分离关注点，各关注点相互隔离又相互配合，围绕一个共同的目的各司其职，评估选择最合适的技术组合。分层架构设计包括展现层V+业务层C+数据层M，App前端开发就是一个自成一体的分层架构模型，模块划分、功能划分同时存在，MVC或MVVM设计模式就是一个简单的程序架构，只是业务逻辑比较简单，但本质依然是关注点分离然后通过一系列通信使模块与模块之间产生相互协作（协作方式典型如ReactiveCocoa）。这个关注点先根据模块来划分一个大的层次，然后又根据功能来进一步区分不同模块的逻辑职责，同时在划分功能的时候就得决定使用哪些现成的程序库（Library）和框架（Framework）。架构作为软件的骨架，不同的系统骨架在处理不同的系统负荷时，会有优劣之分，满足程序的质量性能要求尤其重要。骨架为动物提供了整体结构来支撑行动，比如鸟善飞、袋鼠善跳，四只腿的动物行动便捷，两条腿的动物则更善于使用工具。如果让袋鼠的架构基础上添加飞的需求，可不得重构嘛！为了后期的迭代开发，程序架构设计是必须在项目早期就做出的一组设计决策，而且这些决策也通常是项目后期难以改变的决策！程序架构设计就相当于军事上的谋定而后动，提前考虑好所做的事情会遇到的困难和陷阱，保证设计的架构能够满足产品的功能需求和质量性能等非功能需求。

软件架构师？

软件总体设计和制定技术开发文档、关键技术和算法研究、搭建软件总体架构、指定通信协议（也就是各模块之间的协作通信方式），同时作为业务向技术转化的桥梁，还要分析项目的功能性需求和质量等非功能要求，、技术选型（包括：语言选择、框架选择、公共模块等。数据怎么分表、后端接口怎么分、URL结构怎么定、前后端怎么接，一切围绕需求来定。比如性能、可伸缩性和安全性）、设计高性能的架构进行评审、从备选方案中选出合适的方案、制定项目计划和控制项目进度保障项目质量。

有待提升？

算法和数据结构，感觉用了我也不知道这是算法和数据结构，根本没概念

总结多线程编程，会用但说不出来

内存优化，性能优化

开源框架源代码，深入理解设计思想并能灵活运用，实在不理解，先照猫画符嘛，实践出真知

单元测试

通用架构模式？

SOA、AOP、MVC（如Spring MVC、MyBatis、Struts、Velocity等）、分布式(Redis、Memcache)、消息(RabbitMQ,kafka)、数据库（MYSQL、NoSQL）

质量性能等非功能性需求？

• 性能：响应时间有多快

• 可伸缩性：处理更多用户、请求、数据、消息的能力，开发电子邮件系统并不难，一旦要求高性能地支持百万级用户，就变得异常困难。最典型的就是登录大学教务网选择选修课，根本登不上呀，有木有！

• 安全性，从认证到授权到数据传输存储（安全验证）

• 业务连续性：就是灾难恢复，例如微信红包崩溃的快速恢复（报错处理）

• 审计日志，比如金钱交易记录（Log日志）

• 可扩展性，例如银行系统前期只是存储，后来实现结息，再后来又需要征收个人所得税

• 前提约束条件：运行在成本更低的UNIX平台、硬件限制、宽带限制、使用环境、网络攻击、系统整合、平台兼容

• 质量属性：易用且具鲁棒性，和程序健壮性和容错性含义相同。财会软件不够安全，动画软件执行缓慢那该多坑

好架构特征？

1、遵循单一责任的原则，关注点相互分离，不同的实体各思其职，易用且维护成本低。

2、方便进行单元测试。好多问题直到开始进行单元测试之后才开始显现出来。不同实体实体之间耦合度越低表示程序架构越精细，意味着单元测试越容易。

3、易用易维护。俗话最好的代码是那些从未被写出来的代码，代码写的越少问题就越少，所以开发者想少写点代码实现了需求意味着用了一个比较聪明的方法，同时从源头上减低了维护成本。

4、各模块分离合理，耦合度低，降低了层与层之间的依赖，层间的调用关系规范一致，利于各层逻辑的重用。

why

架构视图为什么重要？

本质是为了交流和传递设计思想，不同的人对架构的理解根本不一样，而架构师要为不同的人设计就必须通过设计视图来帮助架构师从不同的角度分而治之地设计。同一个地球仪，社会学家和气候学家关心的就是不一样。

为什么设计程序架构？

• 更好的理解。当我们试图去理解事物的工作原理的时候，划分可以减轻我们的脑部压力。如果有一天你需要去调试一个巨大无比又有着各种问题的类，那时候你就会迷失在这个类里面，根本就找不到也修复不了任何 bug好不好。因为逻辑与逻辑之间相互干扰，如果你不能找出他们之间的联系并加以区分，无疑是多个耳机线缠在一起的感觉。把一个类作为整体放在脑子里记着是一件非常困难的事情，你总是难免会忘掉一些比较重要的细节。理清控制器逻辑通常需要考虑的问题可能包括：1、控制器VC类与父类的继承关系 2、控制器VC类需要长期保存的数据保存在哪里。3、控制器VC类与子视图View的关系。4、控制器VC类与Model的关系，model除了作为纯粹的数据结构还有什么功能。4、控制器VC类是否能够进行单元测试。

• 更好的测试。排查性能问题往往比排查功能性的Bug更让人头疼，主要有以下几个原因：1、很多性能问题只会在高负载的生产环境下出现，在开发过程中很难发现。 功能性出错时我们通常会抛出异常，我们可以通过Tracestack很快定位到问题所在代码的位置。但对于性能问题，我们很难做这样的快速定位。 虽然我们有各式各样的Profiling工具，但适用于对生产环境的并不多。对于服务器端的性能问题，可以通过日志文件进行分析，例如把每个请求的响应时间都记录下来，但对海量日志文件的存储，聚合与分析又成了另一个麻烦。架构会有效地减少模块的复杂性，带来更轻量的业务层，将使得表示逻辑更加易于测试。

• 更好的扩展。架构作为迭代开发的基础，开发维护扩展难度。提前考虑项目设计的限制条件，如果前期架构没弄好，后期自然难以维护、运行速度慢、稳定性差、宕机频繁。一个不好的架构会随着需求的增加使得代码库变得越来越复杂，当队伍中加入新的开发者时便会陷入困境。

• 更好的质量。系统质量与程序架构的设计息息相关。

• 更多的重用。良好的架构统筹考虑所有的模块，严格区分功能模块和通用模块，不会产生功能的重叠，方便模块的复用，主要是针对 View 和 Model，几乎没有重复代码。

• 更高的效率。方便业务功能的分工，易于独立工作，更利于技能的专业化提升。人的架构和马的架构都能托苹果，但是运输效率和数量就相差甚远，好的架构，事半功倍。

为什么MVC正在被替代？

Cocoa MVC 鼓励你去写重控制器是因为 View 的整个生命周期都需要它去管理，Controller 和 View 很难做到相互独立。虽然你可以把控制器里的一些业务逻辑和数据转换的工作交给 Model，但是你再想把负担往 View 里面分摊的时候就没办法了；因为 View 的主要职责就只是讲用户的操作行为交给 Controller 去处理而已。于是 ViewController 最终就变成了所有东西的代理和数据源，甚至还负责网络请求的发起和取消，还有...剩下的你来讲；最重要的一点是控制器业务逻辑太多灰常灰常不利于进行单元测试。

how

书本的架构举例？

网上商城系统、银行存储系统、航空订票系统、B2C电子商务网站、汽车嵌入式架构（层次化设计、服务层、ECU抽象层、微控制器抽象出层。模仿微软的DirectX架构、分布式架构）、腾讯QQVideo架构（1、水平分层+统一管理各类资源；2、不同功能垂直分离+资源分别对待；这里的不同功能包括视频、视频缩略介绍图、静态Web内容、动态Web内容）、微软MFC（Microsoft Foundation Classes）架构（应用支持层+抽象引入层+Win32封装层）、邮件代发系统、人事管理系统

MVVM使用？

1、将 viewDidLoad 中的表示逻辑放入我们的 ViewModel 里了。同样的代码，只不过移动了位置。

2、A视图的属性与B视图的属性进行对比使用，那么必须在控制器VC里面既实例化A又实例化B，然后再进行对比，如此便会增加一个用来比较的层级的逻辑，那么问题来了，为什么不把这个层级抽离出去呢？抽离到ViewModel里面去。

3、Model这个对象的属性本质是用来记录数据的，也就是不变的。那么如果需要某种情况下Model里面的某一个属性进行更改，应该怎么办呢？常规办法就是通过数组的序号把这个模型找出来，然后修改，毕竟模型不是单例，不能随便实例化的。而通过协作绑定让ViewModel持有Model属性，同时在初始化控制器的时候，将ViewModel的Model属性与控制器的数据变化绑定。如此只要控制器的数据发生变化，直接就将变化后的新值传递到ViewModel的Model属性的特定属性上