8个驯服烂代码的原则：bjdp.org第13次编程道场回顾

* 时间：2014.02.23, 2:00-5:45pm

* 地点：北京直真科技技术股份有限公司

* 参加人数：24人

* 活动主题：驯服Trivia烂代码（Java版）

* Java版Trivia未驯服前源代码：https://github.com/wubin28/trivia/tree/master/java

* 伍斌第一次驯服Trivia的源代码：https://github.com/wubin28/TriviaJava

* 伍斌第二次驯服Trivia的版源代码：https://github.com/wubin28/TriviaJava-2nd

* 活动过程：

1. 伍斌介绍编程操练和驯服Trivia烂代码的一些体会

2. 在座匠友用绘图和代码做自我介绍

3. 伍斌现场编码演示驯服Trivia烂代码的一些步骤

4. 在场匠友结对编程驯服Trivia烂代码（每对7分钟）

* 整理出的8个驯服烂代码的原则：

1. 正在被客户端使用的服务端的公共接口不能改

2. 如果没有测试保护，则不能改相关代码

3. 让不能改的公共接口尽量地窄

4. 尽量早地消除重复代码

5. 尽量用整洁的代码替代注释

6. 对于无法修改且“词不达意”的公共接口，要添加what注释

7. 要编写粒度大些的验收级别的测试，比如验收特征测试(Acceptance Characterization Test)，来覆盖尽可能大的范围，且与实现细节解偶，有利于方便地进行代码接口实现层面的重构，减少测试编写和维护的数量

8. 尽量多用SonarQube做代码内在质量的静态扫描

* 回顾要点：

- 在重构前，一定要先写测试代码，把要重构的代码先保护好，之后才能重构。

- 为获得最大限度的效果，在做驯服烂代码的结对操练前，各位匠友应该事先预习Trivia烂代码的逻辑。主持人在得知大部分与会者都未预习的情况下，在一开始应该增加一起阅读代码和添加注释的环节。

- 在重构代码时应该要考虑性能（伍斌的观点：在重构代码时，若能先把代码的可读性和可扩展性重构好，那么就能让提高性能的工作更加轻松。）

- 除了消除明显的重复代码，也要消除那些不大明显的重复代码

- 在消除魔法数的过程中，同时也想把魔法数转移到另一个新类中，感觉有些顾此失彼。建议一次只作一件事，即可以先在那个“身兼数职”的原有类中消除魔法数，再把魔法数转移到一个新类中。

- 在测试代码中，创建待测的类的实例这条语句，应该放到@Before里面，使得每个测试运行前，都能得到一个崭新的实例。而不要作为测试类的一个成员变量，以避免不同测试之间共享一个实例而造成相互干扰。

- 了解到SonarQube这个做静态代码内在质量扫描的工具

- 编程操练的形式很好

- 可以考虑以后再办一次驯服烂代码的道场

- 驾驶员和副驾驶介绍思路时声音太小

- 驾驶员敲代码和介绍思路时速度较快，使得副驾驶不了解驾驶员的思路

- 副驾驶刚刚换上时，应与驾驶员做相应的沟通

- 下次编程道场可以请大家自带电脑分头两两结对编程，而不是都轮流共用那台连接投影仪的电脑（伍斌的观点：这两种情况各有利弊，不过我个人觉得后者能让大家更专注，效果会更好）

* 疑问

- 驯服烂代码不知从哪里开始（伍斌的观点：先从区分哪些是不能修改的接口开始。）

- 结对编程的目的是什么？两人如何配合？如果两人想法不同该怎么办？（伍斌的观点：结对编程的目的就是“知识的相互传递”，对于个人能增长技能，对于公司能减少因专职负责某个模块的程序员生病、休假而造成的“单点故障”，让团队更健壮。结对编程中，两人的想法肯定会有所不同，这一点即使在日常不编程的工作中，也会时时碰到。我个人认为，解决方法也和日常碰到的情况一样，即需要掌握良好的沟通方法，比如要摆正沟通的位置：沟通不是为了说服对方，而是为了了解对方。您了解对方越多，您就越能和对方配合好。）

喜欢我今天的文章，不妨点击右上角按钮分享到朋友圈，以广结善缘。无论是否喜欢，都可回复本条微信，我必看必回。

您看到的上面我写的文章，首发于微信公众号bjdp_org。该公众号服务于我创办的bjdp.org公益编程操练社区。在这里，程序员们聚在一起，编程、学习、找乐子；和测试工程师一起结对编写验收测试代码；与产品需求专家一块探讨如何能让软件开发的成果不离谱。程序员、测试工程师和产品需求专家，是密不可分的“三兄弟”。

欢迎在微信上搜索bjdp_org关注北京设计模式学习组。

如果您想看本公众号以往的精彩内容，请回复m