看到 InfoQ 宣传这本叫《聊聊架构》的书，自己买了一本，同为书作者，我理解写书人的辛苦，买本书以表支持。我每年会从国内外买很多书，其中相当一部分不会最终留在我的书架里（我可没有很多钱买 10 套房子存书），而这本书，一直会有它的位置。写这篇文章，纯粹是出于对于技术的热爱，对技术人员的尊重，对计算机科学的膜拜，不是替人站台。我们今天只谈书、谈架构、谈软件，不谈人。

　　认识架构

作者花了十一章（第一章至第十一章）讲述这个话题。从生命周期的拆分开始讲起，谈到了生命周期和时间的关系，谈到了人类活动的分工安排，谈到了自然界万千架构场景，也谈到了永恒的对比“建筑架构 VS 软件架构”。

这一部分，有过架构经验、深度思考的人会有所碰撞，正如作者所说：

「一个生命周期里面的活动可以进行拆分，拆分的原则就是形成若干个新的生命周期，每个新的生命周期都有自己的主体。在把一个大的生命周期拆分为多个小的生命周期后，核心生命周期活动的执行都严格地在时间上连续。而非核心生命周期的管理，则围绕着核心生命周期形成了一个树状结构。随着大的生命周期的拆分，树在逐渐地长大。」

我：作者这十一个章节，其实我考虑了十几年，一直没有想好怎么抽象出来。坦白说，作者“浪费”了这么多的纸张，写了这些与技术看似无关的文字，会让很多人觉得虚，对于写书的人来说，这是需要担忧的。既然作者敢于突破，本文中我也不会避讳自己的看法，我会亮出犀利的一面。我觉得，这一部分内容是需要的，尤其在当下这个缺少精神概念的时代。

我认为，无论计算机技术或是软件技术，本身都是科学，不仅仅是谋生手段。既然是科学，必然存在着与其他学科的交叉。当前持不同意见者，可能十年、二十年后，当你们有时间停下来静静思考，不必再忙于奔波赚钱，会有所感悟。正如我微信里一篇文章的读者留言所说“看一帮 50 多岁的俄罗斯程序员写代码，像在看小说”，这是艺术，不是对框架的简单堆叠。

　　软件架构

作者：软件的目的是把现实生活模拟到计算机中，并且软件是需要在计算机的硬件中运行起来的。要做到这一点需要解决两个问题，分别是业务的问题、计算机的问题。

我：是的。技术管理人所需要具备的能力第一条就是，需要能够做到技术的业务派、业务的技术派，需要能够真正理解业务，为业务部门解决问题，这样你的技术才会在业务部门眼中具有价值，才会持续投入。而对于计算机的问题，我们在开发过程中需要对过程进行拆解，按照软件开发生命周期和软件运行生命周期，这两个周期分别进行管理，不能出现生命周期中某些子生命周期颠倒的情况，例如先编码，j2直播，后设计或压根没有设计，这实质是软件开发的最大痛点。

作者：软件架构就是通过软件生命周期的拆分，在符合业务架构的前提下，以达到软件本身访问增长目的的方式。这个增长需要软件开发的增长，也需要软件运行的增长，由此达到所支撑业务的增长。

我：电子工业出版社董英老师前不久给我寄送了阿里最新出版的“双十一”技术书，里面有一段谈到了天猫供应商对于阿里技术的要求，大体是“我们不求技术突破，但求系统稳定，因为你们不稳定，我们提前备货的手段就可能造成破产、失业，求求你们了”。没有实质业务的支撑，没有对生命周期的合理拆分、管理，谈不上后续发展。

作者：很多公司设了软件架构师的职位，主要职责是做出架构设计，也具备一定的影响力，但并不具备调动组织架构的权利。这样的职位往往达不到架构师的效果，有时候还会起反作用。软件架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好地发挥架构师的作用，才能够把软件开发生命周期、软件运行生命周期和业务生命周期的拆分落实执行。软件开发团队的组织领导人其实都是架构师，只是没有这个头衔而已，真正的架构师不一定具备架构师的头衔。一个好的领导，就是一个很好的架构师。在这个架构师的领导下，这个组织一定是健康向上的。

我：我认同作者对于组织领导需要是架构师的观点。一个开发团队的领导，如果你不能在架构方面给出意见，那你就不能在整个设计环节给出自己的观点或者对于团队的指导，你也就会在整个软件开发流程中脱节，进而丢失自己的技术领导力，也就做不成技术管理者。对于一名优秀的技术管理者，技术在前，管理在后，并不是说两者有太大的轻重差异，而是你需要花费 70% 的时间在技术上，只能花 30% 的时间在管理上，但是你需要用这 30% 的时间做完 100% 的管理工作，技术、管理，一样都不能差，架构能力，也是一样。