看到 InfoQ 宣传这本叫《聊聊架构》的书，自己买了一本，同为书作者，我理解写书人的辛苦，买本书以表支持。我每年会从国内外买很多书，其中相当一部分不会最终留在我的书架里（我可没有很多钱买 10 套房子存书），而这本书，一直会有它的位置。写这篇文章，纯粹是出于对于技术的热爱，对技术人员的尊重，对计算机科学的膜拜，不是替人站台。我们今天只谈书、谈架构、谈软件，不谈人。
作者花了十一章（第一章至第十一章）讲述这个话题。从生命周期的拆分开始讲起，谈到了生命周期和时间的关系，谈到了人类活动的分工安排，谈到了自然界万千架构场景，也谈到了永恒的对比“建筑架构 VS 软件架构”。
这一部分，有过架构经验、深度思考的人会有所碰撞，正如作者所说：
「一个生命周期里面的活动可以进行拆分，拆分的原则就是形成若干个新的生命周期，每个新的生命周期都有自己的主体。在把一个大的生命周期拆分为多个小的生命周期后，核心生命周期活动的执行都严格地在时间上连续。而非核心生命周期的管理，则围绕着核心生命周期形成了一个树状结构。随着大的生命周期的拆分，树在逐渐地长大。」
我：作者这十一个章节，其实我考虑了十几年，一直没有想好怎么抽象出来。坦白说，作者“浪费”了这么多的纸张，写了这些与技术看似无关的文字，会让很多人觉得虚，对于写书的人来说，这是需要担忧的。既然作者敢于突破，本文中我也不会避讳自己的看法，我会亮出犀利的一面。我觉得，这一部分内容是需要的，尤其在当下这个缺少精神概念的时代。
我认为，无论计算机技术或是软件技术，本身都是科学，不仅仅是谋生手段。既然是科学，必然存在着与其他学科的交叉。当前持不同意见者，可能十年、二十年后，当你们有时间停下来静静思考，不必再忙于奔波赚钱，会有所感悟。正如我微信里一篇文章的读者留言所说“看一帮 50 多岁的俄罗斯程序员写代码，像在看小说”，这是艺术，不是对框架的简单堆叠。
作者：软件的目的是把现实生活模拟到计算机中，并且软件是需要在计算机的硬件中运行起来的。要做到这一点需要解决两个问题，分别是业务的问题、计算机的问题。
我：是的。技术管理人所需要具备的能力第一条就是，需要能够做到技术的业务派、业务的技术派，需要能够真正理解业务，为业务部门解决问题，这样你的技术才会在业务部门眼中具有价值，才会持续投入。而对于计算机的问题，我们在开发过程中需要对过程进行拆解，按照软件开发生命周期和软件运行生命周期，这两个周期分别进行管理，不能出现生命周期中某些子生命周期颠倒的情况，例如先编码，后设计或压根没有设计，这实质是软件开发的最大痛点。
作者：软件架构就是通过软件生命周期的拆分，在符合业务架构的前提下，以达到软件本身访问增长目的的方式。这个增长需要软件开发的增长，也需要软件运行的增长，由此达到所支撑业务的增长。
我：电子工业出版社董英老师前不久给我寄送了阿里最新出版的“双十一”技术书，里面有一段谈到了天猫供应商对于阿里技术的要求，大体是“我们不求技术突破，但求系统稳定，因为你们不稳定，我们提前备货的手段就可能造成破产、失业，求求你们了”。没有实质业务的支撑，没有对生命周期的合理拆分、管理，谈不上后续发展。
作者：很多公司设了软件架构师的职位，主要职责是做出架构设计，也具备一定的影响力，但并不具备调动组织架构的权利。这样的职位往往达不到架构师的效果，有时候还会起反作用。软件架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好地发挥架构师的作用，才能够把软件开发生命周期、软件运行生命周期和业务生命周期的拆分落实执行。软件开发团队的组织领导人其实都是架构师，只是没有这个头衔而已，真正的架构师不一定具备架构师的头衔。一个好的领导，就是一个很好的架构师。在这个架构师的领导下，这个组织一定是健康向上的。
我：我认同作者对于组织领导需要是架构师的观点。一个开发团队的领导，如果你不能在架构方面给出意见，那你就不能在整个设计环节给出自己的观点或者对于团队的指导，你也就会在整个软件开发流程中脱节，进而丢失自己的技术领导力，也就做不成技术管理者。对于一名优秀的技术管理者，技术在前，管理在后，并不是说两者有太大的轻重差异，而是你需要花费 70% 的时间在技术上，只能花 30% 的时间在管理上，但是你需要用这 30% 的时间做完 100% 的管理工作，技术、管理，一样都不能差，架构能力，也是一样。
另一个观点是作者没有提到的，我认为架构师可以由专门的个人或者团队组成，他们承担新技术、框架的调研工作，负责对用户提出的需求进行评估，采用新的技术做出产品原型、技术调研报告，供产品部门在技术选型和技术架构选型时作为参考，这也可以体现架构师的水平和贡献。
作者：技术本身是没有好坏的。比如最早的计算机软件是单机运行的，逐渐发生了架构拆分，形成了 C/S 的架构。随着互联网技术的发展，变成了 B/S。其实是换汤不换药，Browser 还是一个 Client。但是因为 Browser 的普适性，其实就是又做了一个架构拆分，成了一个通用的 Client，做到了很多 C/S 时代做不到的事情。互联网时代的技术人员对 C/S 架构鄙视得一塌糊涂。到了 App 时代，又回到了 C/S 时代的做法，因为 HTML5 响应慢，无法适应手机客户端。所以说，随着人们问题的不断变化，会有不同的技术周期的出现，会有不同的技术周期出现，技术有自己的生命周期。没有永远最好的技术，也没有永远最差的技术，而问题总是在不断发生变化的，对于这一点，架构师要有清醒的认识。
我：其实我不太喜欢面试培训班出来的技术人员，他们可以滔滔不绝地和你描述各种框架的使用，细微到某一个参数，每遇到这种场景，我真想用英语说“I don’t care”。并不是有偏见，而是我真的不在乎你懂不懂参数的配置，我要问的是计算机科学基础知识，聊算法、聊数据结构、聊设计模式、聊你参与过的系统架构设计、聊内存管理机制和垃圾回收机制、聊你对于技术的情怀。框架的选择，实质上是对于技术可行性的选择，这又需要符合当前的业务形态，所以，正如作者所说，没有哪一个技术或者框架是最好的，只有最适合你的产品需求的，才是最好的。
作者：对于开源者来说，开源是把自己的理念介绍给外部的一个手段，和写一本书是一样的。区别之处在于，写一本书是在读者大脑里运行的，而代码是在计算机中运行的。相同之处在于，要想让代码在计算机里运行好，读者仍然需要理解作者遇到困难时，为何这样思考，找到作者解决问题的独特思路。也就是说，代码最终还是要和书一样在读者的大脑里运行起来，才能够把代码所产生的软件运用好。
我：认同作者观点。很多公司都在内部讨论是否应该开源，看看 Google 就知道你的答案了，人家一天到晚在开源，依然保持引领全世界的技术发展，并没有被看懂开源代码的对手超越。这里作者提到了写书，同为作者，我知道其实写书不能赚多少钱，但是我有一个梦想，这一生出版超过 60 本书，一本一本脚踏实地写起来，梦想还是要有的，万一实现了呢。
作者：很多软件工程师学了大量的算法和计算机基础，然而在工作中发现派不上用场。这是非常正常的，因为这些内容是为了在科学领域做研究准备的。而在业务领域，大多是如何把现有的业务在软件中模拟出来的问题，并没有太多高深的数学问题。并且现在的计算机硬件，比如 CPU、内存、存储等都非常便宜，也不需要斤斤计较地去扣时间和空间复杂度。这些都导致所学不能致用。反而如何能够高效地把业务用软件表达出来，并能够随着业务的增长，让软件也快速地长大，则变成了一个更重要的问题。这一点可能是当前计算机软件教育需要思考的问题。
我：Absolutely。
作者：单元指的是代码调用的最小单位，实际上指的是一个功能块或者方法。所以单元测试指的就是对这些代码调用单元的测试。单元测试是一种白盒测试，相对而言，集成测试基本都是黑盒测试。有人会问，如果方法就是单元，一个软件包含那么多方法，那单元测试会成倍数增加程序员工作量，这个问题确实存在，但是有了单元测试，每天能够看到自己的单元测试运行结果全部是绿色，或者正在逐渐把红色的变成绿色，心理的成就感是非常强的。由于形成了代码编写的反馈环，所写的每个代码都能够快速的从单元测试中看到变化，软件工程师会对写代码保持极大的兴趣，每天都能够有强大的动力去修改代码，而且心理也会感到更安全。在与人沟通时，心里也会更有底气。
我：作者对于单元测试这一章节的描述，采用的篇幅较大，解释较为完整了。我认同作者的判断。单元测试需要对单元的代码细节很清楚才能做好，单元测试的代码编写和执行也是需要由开发人员自己完成。集成测试主要由测试人员根据软件的功能手册进行测试，需要有专门的测试环境、测试数据配合。判断一个方式是否天生是可单元测试的办法是，看这个方法能否用一个 main 函数直接运行，如果可以的话就是可单元测试的代码。
另外一种办法就是该方法单元的参数，是否可以自由模拟，而不需要依赖外部环境。如果代码里有逻辑，不可以单元测试的话，我们是需要做代码改造的。改造的办法是把代码的执行顺序，就是单元的执行生命周期，做架构的拆分。有人说开发团队不应该配测试人员，应该给开发人员设置 KPI，写的代码直接上生产环境，出了问题就扣奖金，这是屁股决定脑袋的想法，制定规则的人一定没有写过代码或者不是真正搞技术的人。
这一部分作者以企业的交易业务为例，探讨了企业软件中的业务架构和软件架构，以及应该如何思考和应用业务架构的软件架构。在这一部分，作者分别对交易、产品、用户、订单、交易系统、事务，这些最容易落地和体现业务架构价值的领域进行了解释，这一切都需要你对于实际项目或产品的了解，才能够更好地理解作者的语言。
企业通过对生产的生命周期分工，雇佣员工，组织他们并行工作，可以得到更大的产能，这就是企业的组织架构。前几天有网友问我如何处理绩效不好的员工，我的想法是毕竟企业投入资金是需要有产出的，而个人绩效不好会最终影响到整个团队的绩效，所以需要做出相应的判断。当然，首先要正确地评估员工的能力，是否使用不当、是否他有其他的优点，也要综合考虑当前项目组情况，做出最有利于团队的决定。此外，作为技术管理者，你有责任把一群不怎么好的人，带领他们成为一支优秀的团队。
软件技术学习到一定水平后，我们会发现软件架构是一个门槛。这个问题已经存在很久了，在软件行业，对什么是架构存在很多的争论。看看市面上讲架构的书就知道了，卖的最好的往往是对于框架堆叠后如何使用的介绍，而不是真正从核心思想解释为什么需要这样架构，因为貌似前一类书最能直接解决问题，短期内也不会出现什么问题。对我来说，SSH 或 SHS 或 HSS，本身没有区别，我所关心的是为什么会有 SSH 的出现，他们分别解决了什么问题，他们还存在哪些问题，未来可能会出现怎么样的变化。
事实上，架构在软件发明前就已经存在很久了。我们应该多向大自然、艺术界、建筑界学习架构，因为软件并不是虚无缥缈的事物，它和我们的现实生活是紧密相关的，它的实质是来源于生活，最终又通过软件服务回到生活的一个全过程实践。
企业软件架构的设计不仅仅要注重于某一个系统功能，更需要给企业一个可进化的、可持续发展的、不断创新的平台，这和国家的整体发展也是类似的，只顾经济发展指标，不管不顾任何的环境污染，甚至于某水务局副局长说“经济越发达的地区，水越黑！”，一派胡言、其心可诛，急于求成，急于靠 GDP 让自己升职，才是这些人内心的写照。
万丈高楼平地起，地基是多么重要已经不用反复重复了。我女儿学习舞蹈过程中承受了一些痛苦，但我相信，只有能够承受这些，才能够真正地学会坚持的意义。
坦白说，《聊聊架构》这本书不适合急于求成的工程师，也不适合完全没有架构经验或者思维的读者。它不是架构领域的武林速成秘籍，不像主流架构书那样对流行框架的公式般的简单或复杂堆叠。它带来的是对于计算机科学本身的尊重、对于架构的深入理解、对于未来的思考。这本书，是本好书，适合泡杯茶，坐在西湖边，慢慢品味。
读初中时我玩乒乓球，直板快攻球风酷似萨姆索诺夫。今天读《聊聊架构》，它杂文式的叙述方式也是我所欢喜的。这本书文风貌似柔弱，但柔中有刚，这是我模仿不来的，我有我的风格，希望未来我能出一本架构书，《聊聊架构 _ 萨姆索诺夫版》。
读《聊聊架构》，迎面而来的是一阵盛夏的凉风。
作者介绍
周明耀，2004 年毕业于浙江大学，工学硕士，国外投资银行 12 年工作经验，4 年分布式系统、物联网工作经验，10 年技术团队管理经验，已提交分布式计算领域发明专利 15 项。业余时间担任 IBM 开发者论坛专家作者、InfoQ 专栏作者，九三学社社员。著有《大话 java 性能优化》、《深入理解 JVM & G1 GC》，即将出版《技术领导力—如何带领一支软件开发团队》。微信号 michael_tec。
自《聊聊架构》上架以来，受到了读者们的广泛好评。
为回馈读者们的喜爱，小 Q 自作主张要来了一个读者回馈的粉丝福利。
《聊聊架构》金句赏析活动
如果你是已经收到书了的老读者，摘抄下《聊聊架构》里的金句加以自己的阐释，即可参与。
如果你是还没看过本书的新用户，写下你对本书最大的期待，你对架构的理解与想象，也可参与。
点赞数最高的前 20 条精选评论，将获得由 InfoQ 送出的《聊聊架构》修订版一本。
活动截止时间：本周三 18 点
活动解释权归 InfoQ 所有。
等不及活动结束的同学，也可以扫码下单，修订版新鲜上架，京东物流急速发货！
我们渴望一个爱读书的你！
