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