下面是小编收集整理的解读极限编程的12大原则 6：重构（共含7篇），供大家参考借鉴，希望可以帮助到有需要的朋友。同时，但愿您也能像本文投稿人“哼哼啾啾咕”一样，积极向本站投稿分享好文章。
系列文章目录索引：《解读极限编程的12大原则》
重构：确保加入新功能后代码仍保持简单，从而保证简单的代码仍然能够运行所有的测试，
作为新员工，入职后的很长一段时间都是在阅读“前辈”们的设计文档和程序代码，在维护以前的项目。这原本是最快捷的学习过程，然而不幸的是我们常常看到的是与实物不一致的设计文档和纷乱、繁杂的代码。代码中的变量常常不知所谓，定义的变量、方法不知道在哪里调用，不知道什么作用。偶尔看到的注释却发现除了里面除了注释是谁增加的，却不知道对应的是哪些修改的代码……越看越糊涂，怎么办？干脆自己重新写一个吧！
我在处理入库的代码时询问提交人某个目录里面的代码有什么用时，得到的答案却往往是“不知道”。生命周期越长的程序，里面的目录和文件越是繁杂，从名称上很难看出文件之间是什么关系，类似以test这样的无意义的名称命名的文件随处可见。
关于重构，是一个相对复杂的话题，通常按照对一个问题的考虑思路是这样这样论述的：重构是什么？为什么要重构？怎么重构？
有本书名字叫《重构——改善既有代码的设计》，专门论述重构，我想自己再怎么写也不可能好过它了，所以推荐大家去看书吧。下面还是为大家说一下当年我们软件开发团队中的一些做法（和测试原则一样，在没有接触到敏捷开发之前我们就已经有意识的在某些方面做一些改进了）：定期进行代码检查，增强代码的复用性
代码复用性的提高势必会加快整个软件开发速度，而代码复用性的提高对开发效率有着最大的积极影响，但是它也能产生最大的消极影响。重复使用的积极影响和消极影响的关键差别可以只用一个词概括，那就是“质量”。如果重复使用的程序达到零缺陷，那么重复使用会产生积极影响。如果重复使用的程序充满了缺陷和错误，那么开发效率会大大降低。我们现在的开发很大程度上是在copy。这不是说我们的工作没有创造性，反而对我们的代码质量提出了更高的要求。
软件检查提高开发效率的同时改进质量，测试一旦开始，有很多缺陷的软件不会被允许交货。问题太多的软件会延长测试过程，同时加大测试成本直到超过项目预算的一半。
对软件开发来讲，设计和代码的预防性检查打下了牢固的质量基础，同时加快测试过程并减少问题的出现。
下面总结了最常见的方法：
1、走查
最平常的回顾可能是非正式的走查了，
是指任何两个以上的开发人员以增进软件质量为目的所召开的回顾技术工作会议。走查对于快速开发很有用，因为这样可以在测试前就发现漏洞。举例来讲，测试能够发现需求漏洞的最早实践是需求刚被列入清单、设计和编写的时候。走查可以在写设计说明书时，在设计和编写完成之前就发现漏洞。走查可以发现30%到70%的程序漏洞。
2、代码阅读
代码阅读是比走查更正式些的回顾方式，但仅适用于代码。代码阅读中，写这段代码的程序员把代码清单交给两个或更多的审阅者审阅。审阅者阅读代码并把发现的错误报告给作者。代码阅读能发现的漏洞是测试时能发现漏洞的两倍。这意味着，在快速软件开发时，将代码阅读和测试结合在一起，会比仅仅测试在时间进度上更具有效率。其实，作为新员工在阅读前辈的代码时，一边阅读，一边试着按照自己的理解去做一些修改，看看结果是否和自己想得一致的做法从某种意义上来讲就是重构。
3、检查
检查是一种正式的技术回顾，他被认为是在整个项目中最具有效率的差错方式。使用检查的方法，开发人员要接受关于检查的特殊训练，并且在检查中扮演重要的角色。在检查会议之前，“仲裁人”发布产品要被检验估算的消息。“审阅人”在会议前检查程序，并且用检查列表激励他们的回顾工作。在检查会议上，“作者”通常要解释要检验的东西，“审阅人”鉴别错误，“书记员”纪录错误。在会后，仲裁人写一份报告说明每个漏洞和该如何处理它。贯穿整个检查过程，你需要收集漏洞的数据，花一些时间改正漏洞，花一些时间再进行检查，以便你可以分析软件开发进程的效率并不断改进它
和走查一样，你可以使用检查的方法比测试先一步发现漏洞。你可以在项目中使用它对需求分析、用户界面原型、设计、编码以及其他人为的过程查错。检查可以查出程序中60%到90%的漏洞，这点要比走查或测试要要。因为可以在开发周期的早期应用，因此，检查方法被证明可以节约10%到30%的开发时间。一项对大型程序的调查结果显示，在检查上每花1小时，可以避免在维护中33小时的花费。检查比测试有效20倍以上。
来自：blog.csdn.net/blueluhan/archive//08/08/2787247.aspx
前言
作为软件开发者，我们很羡慕那些商业软件的开发人员，比如Windows，因为感觉它们的开发者很幸福，不会说哪个用户提出来某个功能就马上去修改程序，甚至当用户使用这些软件的时候出现了问题首先都会怀疑是不是自己的操作出了问题，
不幸的是我们很多开发人员从事的是行业软件、定制软件的开发，总会听到定制的声音，总会感到需求的不断改变，总会感到软件永远没有稳定下来的日子，总会感到修改的日子没有尽头，
管理人员也很头疼，按照研发规范的要求，开发人员必须在编写代码的同时编写设计文档，然而不断的修改最终使得文档的编写成了累赘，于是：
我们的文实一致性得不到保证
我们的设计文档成了“废物”，甚至误导
我们的新员工花费了大量的时间阅读文档却发现不如去直接读程序
我们加班却总是发现有永远干不完的事情
……
传统软件工程中对软件开发过程的定义在这种需求变化频繁、却要求快速交付的软件开发实践中显得那么的无助。大家都在困惑，在寻找出路，于是，当我第一次在ThoughtWorks的网站上看到关于极限开发的理念时，很激动，开始了关于极限开发的学习，也尝试根据自己的理解在工作中实践。网上关于极限开发的争论一直都很多，关于这套理论并不是一切问题的终结者，但是随着学习和思考的深入，我日益感觉到极限开发理念为我们提供了一个新的思维方式：原来，我们可以这样思考问题！比喻的说就是我们的开发模式如思想般已经僵化了，需要一种新的声音来灌输新的活力，只有思维活跃了，才能创新，作为开发人员不光是技术需要创新，思维更要创新。更重要的是，我觉得对于硬件开发，极限开发理念中一样有其可以借鉴的地方。
希望能够通过根据自己的体验解读有关极限编程的12大原则，来吸引更多的志同道合者一起对我们的工作进行思考和改良。
来自：blog.csdn.net/blueluhan/archive/2008/08/08/2787126.aspx
系列文章目录索引：《解读极限编程的12大原则》
编码标准：遵守编码标准，让其它程序员明白代码，减少不必要的沟通，
通常，在公司中都有编码规范，然而这些编码规范执行的好与坏却很少有人关心，编码规范有两个大的方面作用：一是可以使代码容易理解，当然这也是最主要的作用；另外就是通过有效的编码规范可以提高程序的稳定性。下面就给大家介绍一下以前项目团队中关于编码规范方面的要求。
命名规则
一个简单的原则，就是通过命名能够反映变量的数据类型和含义、函数方法的使用范围和含义。我个人觉得匈牙利命名方法还是比较适合的。比如看到gi_find我就知道这是一个公用的int变量，看到wf_find我就知道这是一个窗体函数。这样的规则有利于在编程时防止数据类型的错误使用，自然我就不会将一个字符串赋给gi_find变量。
异常的处理
首先不要轻易使用异常的捕获，其次要尽可能捕获具体的异常，
对于异常的处理最好能够采用封装的方式，大家统一使用。这样可以保证异常处理的一致性也可以保证当异常出现时性能的稳定。
与性能有关的方面
这就视开发工具的不同而有具体不同的要求了，比如常见的，不要在循环中定义变量；对于数据库的查询缓存与及时查询的选择；SQL的写法等等。
上面只是说到了编码规范的几个方面，翻阅我们制定的编码规范，我们可以看到洋洋洒洒几十页，可是再看看我们的程序，是否真的遵从的编码规范呢？我看到很多代码中i,x,y这样的变量定义随处可见，一会儿定义成字符类型，一会儿定义成数据类型，还有变量定义而不知道哪里使用了。对于编码规范的落实，除了依靠个人素质以外，还是更应该从代码检查入手。编码规范的养成，不但有利于项目，更有利于个人，就如同一个人的礼仪，通过长期的培养形成了习惯之后就自然会有一种气质，同样的，当你养成良好的编码习惯后，无论走到哪里别人看到你的代码，先不说程序思路有多好，光看编写风格就可以看出你是否经过正规的实践。
来自：blog.csdn.net/blueluhan/archive//08/19/2793248.aspx
系列文章目录索引：《解读极限编程的12大原则》
小版本：用最少的代码工作量带来最大的业务价值，
这个原则是意思是为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。
这么一说，感觉这一原则对我们公司的产品是没有什么适用性的，我们不可能让运营商承受这样的高度迭代过程。然而，正如我一开始就提到的，我们学习敏捷开发、极限编程的目的不是为了解决所有的问题，而是开拓思路，防止我们的思维僵化。据我的观察，我们的测试部开发的自动化测试、调试软件就非常适合利用这个原则。客户是谁呢？就是负责生产调试的内部客户。
自动化测试、调试软件有个很大的特点就是：变化快，而对于这个特点，正是敏捷开发理论所特长解决的。目前对于这类软件的管理的强度远远要弱于那些产品软件，一方面是因为这些软件因为在使用过程中需求变化太快，如果按照公司的规范输出各类文档，并且按照常规流程管理的话，无法做出及时地响应，会影响工作。另外一方面，就是开发人员的主观因素，常常这类软件都是开发人员在生产线与负责生产调试的人员即时沟通即时修改的，这样的习惯也就导致了习惯成自然，我们的“客户”养成了习惯，开发人员也被迫养成了习惯：开始的时候开发人员往往想反正软件改起来也要比硬件来的容易，那就改吧，一来二往，突然有一天发现自己突然陷入了一个泥潭。
作为技术部的配置管理，我就多次发现这些自动化的测试、调试软件版本混乱的情况，而且从使用这些软件的人员反馈回来的声音中，我们也可以听到对于软件质量方面的抱怨，
这就是我说到的“泥潭”：作为开发者，自己每天疲于修改，却无法得到“客户”的认同，这是一件多么让人郁闷的事情啊！
那么我们是不是可以考虑利用敏捷开发的方法来解决这些问题呢？或者，通过一种思维上的启发来“创造”一个适合我们实际情况的方法来解决这些问题呢？我想到了一些改善的方法：
增加小版本信息，在软件运行中就能够看到大、小版本信息。
增加在线更新功能，这样无论身在公司何处，只要能够连入内部网络，就可以及时、准确地更新程序。
增加版本检验功能，根据需要检测版本是否需要更新，以此来保证当需要时，保证所有的客户端都运行在一个基准之上。
增加错误反馈、日志功能，保证当错误发生时能够通过邮件将必要的信息反馈给开发者。这样可以防止在问题反馈时问题无法复现或者反馈人说不清楚的情况。
这些方法其实都是我们在很多软件中能够看到的功能，并不是什么新奇的技术，实现起来也很容易，而且我们可以将这些功能作为一个公用模块来保证不同的自动化测试、调试软件不用重复开发。这些功能的实现将会让你体会到更多的方便。
有了这些基础，我们就可以在软件开发的过程中将高迭代过程变得更容易控制、实施起来的效率也会更高，效率提高了，时间节省了，才能有条件去思考、去改进。就如同我们的胳膊自由了，呼吸顺畅了，才有可能将自己从泥潭中解救出来一样。
来自：blog.csdn.net/blueluhan/archive/2008/08/08/2787187.aspx
系列文章目录索引：《解读极限编程的12大原则》
现场客户：讨论，使用程序员和客户都能够的语言描述功能，
刚刚参加工作的时候，公司的项目都是严格的区分项目阶段，先是收集用户需求的阶段，由我们的系统设计人员到客户现场通过跟客户的沟通编写出一份很厚的用户需求说明，这个阶段往往需要1、2个月的时间。而沟通的过程呢，也是相当的“粗糙”，因为当时的客户了解软件的人很少，不知道软件可以实现成什么样子，跟他们了解业务，客户自己都很难将自己的业务描述的一清二楚，所以我们通常的做法就是收集一大堆他们平时业务中的纸质报表，然后拿回来自己分析，看看哪些数据是输入的，哪些数据是计算出来的。但是这样的分析却难以触及业务的本质，我们不知道客户为什么要这么做，而仅仅是将他们的手工劳动改变到了用电脑劳动。其实很多年纪大的人都已经习惯了手工劳动，这样做出的软件对于他们来说不但没有提高工作效率，反而因为要学习如何使用电脑，使得工作难度增大了。
然后，进入到系统设计阶段，在公司内部分模块写设计方案，将用户需求转化为给研发人员看的设计文档，这个阶段又花费了1个月的时间。到了真正开始编码的时候，开发人员看到的已经是完全经过设计人员“修饰”过的需求。
在这种模式下就很容易出现用户想要一个“秋千”，结果我们设计出了一个“挂着绳子的轮胎”这样的情况，
更多的悲剧是因为周期过长（从最初的客户现场用户需求收集到软件在客户现场实施会有半年左右的时间），当我们的软件安装到客户现场时，当时的需求提出人自己都忘记了最初提出的需求是什么样子的，或者是当时提供需求的客户发生了变化，等等原因，使得我们的开发人员不得不在客户现场进行需求的重新收集和确认。于是，项目计划必然拖延。
对于定制特征比较明显的软件项目，需求的多变是常态，所以敏捷开发正是清醒的认识到了这一点，需求的变化的不可避免的，与其想办法通过各种手段去减少变化，不如改变思路去面对变化，保证当变化来临时开发进度的高效。
现场客户这个原则有两个主要内容：第一，鼓励和客户一起开发，无论是将客户邀请到公司内部还是开发人员到客户现场。第二，就是在和客户沟通需求时采用场景的方式将用户的需求一个个描述出来，而描述的语言是程序员和客户都能理解的，这样就不需要再经过任何人的重新“润泽”，也就减少了需求在“解释”的过程中被曲解的风险。
当然，客户的素质不同，会导致沟通时的成效也有很大区别。这时，我们通常采用工具（比如Visio、VB、DHTML等一些能够快速开发的工具），首先将业务界面速成，展示给用户，在界面的帮助下进行业务需求的梳理。因为用户通常对看得到的东西感兴趣，如果讨论来讨论去没有任何实物去帮助他理解，客户的思维很难和程序员的思维保持一致。
来自：blog.csdn.net/blueluhan/archive//08/08/2787277.aspx
系列文章目录索引：《解读极限编程的12大原则》
代码共享：在通过测试的前提下，任何一个人都能够对系统做出修改，
代码共享不单单是对代码阅读修改权限的一个共享，而是一种知识的共享。要想做到在通过测试的前提下，任何一个人都能够对系统作出修改，是需要很多前提的：
代码的编写规范是一致的
代码的可阅读性
熟悉代码对内、对外接口的定义
人员的开发技能
在敏捷开发、极限编程的其他几个原则中都已经为实现代码共享作了各种准备工作，例如，简单设计、重构增强了代码的可阅读性，配对编程通过工作方式上的压力实现了深层次的知识共享，编码标准使得代码的编写规范是一致的，
对于研发人员来说，谁都愿意能够学的更多一些，掌握更多的开发技能，这样对自己的职业生涯也是有很大帮助的。然而，在实际的情况中，因为进度的压力，不可能给每个人充足的时间去锻炼成为全才；因为人性，大家都希望自己成为“不可替代”的人而不愿将自己的知识共享；因为技术发展的速度越来越快，我们的精力仅仅够我们成为专业人才而不是全才……。于是，代码共享也就成为了大家都愿意去想（其实作为公司，是最乐意的，这样可以减少人员流失带来的问题），但是却仿佛“永远”难于做好的一件事情。可以这样说，如果没有配对编程，就很难实现代码共享原则。配对编程本来就已经是难于实现了，那么代码共享自然就是难上加难了！
来自：blog.csdn.net/blueluhan/archive/2008/08/08/2787269.aspx
系列文章目录索引：《解读极限编程的12大原则》
计划的制定：包括客户选择的项目大小、程序功能的优先级、各个版本的合成和发布日期，
曾经听说过一个关于项目经理的笑话：接手一个项目，领导问项目需要多长时间，我们的项目经理拍拍脑袋说出一个时间节点。领导说这个任务很紧张啊，能不能快一点（再加上一些威逼利诱的话^%$#^%^$#^），项目经理继续拍拍脑袋说出一个时间节点……就这样一番讨价还价，终于领导满意了，临走关切的问没问题吧？项目经理拍拍胸脯说请领导放心。项目经理回来找到技术骨干，把项目时间节点一说，拍着骨干的肩膀说，兄弟，靠你了！项目开始后进度一再拖延，迟迟不能完成交付，项目经理着急的拍着大腿，怎么办啊~~~~最后，项目失败了，项目经理拍拍屁股，走人！
作为项目经理，几乎是很难能够按照自己的意见确定一个项目计划的，为什么？这里面有多种原因，上司总是会用市场需求等等原因来要求项目周期尽可能的短，而项目经理又不能拿出一个很有说服力的数据来证明项目就应该有这么多的时间。于是项目时间节点的确定就完全变成了菜市场上的讨价还价，上司尽可能的压缩，项目经理尽可能的给自己留余地。
当项目经理的时候，我就碰到过这样的情况，项目刚开始的筹划的时候，领导满口答应派给我的人力资源到了项目开始运作的时候居然都没有到位！怎么办，安排新人吧，领导说人数满足你的要求了，我听得差点吐血。新人需要培训、需要磨合，这些不花时间么？！其实很多人都知道在开发过程中并不是1+1=2这么简单的道理，活干不完了，加班！还干不完，加人！人越堆越多，效率却越来越低，为什么？因为开发需要沟通，沟通的成本随着人员的增加会成数倍的增大：两个点用一条线，三个点要用三条线，四个点需要六条线，五个点需要九条线，六个点需要十五条线……我不敢往下数了，当一个团队到了10个人的规模沟通的工作就很可怕了，
以前做行业软件的时候，公司会把软件模块按照功能点列出来，然后针对每个功能点在不同的技术实现方式下需要多少人月估算出来（当然这需要历史项目的积累）。然后在跟客户谈合同的时候根据用户选择的功能点制定出人月，进而得出报价。在很多软件公司都是这么做的。而我们公司现在也正在向这个方向努力，将来的软件也会像物料一样进料单，也会有成本，现在的IT部已经开始做探索工作了，他们的软件现在都是按照组件为原则进行划分，建立部件。将来理想模式就是用户如果需要我们的软件，那么只需要在产品结构树上选择部件，就可以组成“料单”，我们的开发人员就可以根据这个“料单”进行组合。同样，我们的项目经理就可以根据这些信息估算出软件报价和项目人月数了。当然，所有这些梦想实现的前提是这些软件部件真正做到了组件化，接口真正做到了可以灵活改变。
目前的项目大多数是“背靠一堵墙”进行时间计划的，这一点在目前竞争激烈，以占领市场为前提，以生存为目标的大环境下是很难改变的。那么我们作为“底层”人员是不是就放弃了呢？其实，我倒是觉得越是在这种情况下，越能体现敏捷开发、极限编程的优势。不管我们身处项目的哪个岗位、什么角色，我们都可以以自己微薄之力，从自己开始进行改善。
我们可以抱着积极的心态去参加项目计划的制定，虽然我们不能推倒那堵大墙，但是我们可以让每一次项目计划的同行评审会议变得更加实际、更加有意义。我们用短短的两个小时认真的分析出各个功能点的人月，分析出功能点的优先级别。即便是经过分析，我们需要的时间远远多于公司的要求，也应该有勇气去发出不同的声音。我想，也也正是敏捷开发理念中提到的四个原则之一：勇气。因为我们知道计划永远赶不上变化，所以我们要做的是调整态度，勇敢地去做好准备迎接变化，自然，迎接变化不是光凭勇气，还要有各种具体的、实际的工作，这些工作就包含在我们接下来要解读的其他原则中。
来自：blog.csdn.net/blueluhan/archive/2008/08/08/2787162.aspx
★ 心理极限作文
★ 挑战极限作文
★ 垂直极限观后感
★ 快乐极限作文
★ 解读
★ 编程学习计划
★ 数控编程技巧
★ 信息编程论文
