架构笔记九

　　有了好的架构还须要好的代码，在编写代码前，咱们要区分代码的类型，代码分两种：一个是表达业务逻辑的代码，表达业务逻辑的代码来源于现实生活的切分，是对生活的模拟和虚拟化，另外一种是对用户提供访问并保存业务逻辑运行结果的代码，这里有一个值得分析的名词业务逻辑。

　　业务逻辑是指的是软件代码中的逻辑，不是现实生活中的逻辑，是除代码缩进和计算顺序调用以外的逻辑，如下用严格的顺序调用来指代这种代码。由于顺序调用是计算机的特性，由编译器来决定的，固然最本质的是由于咱们计算的基础都是图灵机。在现实生活中，顺序调用也是逻辑，你们不要和咱们这里说的业务逻辑相混淆。

　　Service里面的代码严格的计算顺序调用的代码不须要作单元测试，也很难作单元测试，由于这些代码都须要和不少上下文打交道，因此代码只要作连通性测试便可，因为 Service 代码简单了，才可让咱们的开发人员投入更多的时间研究业务，毕竟这部分才是软件所真正服务的对象。Business 不访问任何上下文，不访问任何具体的设备，由于其余地方没有业务逻辑，因此一旦有问题，就能够判定是 Model 的问题，单元测试确定能够发现。若是单元测试没有发现问题，那么单元测试必定有问题。线上问题的模拟也就变得很是的简单，单元测试也可以获得进一步的补充。

　　在实际操做中，不能有逻辑，实际上和不少人的观念是冲突的，认为这个根本作不到。作到这一点须要不少的学习成本，可是必定能够作获得。当发现作不到的时候，能够判定是业务的分析出了问题。好比不应合并的合并了，不应计算的计算了。这个问题必定有办法解决的，作不到都是理由，无非是想早点把本身的工做结束罢了。虽然刚开始会比较困难，一旦把这个观念变成自觉，开发的质量和效率立刻就能高好几个级别

　　刚学习编程程序的时候，碰到一个问题，咱们老是想着怎样实现某个功能，而不是思考整个软件的架构问题，那时候只是以为作架构没什么意思，还浪费时间，可是这样的作法只会更加消耗咱们的时间成本，作一个小项目还能够，遇到大项目成本就会指数级增长

参看：架构漫谈