上篇我们介绍了一下架构的切分，以及切分的原则，这样就更加深了我们对架构的认识，然而对于我们这种 学习开发的人来说，总感觉落实到代码的层面比较空，没有具体的要求，只谈设计的话就会感觉比较茫然，所以本次我们就根据书中所说谈一下，如何从架构的角度来说写好代码。当有了好的架构，就应该考虑如何构建了，此时必须落实到代码层面了，要想完完成一个好的架构，就必须保证代码的质量，不能让代码成为架构扩展的瓶颈。
我们经常会听到，需要重写代码，需要推翻原有的架构，进行设计等等说法。其实这些情况都暴露了一个问题，当初在进行架构的实现的过程中仅仅是为了完成任务，是任务都已经实现，功能都能够完成，但是在逐渐的使用过程中却暴露很多问题，其开发的应用并不适用。并不符合实际的应用条件，不能完全的解决用户的问题。
实际上万物来源于生活，软件其实就是一个对现实生活的模拟，和虚拟化。是架构为我们明确了我们要开发的模块，明确的具体的功能，但是架构毕竟是一个大的框架，可以说架构师是在以一个上帝的视角来看待一个软件的，他所看到的是一个总体的框架，而具体的实现还是要靠着开发人员，不断的推理业务逻辑，结合实际的场景进行架构的细化。这就需要我们在开发代码的时候能关彻底的研究使用场景，不能仅仅为了完成任务而进行。用书中所提到的一个例子就是“业余选手，越想从水里浮起来，就越想把头抬起来，身体反而沉下去。只有克服恐惧，把头往水里压下去，身体才能够从水里浮起来。真正专业的习惯往往是和我们日常的行为相反的”只有能够真真的钻研之后才能保证架构的顺利进行。
在日常的生活中总是认为掌握越多的技术能力就会越强，技术人员往往瞧不起业务人员，任务技术更高端，更加又说服力，而业务太低端，只能是按照上层逐步的执行，并且业务人员只会给技术人员挖坑，找难题。
事实上，技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。
有了更好的技术，效率更差的技术，就会慢慢的被淘汰，消失，一切都遵从人类的利益诉求 -- 也就是业务，所以义务才是根本。只有在业务的推动下技术才能不断的进行更新，逐步的完善。对于我们技术人员来说其实最欠缺的就是业务运行的基本逻辑。所以在进行开发时首先要关注的不是该采用什么样的技术去开发，应该是学习期业务逻辑，在熟悉业务逻辑之后，规划出业务场景，往往开发的软件更贴近生活，更加成功。