代码诊所

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

当.NET在2000/2001年第一次发布的时候,Java社区认为它仅仅是从语言以及标准库上对Java的一个“克隆”。我们把二者的简单实例代码进行比较以后就可以...

17210
来自专栏儿童编程

关卡类游戏《鱼塘Ⅰ》的Scratch实现

今天用Scratch实现一个多关卡类的小游戏《鱼塘Ⅰ》(从名字可以看出可能有续集,好吧~)。这个游戏很简单(游戏场景见下图),但是需要使用大量的变量、定义函数、...

543
来自专栏恰同学骚年

自己动手写游戏:飞机大战

  要说微信中最火爆的小游戏是哪款,可能既不是精心打造的3D大作,也不是《植物大战僵尸2》,而是微信5.0刚开启时的《飞机大战》。

811
来自专栏程序你好

软件设计原则——DRY(Dont Repeat Yourself)和KISS( Keep It Simple, Stupid)

551
来自专栏码神联盟

碎片化 | 第四阶段-47-值栈细节问题-视频

本套视频从Java基础到架构模式以及AI算法,整体视频以“碎片化”学习的模式,提供给大家 ,并配备实际项目为案例,让大家在坐车、吃饭、午休、蹲坑的时候,都可以学...

3105
来自专栏一心无二用,本人只专注于基础图像算法的实现与优化。

SSE图像算法优化系列五:超高速指数模糊算法的实现和优化(10000*10000在100ms左右实现)。

      今天我们来花点时间再次谈谈一个模糊算法,一个超级简单但是又超级牛逼的算法,无论在效果上还是速度上都可以和Boxblur, stackblur或者是G...

27710
来自专栏瓜大三哥

改善时序的方法

时序约束的目的本质上是通过时序约束对Vivado的布局和布线过程进行干预,也就通过Vivado工具重新规划设计中所有功能单元的位置,以及布局的策略。 时序约束...

21510
来自专栏腾讯移动品质中心TMQ的专栏

和开发一起写代码,让测试左移起来

一、写在前面的话 互联网产品的迭代速度之快,各位都深有体会。做为产品质量的保障者,测试人员经常为测试时间不足而烦恼,如何打破现状来让现在变得更好一些,这是我们一...

1887
来自专栏斑斓

我们的技术实践

本文是我在中生代技术群分享的话题《创业一年经历的技术风雨》中的第三部分《研发团队总结的技术实践》。若要阅读第二部分《技术团队的管理》,请移步中生代技术群公众号。...

3065
来自专栏恰同学骚年

【整理】待毕业.Net码农就业求职储备

声明:本文题目来源于互联网,仅供即将从学校毕业的.Net码农(当然,我本人也是菜逼一个)学习之用。当然,学习了这些题目不一定会拿到offer,但是针对就业求职做...

893

扫描关注云+社区