极限编程XP的关键实践 极限编程的核心实践( 二 )


当然,你也可以在控制层写服务,也可以在模型层写服务,总之,找出关键核心的处理业务逻辑和算法的地方,加强这个地方的测试覆盖率,不要盲目的以整体的测试覆盖率为标准,这才是 TDD 能够更好运用的重要方面 。
理论归理论,这方面其实我并没有太多的实战经验,不过我也觉得测试覆盖率不能说明一切,在这里更希望有经验的同学能够分享相关的经验,可以评论里留链接或者加好友转载文章哦!
编程方法(三):重构这个词对于写代码的人来说就更不陌生了,甚至很多人在换到新的公司时,第一个建议就是咱们重构一下老项目的代码吧,因为前人写得太X了 。当然,想法总是好的,但现实其实是很残酷的,真正的重构不是说我们要让所有的代码都变成你喜欢的代码 。真正的重构是源于敏捷的不断迭代的重构 。在收下两种情况下,我们通常会开始重构一段代码 。

  1. 实现某个特性之前:尝试改变现有的代码结构,以使得实现新的特性更加容易
  2. 实现特性之后:检查刚刚写完的代码后,看是否能够进一步的优化
在重构中,有一个重要的概念就是 Don't Repect Your Self 也就是非常出名的 DRY 原则 。从开发的角度来说,就是不要让一段相同的代码出现两次 。另外,重构还和 XP 中的其它元素紧密相关,比如说代码集体所有制,让代码共享所有人都能看到代码,并且通过结对编程,你的重构也会被别人发现并指出优劣 。需要完善的测试驱动开发机制,这样才能确保你的重构不会带来问题 。简单的设计,会让你在重构的过程中关注最核心的部分,写出能够实现功能的最简单的代码 。
通过上述内容,其实我们也就保证了 XP 中 勇气 的含义,让你能够勇敢的去重构 。
编程方法(四):简单设计还记得 XP 核心思想中的 简单 原则吗?没错,设计是很重要,但是,我们应该从最简单的设计开始,通过迭代和增量不断地完善它,而不是一开始就做出一个复杂的设计来 。对于简单来说,并不是说所有的设计都很小,只是说我们需要的是尽可能简单的设计它,让它尽快跑起来,通过持续发布来不断验证和完善 。
之前听说过一个故事,也是程序员间的笑话 。一个公司上来就是各种高精尖的技术,各种高并发的处理,引入了一大堆阿里、腾讯的功能架构实践 。结果呢?每日最高只有可怜的几百日活 。而这个项目做了多久呢?几百人的开发团队,一年的开发时间,最后不了了之 。
还好,目前大部分公司都不会再干这种事 。甚至很多公司都会以 MVP(最小可行版本) 的形式来进行新项目的开发 。这是好事,也是值得提倡的 。那么,在 XP 中,对于简单设计有什么建议吗?
  1. 编写测试代码
  2. 保持每个类只负责一件事(单一职责原则)
  3. 迪米特法则(最少知识原则)
  4. DRY 原则
  5. 简单的设计需要简单的思考,要有勇于重构的勇气和定期重构的习惯
小组实践(一):持续集成持续集成也是我们码农们经常听到的一个名词,甚至不少人也使用并实践过 Jenkins 、Travis CI 这类的持续集成工具 。但是你知道吗?这些工具的诞生也正是因为受到 XP 的影响 。
持续集成的关键点是什么?不断的编译整合代码,在你将代码提交到 Git 的时候,测试环境就开始进行单元测试,如果没有通过,那么会报出异常,如果通过了,就会直接打包代码 。这样就可以使代码随时保持在可以发布的状态 。因此,随时整合,越频繁越好,集成及测试过程的自动化程度越高越好,这就是持续集成的根本概念 。


以上关于本文的内容,仅作参考!温馨提示:如遇健康、疾病相关的问题,请您及时就医或请专业人士给予相关指导!

「四川龙网」www.sichuanlong.com小编还为您精选了以下内容,希望对您有所帮助: