三层架构，如何提高协作开发和联调效率
今天我研究的课题《三层架构，如何提高协作开发和联调效率》，作为一名刚走出校园应届生，这一课题对我来说是即陌生又熟悉，对于三层架构的诞生、理论和优缺点，往深了讲，是我在校园和往期实习工作中尚未接触到的深水区，然而在当前重构项目中我却又是其中的一名实践者——业务层开发人员。半年来的实践与开发，在架构师的带领下，摸着石头过河，在今天这个课题下，写下我对三层架构的思考与提高联调的解决方案。本人才疏学浅，深知在后端开发领域知识面不够深不够广，对于课题写下自己的一点想法。
一、什么是三层架构？
三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为：界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。区分层次的目的即为了“高内聚低耦合”的思想。
三层架构.jpg
通俗来讲就好像小朋友玩的积木一样，有一天，小朋友（客户）哭着要一个汽车玩具（界面层），无奈家境一般，为了满足孩子的愿望，父亲就想了个办法，买了很多积木玩具块回来，妈妈按照汽车组装步骤图（业务层逻辑层）组装一个个积木块（数据访问层）最后变成了一个汽车玩具，因为小朋友（客户）的需求是千变万化的，五彩斑斓的黑五光十色的白都有这么一个可能性，哪天哭着闹着要个飞机玩具那也是合情合理的，但回归底层，还不都是一个个小小的积木（数据库），世界上最不会变的那就是变化了，在客户第一的前提下，三层架构的提出是很重要也是不可或缺的。
三层架构-积木类比
二、三层架构的优缺点
很明显，重构后对于整个项目一切都是可观的，优点显而易见，缺点也不可忽略，重构后的优点:
1、结构清晰、耦合度低；结构更加的明确，可以降低层与层之间的依赖；开发人员可以只关注整个结构中的其中某一层；
2、可维护性高，可扩展性高；可以很容易的用新的实现来替换原有层次的实现；有利于标准化；在后期维护的时候，极大地降低了维护成本和维护时间
3、利于开发任务同步进行；容易适应需求变化，利于各层逻辑的复用。
重构后可能面临的问题点:
1、降低了系统的性能；这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改；这种修改尤其体现在自上而下的方向。如果在界面层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
3、增加了开发成本；这点是毋容置疑的事情，在人员上，本来需要两队人马完成的事情，现在需要三队人马；在时间上，三级联调，两个节点联调接口，需要的时间相比之前提高了。
然而公司重构项目从去年春节启动后到现在已有半年时间，在参与重构项目的开发过程中无疑是“不知庐山真面目，只缘身在此山”，持续不断的投入到业务开发和工作中，临近项目期末，现跳出围城进行知识上的扩展与升华，给出个人在参与项目过程中的一点思考与改进。
只有充分思考我们在实施项目的过程中的客观存在的问题，我们才能理性并合理的提出解决方案，我觉得有以下难点问题：
1、在需求不明确的情况下，产品和开发人员并行工作，产品输出远小于开发进度，从源头开始输入量小，下流前期输出量不多，拖到后期就导致功能开发紧张 。例如：到7月1号截止，优惠券活动审核的列表原型未出。
2、排查问题，怎样查能快速定位，找到原因，避免消耗人力过多。例如：前端说登陆不了，报系统错误，如何准确定位，解决问题。
3、前端、业务层、微服务三层架构中各层应用组件和技术相对前沿，在技术方面遇到的技术难点需要时间验证。例如：业务层在重构期间，经常出现模块节点挂的情况，经多次修改基础代码，各个模块均需要同步修改后的代码，消耗了一定时间。
4、顶层设计，错误码，子系统间衔接调用要先设计好。我们现在有但还不完美。
5、三层开发人员统一的开发进度规划，不能统一时间开发，当成流水线来安排。
二、提高协作开发和联调效率
产品同学：
1、需求必须明确，反复确认需求细节，真正理解需求和内在价值。
2、确认需求后需要确认关联人员的开发时间点，按照紧急程度，精确到天或小时。
开发同学：
1、自测：业务层和微服务自测一波再给接口，不要那么随性地就将开发中的接口丢给前端。
2、沟通：在自测过后的接口来进行联调本来就存在出错的可能性，例如：数据错乱、请求头为空等情况，联调出错是一种非常正常的情况，在联调过程中，大家一定要戒骄戒躁，相互理解，及时沟通，积极反馈。由测试同学做主推动，逐层反馈，落实责任人，给出期望完成时间，问题责任人完成后反馈。
3、log日志：主要以业务层的报错与警告来解决问题，目前业务层规范了log日志输出，在测试同学接口报错的情况下，定位到某一个微服务的报错和报错原因。但不可避免的需要人力的排查问题所在。
