《恰如其分的软件架构》读后感精选

《恰如其分的软件架构》是一本由George Fairbanks著作，华中科技大学出版社出版的平装图书，本书定价：88.00，页数：376，特精心收集的读后感，希望对大家能有帮助。

《恰如其分的软件架构》读后感(一)：只有后半部分的几个章节值得读一下

这本书真的是大失所望，全是值得读一读的章节也就只有13，14，15章节可以读一读。这几章归纳总结了常见的几种架构模型。至于其它内容，绝大多数时候都在做名词解释，术语解释，无聊透顶。虽然开篇讲了风险驱动的架构方式的优点，和如何实施操作。但是，如何实施，如何识别风险讲得太笼统了，读者最多能有所了解，建立起一点点概念而已。好的架构书籍真的很难找啊....

《恰如其分的软件架构》读后感(二)：内容太泛，缺乏有价值的内容

太泛，罗列了一大堆东西都没什么价值，几乎没有值得细读地方。

个人观点：唯一可以品位一下的就是“Just Enough Software Architecture”书名的这几个字。作为一个优秀的架构师，必须具备出色的抽象和总结能力，在这个基础上，自然应该能够理清楚架构的重点和轻重缓急，在这个前提下进行的架构，一定程度上就是采用了风险驱动的方式，但又不是照本宣科、僵化的采用。

《恰如其分的软件架构》读后感(三)：回答了为啥工程师和项目经理总是对优先级有不同理解的问题

原文: http://liguanglei.name/blogs/2014/05/31/just-enough-software-architecture/

本书算是个总结整理, 没看出提出了什么新的观点和方法 本书倒是明确了几个词汇, 丰富了设计时可用与思考和交流的语言, 回答了为啥工程师和项目经理总是对优先级有不同理解的问题

《恰如其分的软件架构》读后感(四)：统揽全局，翻译专业

前几天，朋友送了一本书给我《恰如其分的软件架构》，一看副标题，“风险驱动的设计方法”，嗯？“风险”，这是我最想了解的，最近遭遇太多太多风险了，做梦都在想怎么化解各种风险。

想想现在的架构工作，我们总会发现这样一个情景：架构师总是在系统投产上线后，进行项目总结时才发觉现行的架构与最初相差甚远，甚至是大相径庭，但是细想一下，每一个改动都是有理有据的，都有存在的理由。然而，这个结果，投产后的架构，却不是我们希望看到的，它是一个妥协的产物，——期望的架构已经远离了我们。

在商界有种说法，“CEO是公司里最后一个知道公司要破产的人”，在技术领域，是不是可以说“架构师是团队中最有一个知道架构即将被推翻的人”？哎，可能还真是。

想一下我们的架构是从何而来的。很简单，是从头脑中投射出来的，简单的说，就是知识+经验的产物，经过多日的熬夜奋战，终于，一份叫做“架构设计说明书”的文档诞生了。在这个过程中，我们付出了艰辛的劳动，考虑了诸多的特殊和异常场景，建立了丰富的模型，制定了详细的数据流程，想当然的认为它能够适应领域内的大部分场景，但通常情况下，我们是错的。

于是，我决定看看这本“风险驱动设计”，看看如何从风险的角度构架我们的系统，看后收益匪浅。这本书对架构建模进行了深层次的分析，提出抽象规模和复杂度、分析系统质量、忽略细节等等技法，感觉完全可以套用，以前做架构模型没思考这么深。

这本书还提到了架构风格，这是我比较欣赏的，架构风格是“元素和约束组成的语言”，其可以预制约束集、统一理解、减少沟通损耗、设计重用、保证质量等等优势，还介绍了柏拉图式风格、分层风格、大泥球风格等，甚是受用。

估计这本书在国内流行不起来，原因是大家都在忙着写代码，毕竟在世人眼里中Coder才是代表IT技术的。但是如果你的目标不仅仅是写代码，而是想统揽全局，向架构师方向发展的话，建议你读读这本书。还有，这本书翻译的非常专业，没有丝毫机器翻译的味道，而且作者对技术的理解也非常到位，整体看下来就是一气呵成，通顺流畅，值得推荐。

秦小波

《恰如其分的软件架构》读后感(五)：回顾我对这本书的翻译

华中科技大学出版社的徐定翔问我意见，了解我对Just Enough Software Architecture这本书的观感，看是否值得引进。时间是在2010年。从一开始，我就被书名中的Just Enough理念所吸引。它让我想起宋玉的东家姑娘，“增之一分则太长，减之一分则太短”那种不可言说的美丽。我在心里说，架构设计就需要这样。我当时并没有看到本书，只是到Amazon上找到了几篇英文原版样章。犹记得我在读到第一章介绍的RackSpace案例时那种兴奋之情。于是，我迫切地向徐定翔强烈推荐引进这本书，而我则毛遂自荐，希望能作为本书的译者。之后，我在InfoQ上看到对本书的《访谈和书摘》，进一步加强了我翻译本书的信念。于是，出版社开始与作者Fairbanks联系，然而从此音讯如石沉大海。时针指向2011年，我对于本书是否被引进，是否由我翻译，一切未知。我觉得我可能错过了它，思之仍觉怅然。谁知到了九月，消息突然确定，而徐大编辑就不容分说地直接把原书给我寄来了。

拿到沉甸甸的书，第一面就为本书的装帧而惊喜。心里想，我这一辈子若能写出这样一本书，绝对值得生命走过的这一遭了。我并没有迫不及待地开始翻译，这就好似遇到珍馐美味，需得先赏其色，闻其香，然后再品其味。我每天抱着这本书饶有兴味地开始阅读之旅。阅读之旅确乎如行山阴道，沿途之美，目不暇接；可一想到翻译，这种美景就成了一种折磨，因为我害怕辜负这一美景。翻译之初我就举步维艰，那些词语放在那里，我却无法解开“封印”将它们取出来，即使取出来，却又找不到存放的合适位置。一些翻译隐隐约约浮现着，当我竭力去揭开这些词语的真面目时，无论如何用力，总也不能够着。翻译就好像那些年我们一起追过的女孩——追不到，痛苦；追到了，销魂。翻译进度像蜗牛一样的爬着，我终于决定求助了。辗转寻找了好多朋友，都以各种理由拒绝或者放弃了。翻译讲解软件架构的书，确乎不是一件轻松的事儿。那个时候，我的Buddy肖鹏正从翻译《面向模式的软件架构》第五卷的泥潭中爬了出来。每一提及他的这段翻译经历，脸上就会浮现出不堪回首的表情，如看了恐怖片。终于，事情得到转机，最开始是倪健的雪中送炭，再有高翌翔的锦上添花，随着我们这个三人组的建立，翻译才算开始走向正规，我才有了交稿的信心。

自从开始翻译这本书后，我与人谈架构，动辄就会提及“Just Enough，恰如其分”。我像祥林嫂一般地推介着Fairbanks提出的风险驱动模型，并认真地实践着这一模型。我开始对演进的架构有了更深入的理解。我写了《设计恰如其分的架构》这篇博客来详细阐述我对演进式架构的理解。在2011年我参加的技术会议上，我也反复讲解了如何遵循简单之美的原则，运用风险驱动模型设计恰如其分的架构。2012年，在我参加的一个项目中需要针对遗留系统进行技术栈迁移。我撰写了文章《遗留系统的技术栈迁移》，提到了“风险驱动模型”，并在2013年的Scrum Gathering会议上分享了我的一些想法。当然，这个模型并不是锤子，更不是银弹。它更近似于质量属性驱动的架构设计，我们要满足的质量属性，可能就是我们在做架构时需要面对的风险；而在Roy Fielding的那篇关于REST的著名论文中，也提到了对约束的识别，并演示了如何从一个空约束，通过逐步添加约束演化为REST风格的架构。从某种程度上，架构的约束可能是一种风险，也可能成为设计的驱动力。

前几天，我参加Agile China 2013，与我新认识的一位朋友范钢聊到了关于架构重构的问题。事实上，面向对象软件开发到现在，已有十余年之久；各种经验、模式与原则甚嚣尘上并得到较好的推广。然而新的方法、新的语言乃至新的思想仍然层出不穷，尤其是在互联网开发、大数据处理以及移动开发的冲击下，传统软件开发似乎已经开始走向末路。“只见新人笑，不见旧人哭”！？？是，也不是。实际上，在传统的企业开发领域，各种大型系统仍然像一艘庞大如巨型海兽一般的船舰在海面缓缓行驶，它或许就是沉没之前的泰坦尼克，一切还都安然无恙，你甚至可以听到船头甲板传来的悠扬的小提琴声；然而，冰川就在远处出没，船长还未察觉。我们该怎么办？这样的巨型船舰，自然不可能如艨艟快艇那般的敏捷，即使是360度的转身，也可以玩得如此漂亮、优雅。这些大型的企业级软件系统已经走过了漫长的历程，它们如此巨大以至于我们只能看到它的一角，它们的零部件如此复杂以至于没有人能够彻底弄懂。我们必须认识到，这些系统是最有权力的系统，它们很有可能掌握了人类生活的根本命脉——金融管理、股市交易、生命健康、医疗管理、机械制造、国防安全、航空、航天……它们就像政治界、金融界的那些巨头，要是患了病咳嗽两声，也许世界都要抖一抖。它们可以轻易改变吗？不能！然而若是不寻求改变，这些系统会宿命地走向衰亡。若我们无法承受重写的成本，唯一的办法或许就是架构的重构。我们必须清晰地认识到这一点。而我认为，风险驱动模型恰恰可以作为架构重构的指导原则。在进行重构之前，我们需要充分评估重构的价值，回答“为什么我们需要重构”的问题；然后去识别风险。在开始重构之前，我们需要尽可能做到万无一失。风险自然是不可避免的，但如果我们能事先识别出这些风险，就能有的放矢地选择正确的技术。风险驱动模型的第三步，则是评估风险是否得到有效缓解。不要轻视这一步！重构往往意味着还债。可是，我们该用什么来说服管理者们付出成本去做一些看似没有产生直接利益的任务呢？答案就是用数据来说话，通过比较重构前后的系统健康指标，可以加重说服老板的砝码。当然，毫无疑问，这个过程一定是迭代的。

我想，通过这次交谈，我进一步找到了“风险驱动模型”适用的场景。而这正是我翻译并推荐本书的根本意义。本书可以在当当网购买。