《一线架构师实践指南》是一本实用的指南书籍，深入浅出地介绍了架构师的职责、技能和实践方法。通过案例分析和实际经验分享，帮助读者更好地理解架构设计的重要性和实施步骤。本书内容丰富，适合初学者和有经验的架构师参考。
一线架构师实践指南读后感(一)
软件需要分阶段和分视角进行架构设计，其中的3个阶段如下:
ADMEMS方法有3个阶段
1,PA：理解需求,建立需求大局表,确定架构设计方向.
2,CA：概念架构关键:确定设计要素和交互机制,概念架构界定系统的高层组件,不关注接口
3,RA：为开发提供足够的指导和限制
多视角使用5视图方法进行多视角思维.
同时利用场景-目标-决策表进行抉择.
1/7页一线架构师实践指南读后感(二)
一本好书，从软将开发的各个阶段对软件架构的工作进行了一次梳理，使得架构工作的边界更为清晰，架构工作的内容有章可循。
但从另外一个角度说，没有几年设计工作经验的程序员，建议还是不必读。因为架构的层次，又比设计要更抽象。敏捷开发的实践者，可以阅读本书作为对传统瀑布式开发的一个回顾。敏捷开发一般来说，不会在项目初期决策架构的问题。
最近做的都是无技术的管理工作，还是喜欢纯技术的东西。
2/7页一线架构师实践指南读后感(三)
看软件架构设计的时候正值青春少年期，大三大四对社会对人生充满希望的时刻，看软件架构设计宛如醍醐灌顶，实在是太有用了。时隔几年后依然是温老师的粉丝，出了新书肯定首先支持。
到手后迫不及待翻阅，及时更新豆瓣在读状态，读完以后却没有更新读完。看不懂，在书中看到的更多是温老师在一个遥不可及的地方辛勤工作的心得，再反观自身，至少10年内也不可能有办法去“实践”温老师的理论，实在是在沉溺在遗憾中。
看不懂。
目前中国普通游戏行业暂时无法用上这些知识。
看了也是飘飘然，懵懵懂懂的，感觉不如温老师的第一本书的帮助大。
这是我读本书的看法，也是对我最大的触动。几年过去了，我是否是在退步呢？虽然没从本书中摄取到我想要的养分，但是本书对我带来的思考，却是永恒的。
3/7页一线架构师实践指南读后感(四)
朋友送我这本书三年多了，放了好长时间才看得。今天看了大家的评价，表达一下自己的看法：
1、本书还是有指导意义的。方法论的东西好处就是，不明白的人学习了，就可以照着去做，较快达到一个可接受的水平。坦率地讲，国内程序员开始做架构真需要一本这样的书，否则也就像书里说的那些问题了。
2、个人觉得架构这东西是紧紧绑着技术的，脱离技术本身，空谈架构，就太形而上了。如果架构师不精通产品/项目本身所用到的技术，就不可能设计出一个好架构，就真的成咨询了。我想这也是楼下fullsail观点那么激烈的原因了。
3、没有多年产品/项目经验，深厚的技术基础，看本书也就是个方法论。如果能联系实际，举一反三，钻进技术架构深层，又从里面总结抽象出书里的类似观点、方法，才有大帮助。
4、温老师当然经验丰富了，但经验这东西没法通过看书提升啊。所以，谈架构方法论的书，就是艺术多于科学，没法那么确定了。
4/7页一线架构师实践指南读后感(五)
自己买来的技术书很少有能从头至尾读完的，但是这本算是例外，倒不是说书多好多好，主要是章节安排上感觉比较合理，每一章都不是太长，恰好能在不想继续看的时候看完一章，哈哈！
总体感觉还不错，适合刚刚接触架构的人，比如我这种二把刀（没有经过正儿八经的培训和高人指点，靠自学成才的），能够帮助梳理一个比较清晰的思路和一些最基本的架构原则。个人比较认同第二部分概念架构和第四部分非功能需求相关的观点，其他部分没有太大感觉。尤其是第15章数据架构部分，觉得比较烂，写的东西都是大路边上的，没啥干货！
很少写书评，这是第一次，这是个好习惯，以后可以偶尔为之！
5/7页一线架构师实践指南读后感(六)
整体感觉还不错，但可能部分内容可能会有更好的解。
对我有用的点
1. 架构设计应及早从这个功能，质量，限制三个角度开始思考，年轻的设计者往往很容易忽略后两者
2. 软件在进行模块划分时，分是手段，合才是目的。将不同的模块或组件通过"分"（拆分、分解）来实现具体的功能，然后通过"合"（组合、集成）来支持更高层次的功能。这种模块化和组合的方法有助于提高系统的可扩展性、可维护性和灵活性。它使得系统能够更容易地适应变化和演化，同时也简化了开发过程，提高了团队的协作效率。其实有点像从更高层次思考问题，低层次问题就变成手段/方法等，高层次问题是个更高维度的问题。
3. 架构师是在一堆需求中，问题中，做概念抽取的人，形成一个个独立的核心概念。需要把这些核心概念放在场景协作的上下文中去考虑.
4. 架构设计的过程是不断质疑驱动的过程
6/7页一线架构师实践指南读后感(七)
温昱先生的《一线架构师实践指南》在几乎所有的售书网站上都是一致推荐的一本书，当当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方法论的咨询课。
7/7页
