《程序员必读之软件架构》经典读后感有感

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

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

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

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

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

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

然后，实在没什么意思。

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

《程序员必读之软件架构》读后感(二)：受众定位不清晰，核心观点不明确

我带着问题，想得到一些答案，所以才读了这本书。但书已经读了一半了，却发现全书的内容都是我想要问的问题，但没有回答任何一个答案。 再来，我们带着书本里面说的概念，在做一个架构的时候要思考受众是什么人。很明显作者没有认真地思考这个问题，对于初级一些的软件工程师，这本书给的知识点很混乱，无法帮助读者在软件架构的认知上搭建起该有的基本体系。而对于高级一些的程序员，读者本身对软件架构已经有了一些基础，一些思考，而这本书无法帮助他们整合内在已有的知识，更不用说在软件架构上让这类读者有更近一步的提升。总的来说，这本书没有核心的观点，也没能站在读者的角度讲好一个故事。 文中给了很多“启发性”的提问，还有各种指导清单。如果有资料收集癖，看到这些肯定会很开心。但如果试图想一下，作者为什么给出这些提问，为什么给出那些列举项，会找不到一个中心点。就好像，我拿到的不是一本课本，而是一本阅读题练习本。 原本想说这是一本软件架构导论，但看着看着，觉得这本顶多就是一本软件架构的杂谈。作者行文想到哪里就写哪里，知识点很散乱。对于每个知识点的讲解，也没能做出准确的描述，并且存在为了拓展篇幅硬是加入了很多不必要的描述的嫌疑。 原本是想打两颗星的，但看到这书居然还有6.8的评分，减少一星调整一下。

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

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

为什么没人拿架构做为一个明确的主题去讨论，可能的原因是：架构是关于抽象和经验。你说是好的实践，好的架构，最后的落脚点还是交付、性能、可用性上。如果一个的软件满足了这些，谁又会在意出发点和过程呢？你说未来有风险，互联项目快速迭代，开发换了一波又一波，谁又能做到持续负责？在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 的协作图/时序图，简直就是自欺欺人。