读《敏捷开发的26个总结》后，觉得有些习惯对我很有帮助，记录一下！
http://docman.iteye.com/blog/521878
用例一完全能够运行后再开发用例二。 厨房里有一种说法正好可以印证这个问题：“做好一盘菜后你再做下一盘”． 对于软件开发来说一个最大的问题就是人们喜欢并行开发多个任务。因为不可避免的，我们设计的功能中总会有一部分会被放弃砍掉，如果提前开发，很可能做无用 功。 一次只开发一个用例（或很少几个用例，这根据你的开发团队的大小而定）； 让这个用例功能完整； 让相应的测试用例都能通过； 相应的文稳都补齐； 只有在当前的用例完全开发完成后，才做为一个整体提交到版本库，才进行下一个用例。
不要在还没有任何使用案例的情况下设计通用模块。 只有在你知道有具体用例的情况下，你才可以实现一个具体的类，而且你在该类中只应该实现当前该用例需要的方法。 你也许会想到将来这个类会有其它的用途，你可以用注释的方式记录一下，但不要去实现它，只有在有了具体用例后你才可以实现它。
不断的了解如何改进系统。 这项工作没有尽头，你应该做好思想准备，持续不断的寻找可以改进的地方，收集各种关于如何找到质量问题、解决质量问题的案例。
审查，审查，审查。 敏捷开发可以帮助我们应对需求在将来的不确定，但过去的事情也存在不确定性。 测试工作永远不能停下来。 程序每次运行的表现都要被评审和记录。
先写测试用例，后写代码。 测试用例可以用来精确的说明我们的设计需求。 很多时候我们都是通过运行测试用例后发现我们的设计中存在问题。 想想吧，先写测试用例后编码能节省多少时间。 但是：写完测试用例1，然后编写用例1，完后才开始用例2。
清理垃圾代码。 很显然，又是一个尽人皆知的道理，但它也必须写入任何的开发原则里，因为它是如此的重要。 查找垃圾代码的工作永远没有尽头，找到它，消灭它。 要去除掉所有的不能给实际用户带来价值的代码。 如果你不能指出某段代码对用户有什么用处，那它很可能就是没用的。
培养对集成失败问题立即做出反应的习惯。 你要明白，当集成构建失败时，它会影响项目中的每一个人，所以没有比让核心程序能正确的集成和测试通过更重要的事情了。 我曾经见到过有的团队的集成构建中断几个月都不去管它，因为他们有其他的工作要做。 每个人都在忍受这种情况，但没人采取措施。 我们应该明白，应该广泛的认识到，只要做出一点点工作，整个的团队会因此得到非常大的回报。
团队的每个成员都要知道客户的需求。 大型复杂的项目必须要分割到几个独立的团队去开发，然后派发到每个开发人员的手中，但这绝对不能变成程序员可以不明白最终产品的使用用户的需求和目标是什么。
把意义相关的东西放在一起。 组织好代码，让高度相关的东西都放在一起，也就是放在一个类里。 这是标准的面向对象设计原则里的封装的概念。 理想情况下，类之外的程序并不需要知道类里面的工作细节。 有些开发人员喜欢把代码放到好几个文件里，这样是为了按另一种方式组织它们：例如把相同的数据类型的放到一起，或按字母顺序分类。 举个例子，有人会把所有的常量放在单独一个包下的一个类里，他们这样做毫无必要，增加了程序的复杂性。 按照指导原则，它们应该按照相关性进行分组，从而减少复杂性。
先测试后提交代码。 这个准则能让你确保“永远不要让集成构建失败”的准则。
删除死代码。 当发现有一大段不能理解的代码时我们习惯的做法是“让死狗躺在哪”。 比如说，我们需要往类里添加一个新方法来替换以前的旧方法，通用人们会保留老方法‘以防不测’。 其实，我们应该花一些功夫去检查看看这个老方法是否还有用，如果没有证据显示它还有用，就该删掉它。 更糟糕的错误做法是把这些代码注释掉，留下一堆注释码。 注释掉的代码一旦发现就该被删掉，不能留到测试时还有、甚至提交到代码库。 添加代码总是容易的，删除代码总是困难的。 因此，一旦发现有可能没用的代码，你应该花点时去确认它、删除它，这样会让代码更加可维护。
只有当准备好了实现和测试才去确定设计。 我应该有一个总体的认识我们要做什么，应该有个总体架构目标，而不是详细设计、详细的具体方法的实现，只有当开发迭代到一定程度后、足以让我们定下设计细 节后才去把它表现成文档。 详细设计只应该包括当前需求用例中需要覆盖的部分。 软件开发中最大的浪费就是你花时间设计出来东西后被告知不需要了，或者是你的设计一开始就建立在错误的假设上。
对被检测到的和被报告的异常情况请多花一点时间对其进行详细描述。 程序员一般都非常的懒，抛出异常时只描述错误的表面现象。 设想如果只是作者自己会遇到这种错误，他会记得这种一直使用的错误描述信息是什么意思。 但站在客服技术支持的处境，他们因为这种不准确的、不完整的错误描述浪费了大量时间。 这些信息应该达到让一个刚走进屋里没有任何经验的人能看明白的程度。 客户和客服基本都是对编程不懂的人。