架构学习

架构是什么？

架构，英文是 “Architecture”，在维基百科上，是这样定义的：

Architecture is both the process and the product of planning, designing, and constructing buildings or any other structures.

直译过来就是：架构是规划，设计和建造建筑以及其他结构的过程和产物。换一种说法可能更好理解：人类社会中的诸多活动，如建造建筑物，需要通过规划、设计、执行等几个步骤，最终得到一个成果（此处为被建成的建筑物），那么这整个过程，以及最终的成果就被称作架构。这项定义在其他任何具有创造性的活动中通用（比如编写软件）。

为什么要做架构？

一栋好的房屋，可以在提供稳定环境的前提下（不会随时塌方），最大限度的满足业主对房屋内部进行改造的需求；同样，一个好的软件框架，也应该在稳定的前提下（不随便崩溃），最大限度的满足用户对软件的改造或扩展的需求。

如何构建这样的软件框架，就是我们接下来所要完成的工作。

与建造房屋一样，在构建软件架构之前也要明确，该架构的最终目标是什么：不是为了盲目跟风、使用新的技术，也不是为了架构而架构……而是为了解决现有问题，提高团队整体的工作效率，为了能平滑的适应将来的变化等等。

因此我们可以得出这样一个结论：

从软件角度来说，一个“好”的架构是做好一个业务、甚至多个业务的基础。

如何做一个“好”的架构？

1.合适的边界

因为架构是实现业务的基础，也可以理解成架构是为了更好的实现业务服务的，但是现实中的业务多到数不胜数，没有任何一个架构能为所有的业务服务。就像大家都明白“永动机”是不存在的一样，一个能为世间所有业务服务的架构也是不存在的。因此想要做好一个架构，必须要明确它的边界，给架构规定一个范围，如果能在这个范围内能满足业务的需要，我们就可以认为这是一个“好”的架构。

2.合理的分工

就像搭建房屋需要管理人员、施工人员等多个角色分工，共同合作才能完成一样，构建架构也需要针对架构内部的事务进行分工：资历尚浅的人员，我们可以安排比较浅显的工作（如UI）；比较细心的人员，我们可以安排一些逻辑性较强的工作（如数据处理）；能力较强的人员，我们可以安排需要整体思维的工作（如底层架构）等；

3.高效的沟通

与其他工作一样，架构的过程也需要不同成员之间保持有效的沟通：上层业务需要将需求传递给下一层，这样下一层的人员才能明确应当如何满足上层业务的需求；同样的，下层业务也需要将提供的API的使用方式明确的告知上层，方能使上层业务人员合理的使用封装的API；

高效的沟通还需要包括统一每个成员的目标，因为沟通的目标是让成员互相了解，从而更好的完成架构的工作，只有让成员的工作目标保持一致，才能构建或更新出一个可以实现统一目标的架构。

4.统一的目标

架构是以整体为单位运作来产生价值的，不论是在架构的构建还是升级的过程，架构作为一个整体的共同目标必须保持一致；而这个目标，就是解决问题。

需要解决的问题很多，根据影响程度、和严重性，可以归纳出几个急需解决的问题。

急需解决的问题

目前我们面临的问题主要体现在：

界面改造困难：公司目前移动端的项目或产品，每一次升级的主要工作量在于对界面的改造，我们发现随着用户的增加和界面改造的需求的增加，改造界面的复杂程度越来越大，改动一个界面可能会引起其他界面或逻辑的不稳定；改造所耗费的时间也在逐渐提升；改造后产生的bug数量也居高不下；
冗余代码过多且不合理：以往我们会将公用的功能进行封装或形成组件，随着需求的增加，这样的功能类和组件也越来越多，不同的类和组件中存在交叉业务；有的新需求需要将原有的类或组件进行重组，产生新的功能类或组件，不仅使得代码体积变大，也会耗费额外的人力和时间，同时对代码后期的维护和升级带来了隐患；

原因分析

从具体问题分析

界面改造困难：实现业务时没有进行有效的分层和分工，导致不该在界面层出现的逻辑代码被写到了界面层，一旦界面需要修改，就势必会对业务逻辑产生影响；
冗余代码：功能、组件拆分不够彻底，拆分的颗粒过大；

整体分析

代码架构混乱，层级划分不合理，界面层、业务层、框架层的代码互相渗透；
规范不清晰，执行情况不佳：会造成后续的升级更加混乱；

明确了问题，也分析了问题产生的原因，就有了解决问题的方向。

如何解决现在的问题？

合理分层。比如：自上而下分为数据展示层、数据加工层、数据管理层；明确每一层的职责范围，严禁代码直接跨层调用；
合理拆分功能点。一个类只实现一个功能，多个功能组合形成新的功能（暂定）；
优化现有规范。着重点从“形”转为“神”，代码结构（逻辑）重于代码写法；

优化过程中的注意事项

必须从实现业务的角度思考，让业务工程师能专注业务的实现；
代码整齐，分类明确，规范统一；
易测试，易拓展，保持前瞻性；

预期的效果

业务工程师能专注业务实现，较少接触底层逻辑；实现业务层、界面层简单化，方便修改；
功能、组件拆分合理，不同的业务只关联与之相关的功能或组件，缩减包的大小；
形成统一的底层代码库，便于技术积累；且可作为协同、工厂等工程的公用底层库；

计划安排

从整体来看，阿米剪辑可以看做是一个简易版的阿米协同，而阿米协同相当于一个简易版的工厂

因此我们的计划是阿米剪辑 > 阿米协同 > 工厂，由简到繁，循序渐进。

关于时间的安排，会在接下来的几天内整理出来。