《简单之美》是一本由倪健著作，机械工业出版社出版的平装图书，本书定价：55.00元，页数：292，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《简单之美》精选点评：

　　●1.这是一次软件开发者的心灵沟通之旅 2.10大社区一致鼎力推荐 3.探索软件开发与管理的精髓与本质：简单、想象和文化 4.从思想出发，以实践为证，直奔问题的根源，挖掘简单的本质 5.与方法论无关，与具体技术无关，与软件开发的思想和哲学有关

　　●当初抱着想了解点实际软件开发过程从而看能不能找到点想法的动机借了这本书，后面就没仔细看了，走马观花了一番，感觉一般。虽然在中途就不想看了，可是由于自己有看书就要看完 不然总感觉不对劲的习惯，于是草草结案了，也许这是个坏习惯。因为似乎没有把时间花在更重要的事情上。

　　●制度方法流程固然重要，人是更重要的一环，相辅相成。战略对了，战术也要能执行到位。

　　●值得推荐，做一个善于思考的IT从业者！

　　●很值得一读。相信具有几年软件开发经验的人员去读会更有共鸣吧。

　　●里面的故事值得一读

　　●视角独特，有感而发，对很多软件从业人员眼中司空见惯的现象和问题进行了分析。特别是第六章关于测试的章节，张弛有度，节奏感十足！

　　●杀书头！

　　●启迪思维、引人深思

　　●风格稍微有点奇怪的一本书。包含了故事，大道理（并非贬义），意识形态，切身体验和一些一笔带过的思路技巧。作者对于项目管理的理解很深入。对于风险管理的理解很深入。

　　《简单之美》读后感(一)：力荐

　　这本书讲述了一个故事，这个故事涉及到软件工程的方方面面，作者把自己工作中的感悟和思想非常巧妙的融入到故事的各个情节场景中。通过这个故事反观当前个人所面临的迷茫、困惑、软件工作中的一些场景，给我带来很多启发。对书中部分章节能与作者表述的思想产生共鸣，更多的是学习作者对软件工程中各场景的深刻思考，在我翻豆瓣的时候很巧合的把它买下来，很幸运在我这个阶段能读到这本书。

　　《简单之美》读后感(二)：可以当小说看

　　褒：

　　作者编故事的能力还是不错的，看完目录、前言，我就先把每章开始的故事连起来读了一遍，不得不说，很有《圈子圈套》的意味，好好发挥下，超越之绝对不是问题，那么多憋闷、抑郁的coder，需要很多可以yy的故事的，至少，本人读完是很happy的，如同人家描述武侠故事，可以很好的满足中国大男人的某些心态的~

　　方法论、人的重要性及团队建设、项目管理相关论述，还是有些受益的。

　　---------------------------我也有分割线了~--------------------------

　　贬：

　　目录大结构还算清晰简单，但是每一章的正文，总是读的艰难，想为其画个思维导图，总是不得要领，全书立意有点太过庞大，书中不乏精辟之语，但总感到不成系统，你觉得说的都对，崇尚简单美的一本书，却让人有繁杂之感，遗憾。

　　这让我想起了高中时写作文的场景，或纠结于情绪的表达、或充斥着东拉西拽的名言和精辟小故事，本书似有此感。

　　更让人汗颜的是，本书66~67页中间撕掉了两页，多塞了两张也不撕的干净点！

　　《简单之美》读后感(三)：“软件开发方法论”章节评论

　　这本书绝不适合软件开发领域的新手阅读，它的内容是一名经验丰富开发者对软件开发中各个面向所进行的一个总结式思考，但它的内容跳跃过大，思维太发散，很难把握这本书的思想脉络。作为工作两三年的开发者，这本书的作用可开阔视野，指明方向，埋下思考的种子。

　　分别从1）软件开发方法论、2）需求，3）架构设计，4）软件实现，5）软件测试，6）团队，7）项目管理，8）软件维护，10）组织发展，这十个宏观层面简述了自己的经验和总结。而每一个方面，虽然文字不多，但信息量都比较大，读得出来作者是一位经验丰富、格局宽广的开发者和管理者。

　　## 软件开发方法论

　　Q：作者如何看待软件开发方法论，如何看待传统模式和敏捷开发？

　　A：每种方法论都有它适用的场景，但有些方法却是普遍适用的，可以称之为开发的原则。

　　Q：哪些原则是普遍适用的？

　　A：简单原则，用例的撰写就是一个明证：不需要修饰语，不需要副词，不需要语气词和助动词，有效地用例只保留主谓宾，没有任何干扰意思的表达。简单化是准确沟通的做好保证，越简单思路越清晰。而轻率的决策、非技术型妥协、无责任的参与，都可能打破“简单原则”。

　　Q：如何理解敏捷开发？

　　A：敏捷开发中的实践就像导演提供的剧本。在拍摄期间，导演总会要求你完成那些设计好的动作和台词，从而快速进入角色。敏捷开发中的“剧本”更加简单，它给人们留下巨大的发挥空间。于此同时，对人们的能力提出了较高的要求。

　　优点：1）更容易发挥主动性，2）开发效率更高

　　缺陷：1）对人的能力要求更高，更加依赖于人员素质

　　Q：CMM模式的优劣。

　　A：CMM通过制度和约束造就更好的工作习惯。

　　优点：1）对人员的素质要求并没有敏捷开发高。

　　缺点：1）在开始阶段，可能有更多人更不习惯这种方式。2）开始阶段，开发效率并没有敏捷开发高

　　Q：什么是最好的软件开发方法？

　　A：最好的软件开发方法，是最适合企业文化的开发方法。要学会兼容并蓄、博采众长，在目标和能力之间，找到一个平衡点，没有定法。对高手来说，现有情形下的所谓最好都是对“度”的把握。

　　但开发方法都有一个从启发或约束到习惯的过程。开发过程带来启发或约束，长期下来形成习惯，丰富的习惯促生文化、制造氛围，氛围产生最佳的执行效果。如果我们没有经历这个演变过程，那么就不可能从本质上提升执行力和开发效率。

　　Q：项目经理的工作时什么？

　　A：项目经理最重要的工作，应该是为软件开发提供服务。他是扫清路障的人、积极进言者、精神鼓舞者，是有责任、有追求的团队的培养者。而不是拿着时间表，冲开发人员发火的人。

　　《简单之美》读后感(四)：[转]《简单之美：软件开发实践者的思考》书评（精彩至极）

　　本书的内容有些另类，绝不似书名所呈现的中规中矩，但确实体现了一种美，是一种简单到极致的优雅，似乎又繁复如星空般的深邃，包容如峭立千仞之高的山壁。这是一本可以称之为轻松加愉快的思想随笔，又是一篇如杜拉拉升职记般的职场小说，它还贯穿了整个软件开发过程，揭露了从方法论、需求、架构设计、编码实现，到测试与维护以及团队管理的诸多要诀。这正是本书的另类之处。

　　我在阅读本书时，情不自禁地被放在书中每章篇首的实践场景所吸引，甚至忽略了本书的重要内容，直接根据提示转到下一个章节的实践场景，一气呵成，直到将这些实践场景阅读完毕。作者挥洒自如的文笔，入木三分的人物刻画，以及细腻含蓄的情感描写，将我彻底吸引住了。在大结局中，孔如之与儿子在阳光中巴黎圣母院前的对话，让人意犹未尽，似乎满怀希望，却又历尽沧桑，真是让我产生“情何以堪”的感慨。

　　这是本书感性的一面了。只是看完这9篇由实践场景片段组成的小说，就已经值回票价了。而从技术书籍的角度来看，本书的意义显然并不在于此，作者完整地勾勒出软件开发的全貌，诸多感悟与体会都可以成为软件开发人员的重要借鉴。作为本书理性的一面，这些内容需要反复阅读和分析琢磨，才能引起你的共鸣，许多模糊在心头的概念，在作者简明扼要的叙述下，或许就会产生“拨开云层见月明”的感悟。

　　以本书第4章为例。作者给出了一个简单的实例描述了框架构建的过程。首先从背景描述出发，展现了对保险业务中对保单进行处理的需求功能。这段背景描述将复杂的保险需求阐述得非常清楚而富有条理，体现了作者撰写文档的高超能力。

　　接下来是作者对这一背景描述的抽象。这段抽象有理有据，较好地体现了从需求捕获到分析的过程演变，利用抽象搭建了基本的领域模型。紧接着是对约束的思考，这是架构师必须完成的工作。根据对需求的抽象和关于约束的思考，就能够做出合理的架构决策。作者在本书中反复强调的“使用自然语言和讲故事的方式”，通过实例得到了具体的展现。事实上，在Joel on software一书中，Joel Spolsky也提出了同样的观点，认为通过讲故事的方式描述用例场景，可以更好地促进理解与交流。本书作者扩大了这种方式的应用范围，引入到架构设计过程中。对这一做法，我深表赞同。事实上，我在架构过程中，也常常采用类似手法，通过在文档撰写设计的故事场景，帮助我梳理设计思路，有时候，甚至在文档中自问自答，在这样的编写过程中我慢慢找到了解决方案。

　　本书对领域模型的讨论也有着个人独到的见解。例如他对静态模型和动态模型的分类，又例如他提出了使用贫血模型的好处。在Martin Fowler提出贫血模型之后，业界曾经掀起过对贫血模型与充血模型的争论。然而，争论到了最后，也没有一个确切的结果。从经典的OO原则来看，它要求将对象的数据和行为组织在一起，这正是批判贫血对象的主要论据。我比较倾向于这个观点，认为对象没有行为，就是“死”的，缺乏自治的能力。但在实际开发过程中，我也常常体会到贫血模型的好处，尤其是在模型重用与解耦方面，贫血模型都有其显著的优势。本书作者认为，贫血模型的“第一个好处是，有利于信息交换。第二个好处是，清晰了对象的职责。第三个好处是，实体对象（贫血对象）的实现更加灵活。第四个好处是，可以确保实体对象（贫血对象）只能在内存中用于计算。”这些好处都说到了点子上。虽然，我对于贫血对象的使用仍然抱有谨慎态度，但本书对此的阐述依旧给我提供了不错的参考。

　　在项目管理方面，书中强调了“负责制度”的实施。这首先关系到责任定位的问题。项目延迟或失败，究竟是项目管理的问题，还是架构设计的问题？是编码实现的问题，还是测试维护的问题？作者认为，负责制度的缺失可能会影响项目的质量。书中提到：“在软件开发过程中，人是最重要的因素，而责任、权利和利益是保证这个因素发挥作用的关键。”“建立负责制度的目的，不是为了惩罚某人，也不是为了永久取消某人的职业发展权利，它只是通过责任人利益损失的形式，来表明这样一个事实：没有金刚钻，别揽瓷器活。”事实上，负责制度的关键不在于制度的确立，而在于执行。如果没有创建公平、公开、公正的执行环境，这种制度只会给软件开发带来负面影响。这也是作者仅仅提出问题，却没有给出好的答案原因所在。相对而言，我个人更倾向于Scrum“回顾会议”，在基于迭代与渐进式开发的基础上，这种方式更能够有效解决项目开发中存在的问题。

　　倘若是新手阅读本书，由于缺乏足够的工作阅历与开发经验，很难理解作者写作的意图。但我们绝对不能因为这种认识上的障碍，而将本书拒之千里之外。事实上，越早阅读本书，越能够开拓读者的眼界，提前感受业界的真实与谎言，反而能够帮助新手更快地确立自己的职业生涯规划。对于混迹行业多年的老鸟而言，阅读本书，一定能找到那些似曾相识的画面。作者对技术的深入探讨，也一定能给予我们启发，即使观点不同，也可以求同存异。所谓“嘤其鸣矣，求其友声”，这是我在阅读本书时收获的如遇旧友般的快乐！

　　评论人：张逸

　　国内著名的软件架构师、敏捷导师、微软最有价值专家、MUSP培训专家张逸先生，著有《软件设计精要与模式》和翻译了《WCF服务编程》一书，在业界德高望重。