样例：
查找文件名以a或b开头的，可执行文件，并调用ls命令显示其详细信息
find . -name '[a-b]*' -perm 755 -exec ls -l {} \;
查找更改时间为5天内的文件
find . -mtime -5
列出所有的目录名
find . -type d

xargs可以使用户对所匹配到的文件执行几乎所有的命令，而不会受到命令长度的限制。如：
find . -name '*.txt' -type f|xargs grep "ttt"
搜索所有txt文件，并找出这些文档中存在ttt字串的文件。

“研究的动机本身就会影响结果。”（page 14）

书中在第17页到20页对J2EE中使用代码生成技术的种种理由及其解决办法做了详细的分析，我也对此谈谈自己的体会。

◎根据RDBMS schema生成持久对象类

Entity Bean的解耦能力的确令人不敢恭维，我在开发一个项目的时候一般都采用Hibernate ，且一般自己写“*.hbm”配置文件，从不用工具生成，但是我会利用hbm2DDL和hbm2Java工具来生成相应的RDBMS schema和持久对象类。

对于XDoclet工具，其实是个不错的工具，只是使用起来麻烦了一些（我本人比较懒）。

其实对于RDBMS的性能没有做过太多的考虑，因为一直以来做的项目不是很大，数据库的逻辑结构也很简单，所以性能的问题几乎不用考虑。

书中提到“自动生成的持久对象不会包含任何行为，如果手工向其中添加行为，又可能给再次执行代码生成带来麻烦。一个没有行为的‘对象’是典型的反OO设计，我们很快将再次讨论这个问题。”（page 17）我且看作者将会怎么解释这个问题？

◎根据持久对象类生成DDL

◎生成DAO代码

◎生成EJB部署描述符

◎为领域对象生成“将对象映射成XML”的代码

◎生成用于访问EJB的类

◎生成一整套J2EE代码，从JSP直到entity bean（或是别的持久对象）

在此条的附注中，作者提到了Intranet数据库管理工具，这样的工具到是不少，可是我在想真的能通过IE来管理网络数据库的工具太少了，好像PHP在这方面做得还算好。

◎生成千篇一律的重复代码，例如“管理脏数据标记”

在此复习一下“脏读”和“脏数据”。脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是脏数据，依据脏数据所做的操作可能是不正确的。

这本书主要是在谈架构，而且限定在J2EE平台上的架构。自然就不跟微软的.Net等架构作比较，但偶尔也会借鉴其思想之精华。书中对自主开发框架也提出了自己的看法，进行了大篇幅的阐述，总的来看是十分有道理的，但是在很多实际的项目中，我还是经常自己写一些简单的基础设施，当然这些基础设施能够让我的团队很快理解并容易使用。

书中对于开发过程和开发工具没有作过多的讨论。

“除非别无选择，否则不要容忍‘伪对象’的存在。”（page 27）

“在避免非OO的做法的同时，我们还应该尽量实践OO的原则。” （page 27）

对于OO的讨论，书中有前面的章节中确实花了不少的篇幅，还记得当初我去一家公司面试的时候，考官居然还在问我一个问题：“C跟Java有什么区别？”

　　
　　对于

好了，开始言归正传，真正开始谈谈一些我自己的肤浅观点（甚至是错误的观点）。

书中谈到“ J2EE 应用项目至少和从前的非 J2EE 项目一样容易失败――如果不是更容易失败的话”（ page 4 ），我认为一个项目的失败与该项目采用何种框架和技术有太大的关系，在这个时代，对于架构和技术的选择有很多，而更关键的因素可能得从软件项目管理方面来衡量，从所周知，一个项目采用何种架构和细节性的技术只是项目管理的一个小部分。“而在 J2EE 遭遇失败的场景中， EJB 通常都扮演着重要的角色”（ page 4 ），这样说似乎也显得很牵强。

书中再次强调“最成功的标准都是从实践中发展出来的” (page 5) ，最显著的例子莫过于 OSI 和 TCP/IP 之间的关系。

本书的主旋律主要包括以下部分：

1 、简单

我常常在工作中就把一些问题看得较复杂，因为总觉得这不是一件坏事，考虑到一个问题的复杂性并认真想清楚此问题的各个方面，在解决这个问题的时候相对来说就会简单一些，但是这样也确实会带来诸多问题，如软件成本的核算，我就曾因此在一个客户需求并不高的情况下把问题复杂化了，导致了那个方案的失败。上次我就是犯了“提前叫客户掏钱购买的复杂架构”（ page 6 ）这样的错误。“这种想法有两个问题：首先，是否让系统变得如此复杂不应该由作为架构师和开发者的我们来决定，因为买单的人不是我们；其次，即便系统最终变得如此复杂，我们又怎么知道一开始将它们考虑进来就能节约成本呢？说不定，等到有需求的时候再修改架构还会更节约呢。”（ page 6 ）

书中主要从技术层面上讨论了这个问题，如数据库的分布，多种客户端等。对于问题的解决我们应该更切合实际一点，不要沉溺于一些不切实际的想象。

“XP 的核心教义之一就是：很多时候，越是节约成本，就越能开发出高质量的软件；不要试图预先解决所有能想到的问题。 ” （ page 6 ）

“使 J2EE 项目具备架构重构能力的关键在于：遵循良好的 OO 设计法则， 并且始终针对接口编程、而非针对类编程；将EJB之类的技术隐藏在普通Java对象背后。 ”（ page 7 ）

2 、生产率

虽然我没有真正的用 EJB 来开发过任何项目，但根据我对 EJB 的了解来看， EJB 在生产效率方面确实存在着很大的问题。

3 、 OO

以前我在设计一个对象的时候，根本没有认真的考虑过某一个对象是否真正的合理，这个需要在以后的设计中得以重视。

4 、需求至上

“ J2EE 的开发者们仅仅因为他们的技术选择――而不是客户的需求――就耗费了更多的精力。” (page 8)

5 、经验过程

经验对于一个软件开发者来说是极其重要的，很多问题只有你在具体的实施过程中才会发生，但是我从不拿一个人参加工作的时间长短来衡量一个人的经验是否丰富。

书中提到的循证医学（ EBM ）到是一件很有意思的事情，我觉得值得我们中国的医生好好的学习和思考一下（题外话）。

6 、可测试性

对于软件测试，我其实并没有深入的认识，我一直都处在开发的前沿，没有更多的机会和时间来深入研究测试，其实软件测试是一门很值得研究的学问。就拿腾讯的程序来说，其出错的机率远远高于其它软件，这是人的共知的，我想这也是腾讯所需要重视的。

关于轻量级框架和容器，我一直在关注 Spring 、 PicoContainer 和 Nanning 等。

书中讲到的“帕累托法则（ 80/20 法则，或 90/10 法则）”的确可以作为我们在项目实施过程中考虑该如何解决问题的一个衡量标准。即“花比较少的力气就可以解决大部分的问题，而要解决剩下的少部分问题则需要多得多的努力。”（ page 11 ）这教会了我们如何在项目中做适当的取舍（包括软件架构的取舍和需求的取舍，当然很多时候需求是不能改变的）。

EJB 在那些真正需要对象的分布应用方面仍是上佳之选，同时在需要大量使用异步消息的应用中，也是不错的选择，同时， EJB 在金融中间件的应用中，也能为项目提供价值。

本书所推行的思想就是， EJB 并不是要被我们完全抛弃，只是在一些没有必要使用 EJB 的项目中，我们可以如何找到更好，更简单，更具生产率的替代方案。

同时需要澄清的一个误解是： EJB 一直被视为 J2EE 平台的核心。这种观点把 EJB 的地位看得太重了一些。

书中说“还有强大的政治因素（而非技术因素）促使人们使用 EJB ”（ page 12 ），对于此句中的“政治因素”不知所指。是说的来自 Java 官方（即 SUN ）的因素吗？