代码诊所

几年前,我有机会负责一个项目的咨询。团队很小,目标是对旧有系统的后端用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 条评论
登录 后参与评论

相关文章

来自专栏Java技术栈

最新后端架构师技术图谱!附学习资料~

2122
来自专栏文渊之博

关于范式的一些简单理解

---恢复内容开始--- 数据库范式(Normal forms):是用于规范关系型数据库设计,以减少谬误发生的一种准则。 尽管有很多概念定义性的东西,但是在实际...

1808
来自专栏吉浦迅科技

DAY47:阅读read only cache和Time Function

The read-only data cache load function is only supported by devices of compute c...

501
来自专栏企鹅号快讯

编程语言中间令人无语的规则

我们都知道,软件开发人员每天都在做各种各样的决策:如何更好地实现功能、如何修复bug、如何改进应用程序性能等等。但是他们也在其他人的工作成果中继续自己的决定,例...

3405
来自专栏信安之路

奇淫异巧之 PHP 后门

早上看了一位小伙伴在公众号发的文章《php 后门隐藏技巧》,写的挺好,其中有一些姿势是我之前没见到过了,学到很很多。同时,这篇文章也引发了自己的一点点思考:“ ...

460
来自专栏Java学习网

想成为优秀程序员必知的要点

想成为优秀程序员必知的要点 1.永远不要重复代码 不惜一切代价也要避免重复代码。如果你有几个不同的地方经常性地要使用某个代码片段,那么可以将它重构成函数。代码...

2077
来自专栏带你撸出一手好代码

神秘的力量:信息隐藏

「信息隐藏」在软件开发领域中是一个非常重要的核心要点, 它的另一个名称叫做「封装」, 但是因为现代面向对象技术流行的原因, 「封装」似乎已被视为和private...

2707
来自专栏玄魂工作室

CTF实战32 综合实战和讲解二

该培训中提及的技术只适用于合法CTF比赛和有合法授权的渗透测试,请勿用于其他非法用途,如用作其他非法用途与本文作者无关

523
来自专栏个人随笔

Java核心技术(Java白皮书)卷Ⅰ 第一章 Java程序设计概述

第1章 Java程序设计概述 1.1 Java程序设计平台  具有令人赏心悦目的语法和易于理解的语言,与其他许多优秀语言一样,Java满足这些要求.  可移植...

26210
来自专栏机器之心

资源 | 这是一份收藏量超过2万6的计算机科学学习笔记

项目地址:https://github.com/CyC2018/Interview-Notebook

803

扫码关注云+社区