随笔分类 -  极限编程

摘要：关于重构，是一个相对复杂的话题，通常按照对一个问题的考虑思路是这样这样论述的：重构是什么？为什么要重构？怎么重构？有本书名字叫《重构——改善既有代码的设计》，专门论述重构，推荐大家去看。 阅读全文

摘要：持续整合：大量减少在整合中耗费的时间，减少团队开发问题。 用一个实例来讲述这一章吧，2002年的时候，我们的团队开始使用新的技术，并在我们自己设计的软件开发框架下工作，这套框架在设计上充分贯彻了J2EE的开发模式和MVC的设计模式。 MVC是Model、View、Control的缩写，我们做的业务类就是Model，JSP是View，而连接它们的就是各种事件响应的Servlet就是Control。n... 阅读全文

摘要：测试：一个功能存在的前提是有一个测试能够验证它，任何有被破坏的可能的代码就必须有一个对应的测试。 以前当硬件环境有限的时候，程序的编写非常讲究效率，对内存的使用都要精打细算。很快的，硬件环境极大的改善，开发工具越来越“傻瓜”，程序员们再也不用精打细算的过日子了，然而渐渐的，程序员的简洁意识也越来越薄弱，所以，内存泄露的问题越来越严重。 我印象非常深刻的就是以前听过一个同事讲过这样一件事情：他们做软... 阅读全文

摘要：简单设计：通过所有测试，没有重复和费解的逻辑代码，简单的设计能保证代码的简单。 每次在对用户需求的讨论时，最花时间的往往是一些特殊场景下的需求，这些功能需求往往仅占用了整个业务需求的20%，却花费了80%的时间去争论是否需求、如何实现。这就是著名的2/8原则。 开发人员往往是完美主义者，在开发的过程中精益求精，希望自己的软件一旦应用改动尽可能的少，于是程序的可扩展性成为... 阅读全文

摘要：小版本：用最少的代码工作量带来最大的业务价值。 这个原则是意思是为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。 这么一说，感觉这一原则对我们公司的产品是没有什么适用性的，我们不可能让运营商承受这样的高度迭代过程。然而，正如我一开始就提到的，我们学习敏捷开发、极限编程的目的... 阅读全文

摘要：计划的制定：包括客户选择的项目大小、程序功能的优先级、各个版本的合成和发布日期。 曾经听说过一个关于项目经理的笑话：接手一个项目，领导问项目需要多长时间，我们的项目经理拍拍脑袋说出一个时间节点。领导说这个任务很紧张啊，能不能快一点（再加上一些威逼利诱的话^%$#^%^$#^），项目经理继续拍拍脑袋说出一个时间节点……就这样一番讨价还价，终于领导满意了，临走关切的问没问题吧？项目经理拍拍胸脯说请领导... 阅读全文

摘要：解读极限编程的十二大原则 阅读全文