《一线架构师实践指南》书评

中国的架构师必看

一本好书，从软将开发的各个阶段对软件架构的工作进行了一次梳理，使得架构工作的边界更为清晰，架构工作的内容有章可循。 但从另外一个角度说，没有几年设计工作经验的程序员，建议还是不必读。因为架构的层次，又比设计要更抽象。敏捷开发的实践者，可以阅读本书作为对传统瀑布式开发的一个回顾。敏捷开发一般来说，不会在项目初期决策架构的问题。最近做的都是无技术的管理工作，还是喜欢纯技术的东西。

是《软件架构设计》的精编版本

看完《一线架构师实践指南》，有种似曾相识的感觉，于是我就回头去翻了翻作者的前一本书《软件架构设计》。发现很多内容在《软》里面都有，但是当时看《软》的时候给我的印象没有这么深刻。可能是因为前书内容较多，覆盖面较广，更像是一本基础教程，需要读者反复研读，感觉在章节组织和重点突出方面确实还有改善的余地。而《指南》确实是更加突出了它对架构设计人员的引导作用。个人觉得有以下几个方面体现了这一点。1) 全书大致分为 3 个章节，以架构设计的 3 个阶段为划分；2) 强调分析方法和分析工具，比如 ADMEMS 矩阵，在《软》里面也有相同的内容，但是没有具体强调；3) 对 5 视图进行深入细化总的来看，《指南》能给从业人员一些指导意见，看过一遍之后可以作为工具书时常查阅。不过由于领域和团队情况的不同，书中的某些方法还需自己在实际工作中进行加工后才能使用。希望温昱老师接下来能写一写软件框架方面的内容，拓展一下《软》里面的章节 2.5 ，还望各位编辑、策划者考虑和转达，谢谢！

算是入门的架构类书籍吧

自己买来的技术书很少有能从头至尾读完的，但是这本算是例外，倒不是说书多好多好，主要是章节安排上感觉比较合理，每一章都不是太长，恰好能在不想继续看的时候看完一章，哈哈！总体感觉还不错，适合刚刚接触架构的人，比如我这种二把刀（没有经过正儿八经的培训和高人指点，靠自学成才的），能够帮助梳理一个比较清晰的思路和一些最基本的架构原则。个人比较认同第二部分概念架构和第四部分非功能需求相关的观点，其他部分没有太大感觉。尤其是第15章数据架构部分，觉得比较烂，写的东西都是大路边上的，没啥干货！很少写书评，这是第一次，这是个好习惯，以后可以偶尔为之！

一线咨询师的絮絮叨叨

温昱先生的《一线架构师实践指南》在几乎所有的售书网站上都是一致推荐的一本书，当当4星半，china-pub 4星半，亚马逊卓越上也是4星，就连最客观的豆瓣上，也有7.3分之高。我这种买书大大咧咧的人有幸收了这本书也不算怪事，书大致收藏于2010年，最近清理书架，觉得薄，想顺手啃了，翻了几页，觉得不知所云，于是重新上网看了看资料和评论，担心自己是不是走眼了，继续苦读了一下，理了个头绪。此书主要围绕CSAI搞的一个ADMEMS的架构设计方法，将架构设计的方法分成了3个阶段，Pre-Architecture阶段（明确需求）、 Conceptual Architecture阶段（分析需求，进行概要设计）和Refined Architecture（架构详细设计）阶段，在这3个阶段中还要持续关注非功能需求（比如性能，安全，重用等）。ADMEMS方法本质还是以建模和图形辅助分析为主，同时创造了一些自己的方法比如ADMEMS矩阵，帮助进行需求分析。好了，上面这句话基本就概括我对这本书的理解，但你只用看一遍我这句话就可以了（读者不用读懂，因为这个概括也是一句废话），这本书你也就不用看了，仅此而已。从这个方法的出处来大家也可以明白，这本书的目的是帮助做咨询培训，目的和IBM推广RUP和UML建模分析是一个道理，路数也接近。20个专家推荐的噱头也就是20个CSAI的人一起来捧场而已。另外特别有意思的，文中大量的文字描述“业界以为XXX等同于XXXX”，作者为了突出自己方法的优点，一定要和其他一些分析方法找出区别，甚至包括认为用例驱动开发的观念值得商榷等，大都是一些断章取义。其实就是作者为了突出自己方法的优点，标新立异而已罢了。全书讲的东西其实没有什么特色，建模工具仍然用的UML，分析方法还是软件工程中最基本的一套，没有实质创新，只是不断的翻炒一些概念和忽悠一些概念，那3个阶段说白就是需求阶段，概要设计阶段，详细设计阶段架构师要做的事情，但作者非要学习阿Q，一定要抖抖索索，费劲力气把这个圆圈画圆了。全书中唯一有一点ADMEMS自己独立特色的东西是一个叫二维需求观和ADMEMS矩阵的东东，有一章的精华全部在里面。但其实骨子只是对需求细化分析，而其中的组织需求和用户需求，质量和约束这些概念都是一些牵强的强制划分，并没有多少可以参加的依据和道理。另外全书还有一个问题就是废话太太太太多，虽然这类咨询的大部分本质都是将正确的废话。比如说，对于需求要分层，这话有道理不，当然有，但绝对是一句废话。而这本书在废话这个问题有点过火了，举个例子里面的那个5视图法的图片，同类型的就至少出现了3次，然后每个图分拆开再出现一次，作者的目的大概和大内密探里面那个解剖外星人一样，一遍一遍一遍一遍一遍又一遍的重复，是希望我们印象更深刻一点把。当然这个图和本书的风格仍然一致，看似井井有条，实则仍然是正确的废话连天（你把5个元素任意连接起来，换个位置都可以瞎忽悠）。前面说过了本书标榜的东西不过是一个希望自我推荐的架构分析方法，利用咨询来挣钱的东东，这倒也没有什么问题，我倒是认为，这个方法论作者费劲体力，绕来绕去，也没有把他最想意思清楚表达出来，一下说需求观要二维，一下说概念架构，一下说高层分层，一下又掰扯各种架构视图的关系，天知道作者想表达什么意思？我倒要劝劝作者你的方法再好，也要能用一句简单明了的话总结清楚了，所以我相信听“用例驱动设计”咨询的肯定比听ADMEMS这个明白。另外我想请问一下那些给这本书打5星的评价和那些所谓的专家推荐人士是否对这个本书是否还有一点点印象？大概没人能回忆出这本书的一点痕迹吧。因为虽然温先生讲的很多都是正确的东西，但都是废话，有谁牢记废话？而且我也劝一些兄台们，一本书如果你读不懂，有些时候不一定是你的错，不用装作读懂了给个高分。最后点题，此书绝对不是一线架构师的实践指南，它只是一个咨询师为了发财致富的絮絮叨叨。方法论的东西和一线有蛋关系，一线架构师要的能力是看到一个需求能把握问题的核心，找到要实现的特性，并且给出解决方案，不是看软件工程的书你就能成架构师。此书对于新手它的作用就是让你看到一些正确的废话，对于老手你看费力看废话干嘛？所以此书我完全不推荐阅读，除非你要上温老师的ADMEMS方法论的咨询课。

一线架构师

看了部分章节感觉很好！如果能看全书更好了！可惜只能看部分章节！不过已经感到收益颇丰！希望能尽快看到原书！

较差，写得内容过于虚

与某个具体技术平台一点关系都没有。什么叫一线。内容不对题。

还是有用的

朋友送我这本书三年多了，放了好长时间才看得。今天看了大家的评价，表达一下自己的看法：1、本书还是有指导意义的。方法论的东西好处就是，不明白的人学习了，就可以照着去做，较快达到一个可接受的水平。坦率地讲，国内程序员开始做架构真需要一本这样的书，否则也就像书里说的那些问题了。2、个人觉得架构这东西是紧紧绑着技术的，脱离技术本身，空谈架构，就太形而上了。如果架构师不精通产品/项目本身所用到的技术，就不可能设计出一个好架构，就真的成咨询了。我想这也是楼下fullsail观点那么激烈的原因了。3、没有多年产品/项目经验，深厚的技术基础，看本书也就是个方法论。如果能联系实际，举一反三，钻进技术架构深层，又从里面总结抽象出书里的类似观点、方法，才有大帮助。4、温老师当然经验丰富了，但经验这东西没法通过看书提升啊。所以，谈架构方法论的书，就是艺术多于科学，没法那么确定了。

来源于实践的方法体系去指导实践

年初的时候单位就买了几本，但没有一本到我手上，但因个人调整到不熟悉岗位，这个也就先放下了，这个假期因看温老师的软件架构设计，就一并读下来了软件架构设计师2007年出版的，一线是2010年出版的，前后大概3年的时间，从理论走到的实践书中的很多内容是不错的，包括我自己一直在学习RUP和OOAD，公司里面也有一套模板和方法，但使用用例技术，OOAD过程对项目进行开发，有几个过程：第一就是需求开发，需求开发包括需求捕获和需求分析。第二是系统分析；第三是系统设计，也就是概要设计，重点是架构设计；第四是详细设计和实现；这四个过程是我们目前在项目实施阶段的几个主要的过程，其中有几个难点，自己也一直在思考如何进行跨越，第一个难点是需求开发阶段，从需求捕获到开始需求分析，需求捕获的主要成果是需求调研报告，这个是非结构化的文档，而需求分析要求用结构化的UML来表达，即使用用例技术。从非结构化到结构化，从自然语言到UML，两个完全不同的表达方式，这可以说是第一个鸿沟。第二是从需求分析到系统设计，这个是从UML语言到机器语言，也是一个鸿沟。实际上，使用UML来完全的进行这个过程，还是由很多的局限性的，当然，这个温老师也在书中详细的叙说过了。关于第二个鸿沟，我想读完两本书，至少可以建立一个比较完整的理论体系，至于说实践，还是看自己的积累吧，不同产品的开发各有不同的特征，对架构设计的要求也不一样，但架构设计的重要性是不言而喻的。这本书最大的收获是让我能够跳出UML+OOAD的思考范围之外，其思考和解决问题，但同时，对健壮性图的认知，应该说作者谈的是比较多的，也是比较深入的，而健壮性图，正是解决第二个鸿沟的重要的技术手段。在书中的三个阶段中，PreA、CA和RA，对比我们自己的阶段划分，其实会发现，RA才是对应到我们自己的第三个阶段，而PreA和CA是穿插在第一、第二阶段的。因此，这是温老师不断强调架构师要懂得需求的重要的原因吧。另，关于书的校对，还是不够仔细，我在读的时候至少发现了不少于5处的错误，当然都是小错误，稍加推敲还是能明白错误在哪里的。UML+OOAD不是万能药，只是一种分析问题和解决问题的工具和方法体系。

不在其位不谋其政，的确是实践指南

看软件架构设计的时候正值青春少年期，大三大四对社会对人生充满希望的时刻，看软件架构设计宛如醍醐灌顶，实在是太有用了。时隔几年后依然是温老师的粉丝，出了新书肯定首先支持。到手后迫不及待翻阅，及时更新豆瓣在读状态，读完以后却没有更新读完。看不懂，在书中看到的更多是温老师在一个遥不可及的地方辛勤工作的心得，再反观自身，至少10年内也不可能有办法去“实践”温老师的理论，实在是在沉溺在遗憾中。看不懂。目前中国普通游戏行业暂时无法用上这些知识。看了也是飘飘然，懵懵懂懂的，感觉不如温老师的第一本书的帮助大。这是我读本书的看法，也是对我最大的触动。几年过去了，我是否是在退步呢？虽然没从本书中摄取到我想要的养分，但是本书对我带来的思考，却是永恒的。

值得一看

读完了，还行。比较有操作性，在进行架构设计的时候可以比较容易借鉴书中的一些方法。可以说是一本提纲挈领的架构指导书籍。

ADMEMS的3个阶段

软件需要分阶段和分视角进行架构设计，其中的3个阶段如下:ADMEMS方法有3个阶段1,PA：理解需求,建立需求大局表,确定架构设计方向.2,CA：概念架构关键:确定设计要素和交互机制,概念架构界定系统的高层组件,不关注接口3,RA：为开发提供足够的指导和限制多视角使用5视图方法进行多视角思维.同时利用场景-目标-决策表进行抉择.