代码诊所

几年前,我有机会负责一个项目的咨询。团队很小,目标是对旧有系统的后端用Java改写,而团队的开发人员全为C程序员。我的工作职责是负责项目设计、开发,以及担任项目开发过程敏捷化的教练,并培养Java开发人员。

C程序员的一个特点是基本不具备面向对象知识,在初步掌握Java语法之后,写出来的代码还是过程化的代码。团队开发人员的现状就是:没有Clean Code的意识,不知道何谓TDD与重构,写出来的Java代码质量很糟。如果从项目开初不针对这一问题进行有效的防治,就可能导致整个代码库陷入泥沼之中。

为此,我要求在每日站会之后及时开展了代码评审活动。评审过程中,只能以我为主导,帮助大家发现代码的坏味道。从一开始,具有坏味道的代码可谓俯拾皆是,就像我们每天都在呼吸污染了的空气一般不可避免。要净化空气任重而道远,要让团队成员写出好的代码,同样任重而道远。

得有药方才行。

于是我当起了诊治代码疾病的医生。为了更容易传播医疗知识,我在团队工作室的墙角落,开了一个小小的诊所,广而告之——“每日一贴,包治百病”。刚开张时,诊所门面还没装修好,所以直接找了个白板开出了一个药方:

个人认为,这些处方不仅仅对于当时的客户团队有疗效,可能也适合大多数开发团队。几年过去了,我把这些处方分享出来,也算是一个小小的总结吧。先来看看这些处方吧。

第一条:应随时保持架构的清晰与简单:统一所有查询为Repository。

项目其实并不需要访问数据库,而是通过远程的Telnet(或其他协议)去访问前端的设备。然而,我们可以借鉴DDD中资源库的这个隐喻。至于提到的架构,则是我在架构设计时参考了DDD的分层逻辑架构。

为保证架构的简单与清晰,我做了一些“一刀切”的简化原则:例如对Repository和Service的定义。通过Telnet等网络协议获取设备信息的功能不妨看做是对DB的查询。因而,诸如NodeConfigureGetter这样的类就应该统一命名为NodeConfigureRepository。

该处方的主要目的是为了保持代码的一致性,若不加以规范,就会出现Getter、Finder、Query等各种不统一的类名后缀,让人眼花缭乱。

第二条:依赖注入(对象之间的协作)

很多OO初学者并不能理解依赖注入。我的一个办法是让他们从可测试性的角度出发。例如,倘若在NodeConfigureRepository类中直接实例化了TelnetService(这个类提供连接、登录、执行命令等与Telnet有关的操作),那么该怎样在不需要Telnet环境的基础上为NodeConfigureRepository编写单元测试呢?解决不了这样的问题,就说明设计的可测试性不够好。

解决方案就是依赖注入。当时的项目并未引入第三方IoC容器,原因在于项目的Jar包需要和另一个系统协作,并驻留在Flash中。容量有限,不允许引入太多第三方包,保证Jar包的精悍。

第三条:方法名体现意图。

这个问题是许多开发人员都容易犯的毛病,尤其对于面向过程设计的程序员而言,很少会站在对象的角度去思考方法(即行为,准确地说,从设计的角度讲应该是对象承担的职责)。例如在NodeConfigureRepository类中,开发人员定义了getNodeConfigure方法,但返回值却是void:

public NodeConfigureRepository {
    private NodeConfigure configure;
    public NodeConfigureRepository(NodeConfigure configure) {
        this.configure = configure;
    }
    public void getNodeConfigure() {
        getMasterLogicBoard();
        getMasterIp();
        getEnvId();
        getMasterSlot();
        getSlaveIp();
        getSlaveBoardTypeAndStatus();
    }
}

这个方法调用的诸多私有方法实则都是对构造函数传入的NodeConfigure进行数据收集。这样的定义不仅让代码的调用者感觉怪怪的,测试也变得极为诡异:

@Test
public void should_get_main_ctrl_logic_board_type() {
    configure = Nodeconfigure();
    configureRepository = new NodeConfigureRepository(configure);
    configureRepository.getNodeConfigure();

    assertThat(configure.getMasterLogicBoard(), is(12288));
}

怎么改?

方法就是让getNodeConfigure()方法直接返回组装之后的NodeConfigure对象,并且解除NodeConfigure与NodeConfigureRepository之间的生命周期依赖。有趣的是getNodeConfigure方法内调用的私有方法。它成了一种设计的例外,因为在Java中通常需要避免直接对输入参数进行修改,并将其作为返回结果。而在这里出现的一系列方法,实则是履行对NodeConfigure对象的数据收集,因而可以定义为:

private void  collectMasterLogicBoard(NodeConfigure configure) {}
private void  collectMasterIp(NodeConfigure configure) {}
private void  collectEnvId(NodeConfigure configure) {}
private void  collectMasterSlot(NodeConfigure configure) {}
private void  collectSlaveIp(NodeConfigure configure) {}
private void  collectSlaveBoardTypeAndStatus(NodeConfigure configure) {}

我对这些方法的名称进行了修改,使其能够更好地展现其意图。于是,getNodeConfigure()就变成了:

public NodeConfigure getNodeConfigure() {
   NodeConfigure configure = new NodeConfigure();
   collectMasterLogicBoard(configure);
   collectMasterIp(configure);
   collectEnvId(configure);
   collectMasterSlot(configure);
   collectSlaveIp(configure);
   collectSlaveBoardTypeAndStatus(configure);
   return configure;}

这里实际上是Kent Beck提出的Collected Parameter模式。它是Visitor模式的简化设计。当然,我们也可以运用Builder模式对NodeConfigure对象进行组装。

第四条:同一个方法中的实现代码应处于同一抽象层次。

这其实是老生常谈了。Kent Beck在Smalltalk Best Practice Patterns一书中提到了“组合方法”模式,建议“让一个方法中的所有操作处于相同的抽象层”,即所谓的SLAP原则。在Robert Martin的Clean Code一书中也反复提到这一原则,Neal Ford在Emergent Design也有详细描述。

第五条:避免“哑对象”

这里展现的坏味道,在Martin Fowler的Refactoring一书中已有提及。在项目中,存在一些操作Xml文件的操作,并将这些Xml文件的Element映射为了Java对象。我们没有使用Jaxb,因为对于我们有限的xml操作而言,Jaxb还是显得太重。然而,在我们的代码中,包括PackageStatusFileParser、StoragePackageGenerator、DownloadingConfigureParser等类中都存在着将Xml Element转换为PackageInfo、SoftInfo等对象的重复代码。

原因就在于我们将这些对象看做了“哑”的数据对象,而没有将这种转换行为封装到拥有这些数据的对象中(我们的转换仅牵涉到Xml,没有扩展可能,因而无需使用Visitor模式)。

除了会导致大量的重复代码之外,一旦转换逻辑发生变化,例如XmlElement增加了Attribute,就可能需要到处修改,形成所谓的“霰弹式修改”。因而需要将这些逻辑封装到对象中,例如:

public class PackgeInfo {
    public PackageInfo createFrom(Elment element) {}
}
PackageInfo packageInfo = PackageInfo.createFrom(element);

代码虽为细节末道,看似微末,然而在项目开始之初不加以规范与约束,而任其腐化蔓延,最终造成的苦果还是会反击到整个系统;待到代码质量已经堕落到不可修复的地步时,再要挽回,可能已经覆水难收了。

原文发布于微信公众号 - 逸言(YiYan_OneWord)

原文发表时间:2017-03-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏程序员互动联盟

如何提高编写代码的速度?

如何提高代码编写的速度,一直是一个逃避不了的问题。在天朝你得像打字员一样做程序员,不然老板和上司都觉得你是在玩耍。对项目的贡献体现在哪里?码农难道不是以code...

3798
来自专栏LuckQI

美团面试经历,贡献出来一起学习

  晚7点,因为想到下周一才面试,我刚准备出去打个羽毛球,北京的电话就来了。面试官各种抱歉,说开会拖延了。 1、自我介绍 说了很多遍了,很流畅捡重点介绍完。...

1052
来自专栏老九学堂

如何成为一个牛逼的C/C++程序员?

这个题目的噱头太大,要真的写起来, 足够写一本书了。 老九君分享一些经验,希望能让初学的小伙伴少走弯路。 每个人的情况不一样,所以下面的描述可能并不适合每一个...

2944
来自专栏java工会

用JS编写一个Java虚拟机?谈谈哗众取宠的BicaVM

今日目睹某网络新闻,开篇明义便包含如下几行文字 【程序员Artur Ventura,这位超级大牛,用JavaScript写了一个java虚拟机BicaVM】 ...

730
来自专栏屈定‘s Blog

面经

从2016.7来到上海后记录下自己的面试经历,希望能对其他人有所帮助,同时给自己一个提醒.

884
来自专栏程序员宝库

程序员的基础生存技能:高效用Google

来源:GavinZhang( @GavinBuildSomething ) guoze.me/2016/06/26/how-to-google/ 如果说近二十年...

27911
来自专栏刘望舒

一个妹子的Android秋招面试总结(已拿BAT等7家口头offer)

在2018Android暑期实习面试总结曾介绍过个人情况、自学经历、校招流程和复习重点,这部分就不再赘述。那么本篇先以日历形式回顾秋招之路,方便各位参考某厂的处...

4132
来自专栏编程一生

JVM知识在离线数据中的运用

1363
来自专栏WeTest质量开放平台团队的专栏

不修漏洞触犯刑法——一个int类型引发的游戏漏洞

下面转载原文:“网络服务提供者不履行法律、行政法规规定的信息网络安全管理义务,经监管部门责令采取改正措施而拒不改正……处三年以下有期徒刑、拘役或者管制”。

751
来自专栏月牙寂

Golang分布式并发---群体性热点淘汰算法

第一时间获取文章,可以关注本人公众号 月牙寂道长 yueyajidaozhang

3439

扫码关注云+社区