该命令的功能是将给出的文件或目录拷贝到另一文件或目录中，同MSDOS下的copy命令一样，功能十分强大。  

语法： cp [选项] 源文件或目录 目标文件或目录  

说明：该命令把指定的源文件复制到目标文件或把多个源文件复制到目标目录中。  

该命令的各选项含义如下：

- a 该选项通常在拷贝目录时使用。它保留链接、文件属性，并递归地拷贝目录，其作用等于dpR选项的组合。 

- d 拷贝时保留链接。  

- f 删除已经存在的目标文件而不提示。  

- i 和f选项相反，在覆盖目标文件之前将给出提示要求用户确认。回答y时目标文件将被覆盖，是交互式拷贝。  

- p 此时cp除复制源文件的内容外，还将把其修改时间和访问权限也复制到新文件中。  

- r 若给出的源文件是一目录文件，此时cp将递归复制该目录下所有的子目录和文件。此时目标文件必须为一个目录名。 

- l 不作拷贝，只是链接文件。  

需要说明的是，为防止用户在不经意的情况下用cp命令破坏另一个文件，如用户指定的目标文件名已存在，用cp命令拷贝文件后，这个文件就会被新源文件覆盖，因此，建议用户在使用cp命令拷贝文件时，最好使用i选项。

           java.util
        +Collection 这个接口extends自 --java.lang.Iterable接口
           +List 接口
              -ArrayList 类
              -LinkedList 类
              -Vector 类     此类是实现同步的

           +Queue 接口
              +不常用，在此不表.

           +Set 接口
              +SortedSet 接口
                 -TreeSet 类
              -HashSet

        +Map 接口
          -HashMap 类 (除了不同步和允许使用 null 键/值之外,与 Hashtable 大致相同.)
          -Hashtable 类 此类是实现同步的,不允许使用 null 键值
          +SortedMap 接口
             -TreeMap 类

          以下对众多接口和类的简单说明：首先不能不先说一下数组（Array）
       一、Array ， Arrays

Java所有“存储及随机访问一连串对象”的做法，array是最有效率的一种。

1、
效率高，但容量固定且无法动态改变。
array还有一个缺点是，无法判断其中实际存有多少元素，length只是告诉我们array的容量。

2、Java中有一个Arrays类，专门用来操作array。
       arrays中拥有一组static函数，
equals()：比较两个array是否相等。array拥有相同元素个数，且所有对应元素两两相等。
fill()：将值填入array中。
sort()：用来对array进行排序。
binarySearch()：在排好序的array中寻找元素。
System.arraycopy()：array的复制。

二、Collection ， Map

若撰写程序时不知道究竟需要多少对象，需要在空间不足时自动扩增容量，则需要使用容器类库，array不适用。

1、Collection 和 Map 的区别

容器内每个为之所存储的元素个数不同。
Collection类型者，每个位置只有一个元素。
Map类型者，持有 key-value pair，像个小型数据库。

2、Java2容器类类库的用途是“保存对象”，它分为两类，各自旗下的子类关系

Collection
       --List：将以特定次序存储元素。所以取出来的顺序可能和放入顺序不同。
             --ArrayList / LinkedList / Vector
       --Set ： 不能含有重复的元素
             --HashSet /TreeSet
Map
       --HashMap
    --HashTable
    --TreeMap

　Map----一组成对的“键值对”对象，即其元素是成对的对象，最典型的应用就是数据字典，并且还有其它广泛的应用。另外，Map可以返回其所有键组成的Set和其所有值组成的Collection，或其键值对组成的Set，并且还可以像数组一样扩展多维Map，只要让Map中键值对的每个“值”是一个Map即可。

　Collection下 1.迭代器

　　迭代器是一种设计模式，它是一个对象，它可以遍历并选择序列中的对象，而开发人员不需要了解该序列的底层结构。迭代器通常被称为“轻量级”对象，因为创建它的代价小。

　　Java中的Iterator功能比较简单，并且只能单向移动：

　　(1) 使用方法iterator()要求容器返回一个Iterator。第一次调用Iterator的next()方法时，它返回序列的第一个元素。注意：iterator()方法是java.lang.Iterable接口,被Collection继承。


　　(2) 使用next()获得序列中的下一个元素。

　　(3) 使用hasNext()检查序列中是否还有元素。

　　(4) 使用remove()将迭代器新返回的元素删除。

　　Iterator是Java迭代器最简单的实现，为List设计的ListIterator具有更多的功能，它可以从两个方向遍历List，也可以从List中插入和删除元素。

　　2.List的功能方法

　　List(interface): 次序是List最重要的特点；它确保维护元素特定的顺序。List为Collection添加了许多方法，使得能够向List中间插入与移除元素(只推荐LinkedList使用)。一个List可以生成ListIterator，使用它可以从两个方向遍历List，也可以从List中间插入和删除元素。

　　ArrayList: 由数组实现的List。它允许对元素进行快速随机访问，但是向List中间插入与移除元素的速度很慢。ListIterator只应该用来由后向前遍历ArrayList，而不是用来插入和删除元素，因为这比LinkedList开销要大很多。

　　LinkedList: 由列表实现的List。对顺序访问进行了优化，向List中间插入与删除得开销不大，随机访问则相对较慢(可用ArrayList代替)。它具有方法addFirst()、addLast()、getFirst()、getLast()、removeFirst()、removeLast()，这些方法(没有在任何接口或基类中定义过)使得LinkedList可以当作堆栈、队列和双向队列使用。

　　3.Set的功能方法

　　Set(interface): 存入Set的每个元素必须是唯一的，这也是与List不同的，因为Set不保存重复元素。加入Set的Object必须定义equals()方法以确保对象的唯一性。Set与Collection有完全一样的接口。Set接口不保证维护元素的次序。

　　HashSet: HashSet能快速定位一个元素，存入HashSet的对象必须定义hashCode()。

　　TreeSet: 保持次序的Set，底层为树结构。使用它可以从Set中提取有序的序列。

　　LinkedHashSet: 具有HashSet的查询速度，且内部使用链表维护元素的顺序(插入的次序)。于是在使用迭代器遍历Set时，结果会按元素插入的次序显示。

　　HashSet采用散列函数对元素进行排序，这是专门为快速查询而设计的；TreeSet采用红黑树的数据结构进行排序元素；LinkedHashSet内部使用散列以加快查询速度，同时使用链表维护元素的次序，使得看起来元素是以插入的顺序保存的。需要注意的是，生成自己的类时，Set需要维护元素的存储顺序，因此要实现Comparable接口并定义compareTo()方法。

3、其他特征

*     List，Set，Map将持有对象一律视为Object型别。
*     Collection、List、Set、Map都是接口，不能实例化。
      继承自它们的 ArrayList, Vector, HashTable, HashMap是具象class，这些才可被实例化。
*     vector容器确切知道它所持有的对象隶属什么型别。vector不进行边界检查。

三、Collections

Collections是针对集合类的一个帮助类。提供了一系列静态方法实现对各种集合的搜索、排序、线程完全化等操作。
相当于对Array进行类似操作的类——Arrays。
如，Collections.max(Collection coll); 取coll中最大的元素。
       Collections.sort(List list); 对list中元素排序

四、如何选择？

1、容器类和Array的区别、择取
      *     容器类仅能持有对象引用（指向对象的指针），而不是将对象信息copy一份至数列某位置。
      *     一旦将对象置入容器内，便损失了该对象的型别信息。

2、
     *     在各种Lists中，最好的做法是以ArrayList作为缺省选择。当插入、删除频繁时，使用LinkedList()；
        Vector总是比ArrayList慢，所以要尽量避免使用。
     *     在各种Sets中，HashSet通常优于HashTree（插入、查找）。只有当需要产生一个经过排序的序列，才用TreeSet。
        HashTree存在的唯一理由：能够维护其内元素的排序状态。
     *     在各种Maps中
        HashMap用于快速查找。
     *     当元素个数固定，用Array，因为Array效率是最高的。

结论：最常用的是ArrayList，HashSet，HashMap，Array。而且，我们也会发现一个规律，用TreeXXX都是排序的。

注意：

1、Collection没有get()方法来取得某个元素。只能通过iterator()遍历元素。
2、Set和Collection拥有一模一样的接口。
3、List，可以通过get()方法来一次取出一个元素。使用数字来选择一堆对象中的一个，get(0)...。(add/get)
4、一般使用ArrayList。用LinkedList构造堆栈stack、队列queue。

5、Map用 put(k,v) / get(k)，还可以使用containsKey()/containsValue()来检查其中是否含有某个key/value。
      HashMap会利用对象的hashCode来快速找到key。
    *     hashing
          哈希码就是将对象的信息经过一些转变形成一个独一无二的int值，这个值存储在一个array中。
          我们都知道所有存储结构中，array查找速度是最快的。所以，可以加速查找。
      
          发生碰撞时，让array指向多个values。即，数组每个位置上又生成一个梿表。

6、Map中元素，可以将key序列、value序列单独抽取出来。
使用keySet()抽取key序列，将map中的所有keys生成一个Set。
使用values()抽取value序列，将map中的所有values生成一个Collection。

为什么一个生成Set，一个生成Collection？那是因为，key总是独一无二的，value允许重复。

简单地说，一是准时；二是预算控制在既定的范围内；三是质量得到经理和用户们的赞许。项目经理必须保证项目小组的每一位成员都能对照上面三个标准来进行工作。

2、任何事都应当先规划再执行

就项目管理而言，很多专家和实践人员都同意这样一个观点：需要项目经理投入的最重要的一件事就是规划。只有详细而系统的由项目小组成员参与的规划才是项目成功的唯一基础。当现实的世界出现了一种不适于计划生存的环境时，项目经理应制定一个新的计划来反映环境的变化。规划、规划、再规划就是项目经理的一种生活方式。

3、项目经理必须以自己的实际行动向项目小组成员传递一种紧迫感

由于项目在时间、资源和经费上都是有限的，项目最终必须完成。但项目小组成员大多有自己的爱好，项目经理应让项目小组成员始终关注项目的目标和截止期限。例如，可以定期检查，可以召开例会，可以制作一些提醒的标志置于项目的场所。

4、成功的项目应使用一种可以度量且被证实的项目生命周期

标准的信息系统开发模型可以保证专业标准和成功的经验能够融入项目计划。这类模型不仅可以保证质量，还可以使重复劳动降到最低程度。因此，当遇到时间和预算压力需要削减项目时，项目经理应确定一种最佳的项目生命周期。

5、所有项目目标和项目活动必须生动形象地得以交流和沟通

项目经理和项目小组在项目开始时就应当形象化地描述项目的最终目标，以确保与项目有关的每一个人都能记住。项目成本的各个细节都应当清楚、明确、毫不含糊，并确保每个人对此都达成了一致的意见。

6、采用渐进的方式逐步实现目标

如果试图同时完成所有的项目目标，只会造成重复劳动，既浪费时间又浪费钱。俗话说，一口吃不成个胖子。项目目标只能一点一点地去实现，并且每实现一个目标就进行一次评估，确保整个项目能得以控制。

7、项目应得到明确的许可，并由投资方签字实施

在实现项目目标的过程中获得明确的许可是非常重要的。应将投资方的签字批准视为项目的一个出发点。道理很简单：任何有权拒绝或有权修改项目目标的人都应当在项目启动时审查和批准这些项目目标。

8、要想获得项目成功必须对项目目标进行透彻的分析

研究表明，如果按照众所周知记录在案的业务需求来设计项目的目标，则该项目多半会成功。所以，项目经理应当坚持这样一个原则，即在组织机构启动项目之前，就应当为该项目在业务需求中找到充分的依据。

9、项目经理应当责权对等

项目经理应当对项目的结果负责，这一点并不过分。但与此相对应，项目经理也应被授予足够的权利以承担相应的责任。在某些时候，权利显得特别重要，如获取或协调资源，要求得到有关的中小企业的配合，做相应的对项目成功有价值的决策等等。

10、项目投资方和用户应当主动介入，不能被动地坐享其成

多数项目投资方和用户都能正确地要求和行使批准（全部或部分）项目目标的权力。但伴随这个权力的是相应的责任——主动地介入项目的各个阶段。例如，在项目早期要帮助确定项目目标；在项目进行中，要对完成的阶段性目标进行评估，以确保项目能顺利进行。项目投资方应帮助项目经理去访问有关的中小企业和目标顾客的成员，并帮助项目经理获得必要的文件资料。

11、项目的实施应当采用市场运作机制

在多数情况下，项目经理应将自己看成是卖主，以督促自己完成投资方和用户交付的任务。项目计划一旦批准项目经理应当定期提醒项目小组成员该项目必须满足的业务需求是什么，以及该怎样工作才能满足这些业务需求。

12、项目经理应当获得项目小组成员的最佳人选

最佳人选是指受过相应的技能培训，有经验，素质高。对于项目来说，获得最佳人选往往能弥补时间、经费或其它方面的不足。项目经理应当为这些最佳的项目成员创造良好的工作环境，如帮助他们免受外部干扰，帮助他们获得必要的工具和条件以发挥他们的才能。

故事一

有两个软件项目（姑且称之为“项目 A”和“项目 B”），它们在开始时的预算都是 50 个人月，时间是 5 个月。

项目 A 在 5 个月后完工，耗费成本 50 人月
项目 B 在 6 个月后完工，耗费成本 70 人月
在软件圈子里摸爬滚打多年的读者们对这个故事一定有自己的判断——而且我可以大致猜出是什么样的判断。不过先别着急，我们还有另一个故事。

故事二

有两个软件项目（仍然姑且称之为“项目 A”和“项目 B”），它们在开始时的计划都是交付 200 项功能。

项目 A 在项目结束时一次性交付了最初计划的 200 项功能，但客户发现其中大约 30 项功能没有太大用处，而另外 30 项有用的功能要等到下一个项目才能实现。
项目 B 在第一个月结束时交付了第一个版本，此后每两周交付一个新的版本。在项目进行的过程中，客户进行了一次业务调整，加入了 90 项新的功能，并搁置了 50 项用处不大的功能。最终该项目交付了 240 项功能。
聪明的读者大概注意到了，前后两个故事讲的是同一回事，同样的两个项目。现在我的问题来了：请问哪个项目是更成功的项目？

这个问题并不容易回答——实际上它没有标准答案。站在很多软件企业的立场上，项目 A 是一个理想的成功项目：按时间、按成本完成预先约定的任务。请注意，我用了“理想的”这个词，稍后我还会解释这个有趣的词，因为实际上的软件项目往往没有那么理想。

而如果换一个角度，站在客户的立场上呢？也许付钱购买软件的客户会有一些不同的想法。项目 B 从开始之后一个月便交付了第一个可工作的版本，从那时起客户就开始使用这个软件的部分功能，并且不断地把自己使用的感受反馈给开发团队。在真实的业务运营过程中，客户甚至发现了一种新的盈利模式，并进行了一次大规模的业务调整，这次调整的结果也直观地体现在软件项目中。虽然项目B的整体交付速率低于项目 A，但它提供的所有功能都是客户真正需要的，它们为客户提供实实在在的价值——更不用说，客户提前好几个月就开始使用这个软件。

实际上，这是一篇关于软件价值的文章。和“成功项目”一样，对于“软件的价值”，不同的人也会有不同的定义。不过作为付钱购买软件的客户，他对于软件价值的定义是一目了然的：他能够从使用软件中创造多少价值，软件能够为他的业务提供多少价值，这就是软件的价值。或者说得更简明一点：

软件价值源自使用
这正是为什么很多客户青睐“项目 B”的原因——我并不打算声称所有客户都有同样的观点，稍后我也会举出反例，但至少支持这一观点的客户不在少数。因为他们处在一个残酷而快速变化的商业环境中：他们的供应商在变化，他们的客户在变化，他们所处的经济环境和政策环境也在变化。这一切的变化迫使他们的业务也要随之变化。更要命的是，今天这个经济全球化的时代是一个“快鱼吃慢鱼”的时代，客户迫切希望新的软件系统为他们带来竞争优势——哪怕这个软件系统尚未完成，只要能够投入使用。最后，客户对于新的软件系统究竟应该是什么样子并没有百分之百的把握，他们的想法往往要在真正使用软件之后才会浮现成型。几方面的因素加在一起，使得这些客户更愿意尽快开始使用软件、提出反馈、并不断完善软件，而不是提出一组需求、然后坐等几个月之后原封不动地拿到这些功能。

一个真实的案例

在 ThoughtWorks 的一个项目中，开发者们在项目开始之后一个月内就发布了第一个版本——只有一些简单的数据采集功能。在发布展示会上，发生了这样的对话……

开发者：这是我们的第一个功能。我们从文本文件、Excel 数据表和遗留数据库采集数据，现在我们的数据库中有这些数据……（展示数据库结构）
客户：唔……有意思。要是你能做这样一个查询（写出查询要求），得到的结果可能会有用。
开发者：可是我们的界面上没有地方做这样的查询操作。
客户：啊，我不需要操作界面，只要每天深夜做一次查询，把报表发到我的信箱就可以了。
开发者：这样吗……另一个问题是，这需要花我们几天时间。
客户：不要紧，把别的任务往后放几天好了，我很想看到这份报表。
开发者：那好吧，下周我们就会开始提供这个报表。
猜猜结果怎么样？一周之后客户就开始每天接收这份报表，并根据报表内容做一些分析和决策。仅仅几个月之后，这份报表给客户带来的收益就已经超过了整个项目的投资——这时项目其他部分的开发甚至还没有完成。

想想这个客户会怎么定义一个“成功的软件项目”？好吧，也许这个项目超过了预期的时间，也许投入了更多的人力，但这些并不意味着“项目失败”——只是付出更高的成本。关键在于，他投入的这些成本能够带来多大的收益，他的投资回报率是否划算。对于这个客户而言，如果项目能够随时给他提供可用的、能够创造最大价值的软件，能够随时让——就像故事中提到的——这种有价值的想法得以实现，这就是一个成功的项目。

所以，亲爱的读者，请你忘记本文标题上出现的“敏捷”二字，我们在这里所说的不是别的，就是一种为客户创造最大化价值的软件开发方法。这样的方法有很多种，但它们有一个共同的特点：尽快、尽可能频繁地交付可以工作的软件，让客户尽快开始使用软件，从使用中创造价值、厘清思路、提出反馈。仍然以 ThoughtWorks 的项目为例，这些项目通常在启动开发阶段之后一个月内就会发布第一个版本，随后每一周或每两周发布一个新版本——每个版本都是一个可以工作的软件，每个版本都比前一个版本具有更丰富的功能，并且每个版本都包含客户认为迄今为止最有价值的那些功能。用软件开发的“黑话”，“开发下一个版本”的过程叫做“迭代”，这些开发方法最大的共同点就是“迭代式开发”——不是一股脑地交付全部功能，而是每次增加一点、渐进地交付最有价值的功能。

软件开发的梦想与真实

回到文章开始处的两个故事。我曾经说过，对于很多软件企业而言，项目 A 是一个“理想的”成功项目。那么，是什么让情况变得不那么理想？

答案是一个所有软件开发者耳熟能详的词：需求变更。在真实的项目中，客户通常不会等到最后一天再照单全收整个项目，因为他知道自己的业务正在发生变化。这时需求变更就出现了，伴随着来回的扯皮和讨价还价。更糟的是，大量的需求变更发生在项目晚期——因为直到这时客户才真正看到、使用到这个软件，他的很多想法才真正浮现成型。随着这种“最后一分钟的需求变更”，项目超期、超出预算也就成了家常便饭。能够像项目A这样完工交付的，实在是凤毛麟角的幸运儿。

为了对付需求变更这个噩梦，软件开发者们还发明了另一个词：变更控制。这个有趣的词暗示着：需求变更是一种“不好”的东西，是需要“控制”的东西。然而站在客户的角度上想想，他在亲身使用了软件之后提出的要求，难道不是最有价值的东西吗？把这种真正创造业务价值的要求“控制”起来，难道是合理的吗？

在前面我也暗示过，并非所有的客户都一定青睐迭代式开发。那么，哪些软件项目不一定需要迭代式开发呢？从整篇文章的内容不难看出，如果客户的业务绝对不会变化，如果客户的需求巨细靡遗非常明确，如果客户不需要尽快开始使用软件以便收回成本，那么迭代式开发对他的帮助就会小得多。不过，如果读者认真思考的话，这样的例子也许并不多——也许比你最初认为的要少得多。一个很好的例子是“神州六号”火箭使用的计算机控制系统。还有多少这样的例子？读者不妨试着自己想想。

如果我足够幸运的话，也许一些读者已经被这篇文章吊起了胃口：既然有这么好的软件开发方法，既然它能够为我们创造更大的价值，那还等什么呢，我们马上就动手吧。事情不会那么简单。为了让迭代式开发能够成为现实，为了确保尽快、尽可能频繁地交付，为了确保每次交付的都是最有价值的功能，我们——包括软件开发者、软件企业和客户——需要很多的改变。这里既有职责与权利的划分，也有开发过程和团队的重组，还有技术层面的实践指导。这些正是敏捷方法学所涵盖的内容。缺少了这些东西，“为客户创造最大价值”就只能成为一句空话。在后续的文章里，我们将结合 ThoughtWorks 的实践经验，逐步介绍敏捷方法的方方面面。