思想未必是最新、最独特的，但一定是有用的！
正如该书“阅读指南“中所说，该书比较啰嗦。不过，老外有此风格的不是一个、两个，忍了。
全书的主题紧紧围绕”无绪“的概念进行，所谓”无绪“，就是指某些事情并不需要对背后的原理、规则有深刻的理解，就可以使用。典型的，不懂得汽车的原理，但我们照样开车，而且开得还不错。当今，软件开发世界中，更多的应用往往只是将不同的框架、组件进行集成，以满足自身的业务需求，而对这些被集成的”部件“并不一定需要深入了解其背后的细节、原理。这也导致了软件开发从严谨的结构化设计（一步步分解、整合设计出全新的系统）向如何更好的”集成与拼装“设计转化，也是敏捷开发得以盛行的基础，因为不需要从无到有的进行创造。当然也有不好的后果，更多的分不清需求和设计之间的界限，系统设计和详细设计之间的界限，也不想分清。
其实这本书，最吸引我的还是作者本身提供的很多自身案例，对我们自身的工作方式有很多启发，摘录一些分享：
知识传递的困难：
”想要将知识传授给其他人的时候，就会因为他们没有类似于我们的经验，也就很难说服他们接受我们的知识“
程序员的骄傲：
”P2 一年后，我证明了当时的这一猜测。因为Netbeans是一个开源项目，有一个API吸引了一个外部的开发人员。开始的时候，这位外部代码贡献者主要是做一些修复Bug的工作。随后，他开始单独负责一个子项目，并设计相关的API。原先负责设计这个API的人说他发现这个子项目的API变得越来越差，但他找不出原因，希望我帮一手。他说：非常不喜欢这些新的API，更不想把它们集成到他负责的项目中。但他也同样说不清楚这些新的API到底有什么问题。最后，他说这些新的API看起来和他原来的设想不一致。我曾经也对他说过类似的话。以我的标准来评价的话，他所编写的API与NetBeans的API的设想不一致！“
Java世界的”迷炫“：
P111 2001年，我们给JavaOne大会提交了一份名为“组件定位与协作”的议题，该议题中的内容与本章多少有些关系，我们认为该议题涉及的内容对于所有的模块化程序都很重要。然而，当时的JavaOne会议的组委会可能仅仅因为觉得这个议题的名称不够酷，或者可能因为他们觉得组件这个词用得太滥了，要知道“组件”这个词几乎包含了所有可以想象的内容，所以没有接受该议题。直到2006年，我和同事Tim Boudreau又提交了一份类似的议题，名为“模块化架构中那些发现注入和依赖注入的模式”。果然，如我们所料，议题被组委会接受了。这说明一定要找到能够贴近目标人群的术语才能打动他们。一旦听到“依赖注入”这个词，他们的心就被打动了。就像API这个词一样，恰当的名称有益交流。对于用户来说，他们越容易理解API这个词，就越容易接受API的相关内容。
留一条路给自己，扁鹊的大哥没那么好做：
开发人员抱怨的事项总是不断，如评审、编程规范，等等。但API监护人需要时刻保持警醒的状态，否则就可能因为一个小小的疏忽而引发问题。另一方面，不是出个小问题，至少说明了你所做的工作确实很有用。
整理：fasiondog
笔记思维导图下载地址：http://note.sdo.com/u/1517210336#/n/qrIHw~jy6hZFnM00401hmP