之前我们介绍了两篇架构的博客，对于我们这种还在大学的学生，理解这些很难，没有代码的支持都是空谈，所以这次我读了如何写代码的部分，如何从架构的角度来说写好代码。当有了好的架构，就应该考虑如何构建了，就必须落实到代码层面了。
写代码的过程中，可能有时候需要重写代码，就会产生推翻原有架构，重新设计架构等等说法。这就证明一个问题，最开始设计的架构仅仅是为了完成任务而设计的，并没有为整体布局考虑，一旦需要更正某些模块，都影响到整体的架构，这样并不符合实际的应用条件，不能完全的解决用户的问题。
生活是一个很好的镜子，我们开发的软件就是跟生活密切相关。是架构为我们明确了我们要开发的模块，明确的具体的功能，但是架构毕竟是一个大的框架，可以说架构师是在以一个上帝的视角来看待一个软件的，他所看到的是一个总体的框架，而具体的实现还是要靠着开发人员，不断的推理业务逻辑，结合实际的场景进行架构的细化。这就需要我们在开发代码的时候能关彻底的研究使用场景，不能仅仅为了完成任务而进行。用书中所提到的一个例子就是“业余选手，越想从水里浮起来，就越想把头抬起来，身体反而沉下去。只有克服恐惧，把头往水里压下去，身体才能够从水里浮起来。真正专业的习惯往往是和我们日常的行为相反的”只有能够真真的钻研之后才能保证架构的顺利进行。
平时的开发生活中，技术人员可能会瞧不起业务人员，任务技术更高端，更加又说服力，而业务太低端，只能是按照上层逐步的执行，并且业务人员只会给技术人员挑问题，找麻烦。
事实上，他们都是相辅相成的，没有了业务也就没了开发，没了开发也就没了业务，缺一不可。
高端的技术会淘汰低端的技术，一切都必须符合人类的利益诉求 -- 也就是业务，所以义务才是开发的根本。只有在业务的推动下技术才能不断的进行更新提高，逐步的努力完善。最正确的的应该是学习业务逻辑，在熟悉业务逻辑之后，规划出业务场景，开发的软件如果更贴近生活，也就会更加成功，生活是成功之本。