《程序员必读之软件架构》是一本由[英] Simon Brown著作，人民邮电出版社出版的平装图书，本书定价：49.00元，页数：228，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《程序员必读之软件架构》精选点评：

　　●不要把自己局限在写代码这件小事上。

　　●架构入门实践

　　●了解一下基础知识吧，一般般。

　　●c4还不错，其他只能呵呵了

　　●翻译的太差了。不是讲架构，更多的是讲软件开发的流程，工具，文档等，有参考价值！还是读英文原版！

　　●太多太杂，但是没有一个深入。而且没有看到任何有价值的思想，偶尔看看当做是要考虑的点吧。

　　●内容太水了，像一份提纲

　　●如果你在架构软件，要时常问自己：在时间，资源有限的情况下最有性价比的事情是什么；软件架构设计到经验和理论，目前还只能算手工艺，唯一能提高这方面的方法估计只有多读书多看最佳实践的博客和文章，然后自己在力所能及的工作中摸索。

　　●不错的一本书

　　●可能是因为书的前半部分过于说教 而这些说教也都是老生常谈，所以我个人认为这本书的价值主要集中在后半部分。C4工具还算新颖，可以在具体实践中应用。

　　《程序员必读之软件架构》读后感(一)：如何成为“架构师”

　　这本书的结构大概是这样的：

　　1. 架构师和程序员是不同的啊！架构师很厉害的啊！架构师也要写代码的啊！

　　2. 架构文档要这么写啊朋友！会了没有啊朋友！

　　3. 来来来，叔叔手把手教你写架构文档，好好学啊朋友！

　　然后，实在没什么意思。

　　所谓架构师，更多的应该算是成熟期的程序员，硬要搞一些名头出来实在无聊。

　　《程序员必读之软件架构》读后感(二)：确实需要3年经验基础才能看

1）技术场景介绍比较清楚，基本都配置了很典型的思考问题；

2）怎么做项目，应该从哪些方面思考，将项目做更好，该书提出了很多建设性思考；

3）例子具体的很具体，项目实战典型；

4）接近我司的研发体系，比较有实操性，方便对号入座；所以看完可以给小朋友们推荐一下；帮助理解我们公司内部的情况；

5）翻译的很不错； 译者文笔挺好的；

6）simon观点提法比较中庸，不会鼓吹或者一边倒；

　　《程序员必读之软件架构》读后感(三)：避而不谈的事也许是好事

　　团队里每个人都在做设计，做架构，但从来没人说过什么是架构，该如何架构，这应该是大部分团队的现状。

　　为什么没人拿架构做为一个明确的主题去讨论，可能的原因是：架构是关于抽象和经验。你说是好的实践，好的架构，最后的落脚点还是交付、性能、可用性上。如果一个的软件满足了这些，谁又会在意出发点和过程呢？你说未来有风险，互联项目快速迭代，开发换了一波又一波，谁又能做到持续负责？在KPI文化里，没法量化的东西是不被重视的。

　　架构师是稀有动物，经验最丰富，然而缺乏动力把经验理论化、系统化，教授给开发。普通开发者，听命而行，在仅有的一点自主设计上依葫芦画瓢。每个人根据自己的喜好来，再吸收别人的经验，久了团队形成了默认风格，没人能说得清为什么要这样做。这究竟是好是坏，也许并不重要，什么样的组织结构，就会产生什么样的软件架构——康威定律。

　　在我看来，本书的作用对个人的帮助大于团队。好的团队不需要改变，差的团队改变很难，与其从架构层面入手，不如严格执行KPI，淘汰不合格的人来的实在。个人的主要受益点，来自作者多年经验总结出的理论、方法论，自己工作几十年也不会有如此沉淀。有了这些方法论，可以切实解决实际的问题，比如如何画图，用草图而不是UML——这的确困惑了我很久。有了理论，嘿嘿，无论是建立领导力，还是说服他人，都吃这一套。

　　《程序员必读之软件架构》读后感(四)：软件架构的培训提纲

　　架构入门书，书大概是直接由PPT改过来的，薄薄两百页有68章，每章一到两页，仅仅介绍了什么是架构，架构包含什么内容，并没有讲怎么从需求分析得到软件架构这个最有技术含量的话题，大概书的目的就是说服程序员，架构很有必要，架构师也很有必要。另外书里提到不要去重新发明轮子，自己又提出个C4，要架构师自己去定义标记法，UML都定义好了，用就是了，不会用学就是了，这本书试图向那些不愿意学习UML的架构师程序员介绍一个简洁方法C4，其实，对于不爱学习不愿学习的人，介绍啥都是没用的，徒劳，还冠以程序员必读，实在是名不副实，要想在架构领域有所深入的话，还得看看专业领域的书，需求分析，领域建模，模式系统... 无论如何，开卷有益，读完还是有几点留下深刻印象：1）、Boyd loop-OODA -Observe-Orient-Decide-Action，2）、风险驱动架构， Head first OOAD 提出了用3Q来找出risk，比这本只提一个概念强，3）架构驱动力（由什么来驱动）功能需求，非功能需求（performance,scalability, usability(error handler,error recovery),, security, expandability, constrain, principle ，只介绍了个概念，考虑架构时要把这些要素考虑进去，但这些元素怎么变成架构的过程/方法没有提及 4）C4， context - container - component - class, 对应UML system use case diagram - deployment view, package diagram, class diagram, 重新发明轮子典型例子，C4没有动态交互，交互还得借助UML 的协作图/时序图，简直就是自欺欺人。