8、 从架构的角度看如何写好代码
代码对于一个软件工程专业的学生再熟悉不过，关于代码架构的那一篇文章现在虽然看不到，但我依旧从第八篇文章中得到了部分结论，重写代码，推翻原有架构，重新设计等等说法，来说明架构的进化。这实际上就是当初为了完成任务，没有充分思考所带来的后果。这也并不是架构进化的事情，而是个人对问题领域的逐渐深入理解的过程。所以有必要再讨论一下，代码的架构应该是怎样的。
首先提到的就是业务逻辑，在软件代码中，不需缩进和计算的顺序调用，包括缩进的代码目的是 catch exception 的，都不算逻辑，除此以外都是逻辑。这里通过实例，为我们介绍了业务逻辑等相关知识，也提到了，我们真正想快速的完成代码工作，就要克服自己对时间的恐惧，真正的去研究业务的问题，相关 stakeholder 的利益，把这个变成我们的习惯。写代码的时候让该出现逻辑的地方出现逻辑，让不该出现的地方不能出现。一旦不该出现的地方出现了逻辑，那么要马上意识到，这个地方是一个坑，这个问题一定和业务的分析不透彻有关系。
读到这里，我突然发现一个问题：“克服恐惧”,在《架构漫谈》系列文章中，确实提到了不少关于克服恐惧的观点，想想自己编码时的烦躁，确实，有很大一部分是恐惧，畏惧，不确定，害怕自己时间不够，害怕自己花费了时间没有完成，害怕自己实现不了相关功能，这里确实，我们在开发的路上，需要克服的恐惧很多，每个阶段都要克服自己心里不同的恐惧。
9、 理清技术、业务和架构的关系
文章开头提到的那个关于开发软件的话题我觉得很有意思：“作为架构师或者做技术的人，在开发软件时，我们基本上就是在扮演上帝的角色：我们不但要创建出一个个的程序，还要让这些程序能够脱离我们在硬件上独立运行，以便为这个程序所服务的群体提供服务。当这个程序出现问题甚至 bug 的时候，我们还得扮演牧师的角色去修复这些问题。”让我又从另一个方面认识了所谓编程，所谓开发，就是建立一个程序的社会，我们都在这个社会中扮演重要的角色，
技术的产生是为了解决一个业务目标（比如取火），这里解决的是人类自己的问题，实现人类的利益，技术总是在人类解决对业务的要求不断提高的情况下产生，目的也是为了获取更大更好的利益。一般是先有技术，才会有架构。这些其他技术（弓弦拉动木棍），是从直接解决问题的初始主要技术中分拆出来形成的，并通过树状结构和主要技术（钻木取火）组合在一起。在解决主要问题（生火）之后，再开始逐渐的分拆为更为细粒度的技术（弓弦转木棍）。
最后讲解了业务人员和技术人员的冲突产生以及解决，这里就提到了软件架构师重要性，架构师应该承担起解决业务问题的这个角色来，专注于 Business Domain 和软件本身的架构，让技术人员致力于为业务在计算机中跑起来而努力。只有把这两者很好的结合起来，才能更好地完成业务的目标，才会让软件更好地服务于大家。
总结
在阅读完《架构漫谈》系列文章之后，我感觉自己之前的一些关于软件，关于编码的认知在不断的被刷新中，以及了解了软件架构的必要性和必然性，以及要成为一名软件架构师要具备的能力，和承担的角色，已经架构在整个软件开发中的作用。