《简单之美》书评

适用面广

本书应该适用于那些在实际工作中陷入迷惘或存在困惑的软件开发者、管理者和企业经营者。推荐！（来自互动）

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

本书的内容有些另类，绝不似书名所呈现的中规中矩，但确实体现了一种美，是一种简单到极致的优雅，似乎又繁复如星空般的深邃，包容如峭立千仞之高的山壁。这是一本可以称之为轻松加愉快的思想随笔，又是一篇如杜拉拉升职记般的职场小说，它还贯穿了整个软件开发过程，揭露了从方法论、需求、架构设计、编码实现，到测试与维护以及团队管理的诸多要诀。这正是本书的另类之处。我在阅读本书时，情不自禁地被放在书中每章篇首的实践场景所吸引，甚至忽略了本书的重要内容，直接根据提示转到下一个章节的实践场景，一气呵成，直到将这些实践场景阅读完毕。作者挥洒自如的文笔，入木三分的人物刻画，以及细腻含蓄的情感描写，将我彻底吸引住了。在大结局中，孔如之与儿子在阳光中巴黎圣母院前的对话，让人意犹未尽，似乎满怀希望，却又历尽沧桑，真是让我产生“情何以堪”的感慨。这是本书感性的一面了。只是看完这9篇由实践场景片段组成的小说，就已经值回票价了。而从技术书籍的角度来看，本书的意义显然并不在于此，作者完整地勾勒出软件开发的全貌，诸多感悟与体会都可以成为软件开发人员的重要借鉴。作为本书理性的一面，这些内容需要反复阅读和分析琢磨，才能引起你的共鸣，许多模糊在心头的概念，在作者简明扼要的叙述下，或许就会产生“拨开云层见月明”的感悟。以本书第4章为例。作者给出了一个简单的实例描述了框架构建的过程。首先从背景描述出发，展现了对保险业务中对保单进行处理的需求功能。这段背景描述将复杂的保险需求阐述得非常清楚而富有条理，体现了作者撰写文档的高超能力。接下来是作者对这一背景描述的抽象。这段抽象有理有据，较好地体现了从需求捕获到分析的过程演变，利用抽象搭建了基本的领域模型。紧接着是对约束的思考，这是架构师必须完成的工作。根据对需求的抽象和关于约束的思考，就能够做出合理的架构决策。作者在本书中反复强调的“使用自然语言和讲故事的方式”，通过实例得到了具体的展现。事实上，在Joel on software一书中，Joel Spolsky也提出了同样的观点，认为通过讲故事的方式描述用例场景，可以更好地促进理解与交流。本书作者扩大了这种方式的应用范围，引入到架构设计过程中。对这一做法，我深表赞同。事实上，我在架构过程中，也常常采用类似手法，通过在文档撰写设计的故事场景，帮助我梳理设计思路，有时候，甚至在文档中自问自答，在这样的编写过程中我慢慢找到了解决方案。本书对领域模型的讨论也有着个人独到的见解。例如他对静态模型和动态模型的分类，又例如他提出了使用贫血模型的好处。在Martin Fowler提出贫血模型之后，业界曾经掀起过对贫血模型与充血模型的争论。然而，争论到了最后，也没有一个确切的结果。从经典的OO原则来看，它要求将对象的数据和行为组织在一起，这正是批判贫血对象的主要论据。我比较倾向于这个观点，认为对象没有行为，就是“死”的，缺乏自治的能力。但在实际开发过程中，我也常常体会到贫血模型的好处，尤其是在模型重用与解耦方面，贫血模型都有其显著的优势。本书作者认为，贫血模型的“第一个好处是，有利于信息交换。第二个好处是，清晰了对象的职责。第三个好处是，实体对象（贫血对象）的实现更加灵活。第四个好处是，可以确保实体对象（贫血对象）只能在内存中用于计算。”这些好处都说到了点子上。虽然，我对于贫血对象的使用仍然抱有谨慎态度，但本书对此的阐述依旧给我提供了不错的参考。在项目管理方面，书中强调了“负责制度”的实施。这首先关系到责任定位的问题。项目延迟或失败，究竟是项目管理的问题，还是架构设计的问题？是编码实现的问题，还是测试维护的问题？作者认为，负责制度的缺失可能会影响项目的质量。书中提到：“在软件开发过程中，人是最重要的因素，而责任、权利和利益是保证这个因素发挥作用的关键。”“建立负责制度的目的，不是为了惩罚某人，也不是为了永久取消某人的职业发展权利，它只是通过责任人利益损失的形式，来表明这样一个事实：没有金刚钻，别揽瓷器活。”事实上，负责制度的关键不在于制度的确立，而在于执行。如果没有创建公平、公开、公正的执行环境，这种制度只会给软件开发带来负面影响。这也是作者仅仅提出问题，却没有给出好的答案原因所在。相对而言，我个人更倾向于Scrum“回顾会议”，在基于迭代与渐进式开发的基础上，这种方式更能够有效解决项目开发中存在的问题。倘若是新手阅读本书，由于缺乏足够的工作阅历与开发经验，很难理解作者写作的意图。但我们绝对不能因为这种认识上的障碍，而将本书拒之千里之外。事实上，越早阅读本书，越能够开拓读者的眼界，提前感受业界的真实与谎言，反而能够帮助新手更快地确立自己的职业生涯规划。对于混迹行业多年的老鸟而言，阅读本书，一定能找到那些似曾相识的画面。作者对技术的深入探讨，也一定能给予我们启发，即使观点不同，也可以求同存异。所谓“嘤其鸣矣，求其友声”，这是我在阅读本书时收获的如遇旧友般的快乐！本文转自著名网站InfoQ：http://www.infoq.com/cn/news/2011/04/beauty-of-simple评论人：张逸国内著名的软件架构师、敏捷导师、微软最有价值专家、MUSP培训专家张逸先生，著有《软件设计精要与模式》和翻译了《WCF服务编程》一书，在业界德高望重。关于本书的更多信息：http://tinyurl.com/68xwxfd

摆脱混乱状态

很多软件开发人员，在实践中经常处于一种混乱状态——出现问题的时候，没有人知道怎么做才算最好，或者大家缺乏足够的信任和共识，又或者不断地讨论却得不到满意的解决方案。这本书可以帮助我们摆脱混乱状态。（来自卓越）

内驱力为王

通过方法或手段来提高软件开发人员的主动性是错误的。从理想主义者的角度来看，软件开发人员和企业之间的关系是平等的，他们以一种契约的形式，相互服务于对方。一切都建立在“内驱力”之上！（来自当当）

非常不错

我看非常不错，不像有些人说的那么差劲。我比较认同第8.2节中的两个观点：“项目管理工作的基本思路不是控制，而是创造环境和顺势引导。”“把项目管理和软件开发工作清晰地分开，是一种最佳的实践。”这种总结应该和我一样来自教训吧...麻烦个别tx把书看完再发表意见哈，不要误导我们。（来自卓越）

技术性强，富含哲理，可读性超过《杜拉拉升职记》，强烈推荐！

用现在比较流行的话来说，本书中对软件开发和管理提出的一些观点都非常犀利，反映了作者的深入思考和深刻见解，很多朋友都非常赞同。尤为值得一提的是，作者为本书虚构的一个大型故事案例（分散在各章，寓意非常深刻）吸引了很多的读者朋友，可读性和趣味性比《杜拉拉升职记》还要好。关于本书，有个简单的讨论帖，感兴趣的朋友可以看看：http://www.javaeye.com/topic/659958

可以当小说看

褒：作者编故事的能力还是不错的，看完目录、前言，我就先把每章开始的故事连起来读了一遍，不得不说，很有《圈子圈套》的意味，好好发挥下，超越之绝对不是问题，那么多憋闷、抑郁的coder，需要很多可以yy的故事的，至少，本人读完是很happy的，如同人家描述武侠故事，可以很好的满足中国大男人的某些心态的~方法论、人的重要性及团队建设、项目管理相关论述，还是有些受益的。---------------------------我也有分割线了~--------------------------贬：目录大结构还算清晰简单，但是每一章的正文，总是读的艰难，想为其画个思维导图，总是不得要领，全书立意有点太过庞大，书中不乏精辟之语，但总感到不成系统，你觉得说的都对，崇尚简单美的一本书，却让人有繁杂之感，遗憾。这让我想起了高中时写作文的场景，或纠结于情绪的表达、或充斥着东拉西拽的名言和精辟小故事，本书似有此感。更让人汗颜的是，本书66~67页中间撕掉了两页，多塞了两张也不撕的干净点！