我收集各式各样的至理名言。近我一直在研究敏捷软件开发；有收获吗？下面是能够指导敏捷软件开发团队的26条核心原则。
　　用例一完全能够运行后再开发用例二。厨房里有一种说法正好可以印证这个问题：“做好一盘菜后你再做下一盘”． 对于软件开发来说一个大的问题是人们喜欢并行开发多个任务。因为不可避免的，我们设计的功能中总会有一部分会被放弃砍掉，如果提前开发，很可能做无用功。 一次只开发一个用例（或很少几个用例，这根据你的开发团队的大小而定）； 让这个用例功能完整； 让相应的测试用例都能通过； 相应的文稳都补齐； 只有在当前的用例完全开发完成后，才做为一个整体提交到版本库，才进行下一个用例。
　　避免提交一个半成品。这一点大家似乎都知道，但这条原则必须列入任何一个开发指导里。 能够听取这些忠告进行开发测试然后提交代码的程序员一定不会发生代码提交到版本库使整个项目无法编译码通过情况。 如果系统编译失败，那一定是有人抄近道到了。
　　不要在还没有任何使用案例的情况下设计通用模块。只有在你知道有具体用例的情况下，你才可以实现一个具体的类，而且你在该类中只应该实现当前该用例需要的方法。 你也许会想到将来这个类会有其它的用途，你可以用注释的方式记录一下，但不要去实现它，只有在有了具体用例后你才可以实现它。
　　一定不要在没有使用例的情况下往类里添加成员方法。这跟上面一条极其相似，除了这里针对的是数据成员。 开发人员很容易想到：一个‘客户记录’里应该有‘送货地址’的信息，但一定不要在没有任何用例要求这个属性的时候实现这个属性。
　　不要害怕做决定；不要害怕改变以前的决定。敏捷开发的目的是应对客户需求的不确定。 开发前期你不可能获到全部的信息。 你应该尽可能的拖延做决定的时间，但一旦到了你该做决定的时候，你应该当机立断，让项目向前推进。 你不能说一直等到有了足够的信息才做决定。 相反，你要依赖现有的信息作出正确们决定。 之后，当有新的信息出现后，不要害怕对以前的决定作出更改。 (老辈人有的称之为触发器，但我称之为随环境而变)
　　不断的了解如何改进系统。这项工作没有尽头，你应该做好思想准备，持续不断的寻找可以改进的地方，收集各种关于如何找到质量问题、解决质量问题的案例。
　　审查，审查，审查。敏捷开发可以帮助我们应对需求在将来的不确定，但过去的事情也存在不确定性。 测试工作永远不能停下来。 程序每次运行的表现都要被评审和记录。
　　软件的设计要以人为本，而不是系统。很多开发人员退而求其次、以技术为中心，让设计为技术服务。 永远不要忘记软件的目标是什么，是帮助人们完成工作。
　　测试是产品的一部分。许多开发人员和经理都认为产品是你打包给客户的东西，其余的都不重要。 其实测试也应该看作是产品的实际一部分，应该在设计时给予相当的重视，甚至，在很多时候，测试功能也应该同产品一起提交给客户。 （后面说的这部分很多人都不认可，一个内置的能自我测试软件包并不会占用多少额外的资源，但当你需要用到它时，你会发现它的巨大价值。)
　　先写测试用例，后写代码。测试用例可以用来精确的说明我们的设计需求。 很多时候我们都是通过运行测试用例后发现我们的设计中存在问题。 想想吧，先写测试用例后编码能节省多少时间。 但是：写完测试用例1，然后编写用例1，完后才开始用例2。
　　清理垃圾代码。很显然，又是一个尽人皆知的道理，但它也必须写入任何的开发原则里，因为它是如此的重要。 查找垃圾代码的工作永远没有尽头，找到它，消灭它。 要去除掉所有的不能给实际用户带来价值的代码。 如果你不能指出某段代码对用户有什么用处，那它很可能是没用的。
　　培养对集成失败问题立即做出反应的习惯。你要明白，当集成构建失败时，它会影响项目中的每一个人，所以没有比让核心程序能正确的集成和测试通过更重要的事情了。 我曾经见到过有的团队的集成构建中断几个月都不去管它，因为他们有其他的工作要做。 每个人都在忍受这种情况，但没人采取措施。 我们应该明白，应该广泛的认识到，只要做出一点点工作，整个的团队会因此得到非常大的回报。
　　团队的每个成员都要知道客户的需求。大型复杂的项目必须要分割到几个独立的团队去开发，然后派发到每个开发人员的手中，但这不能变成程序员可以不明白终产品的使用用户的需求和目标是什么。
　　把意义相关的东西放在一起。组织好代码，让高度相关的东西都放在一起，也是放在一个类里。 这是标准的面向对象设计原则里的封装的概念。 理想情况下，类之外的程序并不需要知道类里面的工作细节。 有些开发人员喜欢把代码放到好几个文件里，这样是为了按另一种方式组织它们：例如把相同的数据类型的放到一起，或按字母顺序分类。 举个例子，有人会把所有的常量放在单独一个包下的一个类里，他们这样做毫无必要，增加了程序的复杂性。 按照指导原则，它们应该按照相关性进行分组，从而减少复杂性。
　　先测试后提交代码。这个准则能让你确保“永远不要让集成构建失败”的准则。
　　过早优化是灾难之源 这句话是引用Don Knuth的，听起来一点不错。 在内核里的代码应该尽力的写好来避免不要的浪费，但针对高于单个方法的级别的优化应该在整个项目测试通过、针对终实际用户的压力测试用例通过之后才能进行。 仅仅根据静态的代码来判断哪些是影响整个性能主要的问题的论断往往是错误的。 相反，评审整个系统的运行表现，找出真正影响性能的1%的代码，只针对这些代码做优化。