我：作者对于单元测试这一章节的描述，采用的篇幅较大，解释较为完整了。我认同作者的判断。单元测试需要对单元的代码细节很清楚才能做好，单元测试的代码编写和执行也是需要由开发人员自己完成。集成测试主要由测试人员根据软件的功能手册进行测试，需要有专门的测试环境、测试数据配合。判断一个方式是否天生是可单元测试的办法是，看这个方法能否用一个 main 函数直接运行，如果可以的话就是可单元测试的代码。

另外一种办法就是该方法单元的参数，是否可以自由模拟，而不需要依赖外部环境。如果代码里有逻辑，不可以单元测试的话，我们是需要做代码改造的。改造的办法是把代码的执行顺序，就是单元的执行生命周期，做架构的拆分。有人说开发团队不应该配测试人员，应该给开发人员设置 KPI，写的代码直接上生产环境，出了问题就扣奖金，这是屁股决定脑袋的想法，制定规则的人一定没有写过代码或者不是真正搞技术的人。

　　软件架构的应用

这一部分作者以企业的交易业务为例，探讨了企业软件中的业务架构和软件架构，以及应该如何思考和应用业务架构的软件架构。在这一部分，作者分别对交易、产品、用户、订单、交易系统、事务，这些最容易落地和体现业务架构价值的领域进行了解释，这一切都需要你对于实际项目或产品的了解，才能够更好地理解作者的语言。

企业通过对生产的生命周期分工，雇佣员工，组织他们并行工作，可以得到更大的产能，这就是企业的组织架构。前几天有网友问我如何处理绩效不好的员工，我的想法是毕竟企业投入资金是需要有产出的，而个人绩效不好会最终影响到整个团队的绩效，所以需要做出相应的判断。当然，首先要正确地评估员工的能力，是否使用不当、是否他有其他的优点，也要综合考虑当前项目组情况，做出最有利于团队的决定。此外，作为技术管理者，你有责任把一群不怎么好的人，带领他们成为一支优秀的团队。

　　我所认识的软件架构

软件技术学习到一定水平后，我们会发现软件架构是一个门槛。这个问题已经存在很久了，在软件行业，对什么是架构存在很多的争论。看看市面上讲架构的书就知道了，卖的最好的往往是对于框架堆叠后如何使用的介绍，而不是真正从核心思想解释为什么需要这样架构，因为貌似前一类书最能直接解决问题，短期内也不会出现什么问题。对我来说，SSH 或 SHS 或 HSS，本身没有区别，我所关心的是为什么会有 SSH 的出现，他们分别解决了什么问题，他们还存在哪些问题，未来可能会出现怎么样的变化。

事实上，架构在软件发明前就已经存在很久了。我们应该多向大自然、艺术界、建筑界学习架构，因为软件并不是虚无缥缈的事物，它和我们的现实生活是紧密相关的，它的实质是来源于生活，最终又通过软件服务回到生活的一个全过程实践。

企业软件架构的设计不仅仅要注重于某一个系统功能，更需要给企业一个可进化的、可持续发展的、不断创新的平台，这和国家的整体发展也是类似的，只顾经济发展指标，不管不顾任何的环境污染，甚至于某水务局副局长说“经济越发达的地区，水越黑！”，一派胡言、其心可诛，急于求成，急于靠 GDP 让自己升职，才是这些人内心的写照。

万丈高楼平地起，地基是多么重要已经不用反复重复了。我女儿学习舞蹈过程中承受了一些痛苦，但我相信，只有能够承受这些，才能够真正地学会坚持的意义。

　　写在最后

坦白说，《聊聊架构》这本书不适合急于求成的工程师，也不适合完全没有架构经验或者思维的读者。它不是架构领域的武林速成秘籍，不像主流架构书那样对流行框架的公式般的简单或复杂堆叠。它带来的是对于计算机科学本身的尊重、对于架构的深入理解、对于未来的思考。这本书，是本好书，适合泡杯茶，坐在西湖边，慢慢品味。

读初中时我玩乒乓球，直板快攻球风酷似萨姆索诺夫。今天读《聊聊架构》，atv，它杂文式的叙述方式也是我所欢喜的。这本书文风貌似柔弱，但柔中有刚，这是我模仿不来的，我有我的风格，希望未来我能出一本架构书，《聊聊架构 _ 萨姆索诺夫版》。

读《聊聊架构》，迎面而来的是一阵盛夏的凉风。

　　作者介绍