极限编程XP︱一文搞懂极限编程XP的关键实践
2022-11-10
来源：ZyBlog 码农老张
呢？
我曾经待过的一个公司，也不算是特别大的公司，是一个上市公司的子公司。程序员吧，说多不多，说少也不少。我在其中感受最深的就是，我们所有 PHP 工程师写出来的代码基本都是一样的。什么意思呢？如果没有注释，如果没有 Git 记录，你可能很难分辨出这段代码是谁写得。我们在入职的时候，都会熟读一份编码标准的文档，然后统一都按这个文档来执行。并且在 Code Review ，也就是代码审查的时候，也会在团队的指引下对不符合规范的代码进行修正。
当然，这只是一个实例，好处自然不用多说，各个部分自解释，沟通确实是不需要文档，因为他的代码一拿过来我就知道这一段或者那一段是在干什么的。另外，我随时可以迅速的维护另一个人之前写过的内容。坏处嘛，也有，那就是这样的工程会缺少一些灵性，很多东西会写得过于死板。但是对于大公司或者大型的项目而言，它的好处是要大于坏处的。
从上面的例子以及前人的经验来说，我们可以总结出编码标准的七个原则：
不要预先花费太多时间
目标应该是团队中没有人辨认各自的代码
以团队为单位对某一标准达成协议，然后遵守这一标准
不是事无巨细的规则列表，而是确保代码可交流的指导方针
编码标准开始时应很简单，然后根据团队经验逐步进化
创建能够工作的最简单标准，然后逐步发展
只制订适合本团队的
小组实践（四）：集体拥有代码
这个概念其实现在在日常的企业中也开始越来越多的出现了。那就是代码是“我们”的，而不是“我”的，也就是说，我们都可以修改任何人的代码，这个代码也是属于任何人的，而不是某个特定的人。不过，你改动没关系，但请通过我的测试，如果测试有问题，那么提交之后就会影响线上的运行，进而影响整个团队。从这里来说，又和之前讲过的测试驱动开发联系上了，果然还是一环套一环啊。
另外，光是测试还不够，我们还要有 编码标准 ，可以结对编程 ，能够进行简单设计 。这一系列相关的实践操作能够在团队内灵活运用的话，才能说我们的代码可以达到真正的集体所有。
跨敏捷小团队范围的代码也是可以共享的，前提是这些不同的小团队应该是服务于同一个大的项目。而人数不多的小范围集体拥有代码也是敏捷所推崇的。
小组实践（五）：稳定高速的步伐
这个应该是所有码农都喜欢的，而所有管理者都讨厌的一个东西了。为啥呢？稳定两个字透露出来的是什么含义？就是别突然给我加班呀。我们要保持一个稳定的速率，在每个迭代周期内应该完成差不多的东西，并且让团队把注意力集中起来，专注地在工作时间内完成更多的东西，这样就能够达到高速的目的。
嗯，老外那边对于加班这个问题确实还是看得比较重的。其实硅谷的大公司加班的不在少数，但他们确实也把待遇和金钱给到位了。而国内的公司，除了少数头部大企业之外，很多小企业都只是想要培养狼，却不给狼吃肉的这种尴尬状态，也就是我们最常说的 996 ，而且小企业还是根本没有任何补贴的 996 。
这个东西吧，不多做讨论了。毕竟我还在一个大小周的公司上班，虽说没有到 996 这个地步，但还是每两周都多了一天的上班时间。有些东西，年轻的时候经历一下可以，但上了年龄之后，就不要羞于不谈条件了，改变不了的话就谈条件，该得到的应该要去争取。
交付和管理（一）：完整的
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
