程序员你为什么这么累【续】:编码习惯-函数编写建议

之前系列文章里面完整的代码已经上github,地址在文章最后

傻瓜都能写出计算机可以读懂的代码,只有优秀的程序员才能写出人能读懂的代码!

在我看来,编写简单的函数是一件简单又困难的事情。简单是因为这没有什么技术难点,困难是因为这是一种思维习惯,很难养成,不写个几年代码,很难写出像样的代码。

大部分的程序员写的都是CRUD、一些业务逻辑的代码,谁实现不了?对于我来说,如果业务逻辑的代码评审,需要人来讲每一个代码做了什么,这样的代码就是不合格的,合格的代码写出来应该像人说话那么简单有条理,基本上是业务怎么样描述需求,写出来的代码就是怎么样的。编写出非开发人员都能看懂的代码,才是我们追求的目标。不要以写出了一些非常复杂的代码而沾沾自喜。好的代码应该是看起来平淡无奇觉得很简单自然,而不是看得人云里雾里的觉得很高深很有技术含量。

如果你做好了我前面几篇文章的要求,编写简单的函数就容易的多,如果你觉得我之前说的去掉local,去掉用户参数这些没有什么必要是小题大做,那么我觉得你写不出简单的函数。从个人经验来说,函数编写的建议有以下几点:

1 不要出现和业务无关的参数

参考我之前的帖子,我的编码习惯 - 参数校验和国际化规范,函数参数里面不要出现local,messagesource,request,Response这些参数,第一非常干扰阅读,一堆无关的参数把业务代码都遮掩住了,第二导致你的函数不好测试,如你要构建一个request参数来测试,还是有一定难度的。

2 避免使用Map,Json这些复杂的数据对象作为参数和结果

这类参数看着灵活方便,但是灵活的同义词(代价)就是复杂,最终的结果是可变数多bug多质量差。就好比刻板的同义词就是严谨,最终的结果就是高质量。千万不要为了偷懒少几行代码,就到处把map,json传来传去。其实定义一个bean也相当简单,加上lombok之后,代码量也没有几行,但代码可读性就不可同日而语了。做过开发的人应该很容易体会,你如果接手一个项目,到处的输入输出都是map的话,request从头传到尾,看到这样的代码你会哭的,我相信你会马上崩溃很快离职的。

还有人说用bean的话后面加字段改起来麻烦,你用map还不是一样要加一个key,不是更加麻烦吗?说到底就是懒!

如果一个项目的所有代码都如下面这样,我是会崩溃的!

/**
 * !!!错误代码示例
 * 1. 和业务无关的参数locale,messagesource
 * 2. 输入输出都是map,根本不知道输入了什么,返回了什么
 * 
 * @param params
 * @param local
 * @param messageSource
 * @return
 */
public Map<String, Object> addConfig(Map<String, Object> params, 
    Locale locale, MessageSource messageSource) {

  Map<String, Object> data = new HashMap<String, Object>();

  try {
    String name = (String) params.get("name");
    String value = (String) params.get("value");

    //示例代码,省略其他代码
  }
  catch (Exception e) {
    logger.error("add config error", e);

    data.put("code", 99);
    data.put("msg", messageSource.getMessage("SYSTEMERROR", null, locale));
  }

  return data;
}

3 有明确的输入输出和方法名

尽量有清晰的输入输出参数,使人一看就知道函数做了啥。举例:

public void updateUser(Map<String, Object> params){
  long userId = (Long) params.get("id");
  String nickname = (String) params.get("nickname");

  //更新代码
}

上面的函数,看函数定义你只知道更新了用户对象,但你不知道更新了用户的什么信息。建议写成下面这样:

public void updateUserNickName(long userId, String nickname){
  //更新代码
}

你就算不看方法名,只看参数就能知道这个函数只更新了nickname一个字段。多好啊!

这点只可意会不可言传。

4 把可能变化的地方封装成函数

编写函数的总体指导思想是抽象和封装,你要把代码的逻辑抽象出来封装成为一个函数,以应对将来可能的变化。以后代码逻辑有变更的时候,单独修改和测试这个函数即可。

这一点相当重要,否则你会觉得怎么需求老变?改代码烦死了。

如何识别可能变的地方,多思考一下就知道了,工作久了就知道了。比如,开发初期,业务说只有管理员才可以删除某个对象,你就应该考虑到后面可能除了管理员,其他角色也可能可以删除,或者说对象的创建者也可以删除,这就是将来潜在的变化,你写代码的时候就要埋下伏笔,把是否能删除做成一个函数。后面需求变更的时候,你就只需要改一个函数。

举例,删除配置项的逻辑,判断一下只有是自己创建的配置项才可以删除,一开始代码是这样的:

/**
 * 删除配置项
 */
@Override
public boolean delete(long id) {
  Config config = configs.get(id);

  if(config == null){
    return false;
  }

  // 只有自己创建的可以删除
  if (UserUtil.getUser().equals(config.getCreator())) {
    return configs.remove(id) != null;      
  }

  return false;
}

这里我会识别一下,是否可以删除这个地方就有可能会变化,很有可能以后管理员就可以删除任何人的,那么这里就抽成一个函数:

/**
 * 删除配置项
 */
@Override
public boolean delete(long id) {
  Config config = configs.get(id);

  if(config == null){
    return false;
  }

  // 判断是否可以删除
  if (canDelete(config)) {
    return configs.remove(id) != null;      
  }

  return false;
}

/**
 * 判断逻辑变化可能性大,抽取一个函数
 * 
 * @param config
 * @return
 */
private boolean canDelete(Config config) {
  return UserUtil.getUser().equals(config.getCreator());
}

这就是简单的抽象和封装的艺术。看这些代码,参数多么的简单,很容易理解吧。

这一点非常重要,做好了这点,大部分的小的需求变更对程序员的伤害就会降到最低了!毕竟需求变更大部分都是这些小逻辑的变更。

5 编写能测试的函数

程序猿不招妹子们喜爱的根本原因在于追求了错误的目标:更短、更小、更快。

这个非常重要,当然很难实现,很多人做技术之前都觉得代码都会做单元测试,实际上和业务相关的代码单元测试是很难做的。

我觉得要编写能测试的函数主要有以下几点:

第一不要出现乱七八糟的参数,如参数里面有request,response就不好测试,

第二你要把函数写小一点。如果一个功能你service代码只有一个函数,那么你想做单元测试是很难做到的。我的习惯是尽量写小一点,力求每一个函数都可以单独测试(用junit测试或者main函数测试都没有关系)。这样会节约大量的时间,尤其是代码频繁改动的时候。我们应用重启一次需要15分钟以上。新手可以写一个功能可能需要重启10几次,我可能只需要重启几次,节约的时候的很可观的。

第三你要有单独测试每一个函数的习惯。不要一上来就测试整个功能,应该一行一行代码、一个一个函数测试,有了这个习惯,自然就会写出能测试的小函数。所以说,只有喜欢编码的人才能写出好代码。

我的编码习惯 - 配置规范这篇文章了,我的配置相关代码,都是可以单独测试的,所以配置项的改动不需要测试业务功能,应用都不需要重启。

总结

一句话总结,使用简单参数,不要出现和业务无关的参数,把可能变化的地方都写出独立的函数,力求每一个函数都可以单独测试。

GITHUB地址

所有的代码细节都在已经上了github了,地址 xwjie/PLMCodeTemplate**,欢迎加星。有问题欢迎提出。

点击阅读原文关注作者的知乎专栏

https://zhuanlan.zhihu.com/c_120823325

原文发布于微信公众号 - 程序猿DD(didispace)

原文发表时间:2017-09-19

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏AI科技大本营的专栏

精选26个Python实用技巧,想秀技能先Get这份技术列表!

【导读】Python 虽然是脚本语言,但是因为其易学,迅速成为科学家的工具,从而积累了大量的工具库、架构,人工智能涉及大量的数据科学,用 Python 是很自然...

1455
来自专栏互联网杂技

如何去了解JavaScript引擎的工作原理

1. 什么是JavaScript解析引擎? 简单地说,JavaScript解析引擎就是能够“读懂”JavaScript代码,并准确地给出代码运行结果的一段程序。...

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

【腾讯内部干货分享】安卓包体压缩——分析Dalvik字节码进行减包优化

对游戏整体的压缩却不影响场景,对图片的压缩却不影响品质。最麻烦的是对代码进行压缩,简直是让程序们熬白了头发只为包体再小个几K。

2425
来自专栏C语言及其他语言

【工具资源】迈进C世界的第一步

开始学c的小伙伴 肯定对两个问题焦头烂额 如何选择编译器 到哪里去下载想要的编译器 下面就让小编来帮大家解决这两个问题 ? 细心的小伙伴其实已经发现 咱们C语言...

3627
来自专栏企鹅号快讯

ForeSpider教程连载之链接抽取

自从来到前嗅,小编从一个爬虫小白到现在能够熟练的采集各种网站各种数据真的是有很大的成长,当然,成长过程中肯定少不了踩坑(很多网站都有防爬措施),为了让各位用户能...

2317
来自专栏Crossin的编程教室

【Git 第63课】python 2到3的新手坑

昨天挖了个坑,论坛上已经有不少解答了,还有c语言的版本。今天先不填坑,让题目再飞一会儿,没做的同学可以周末试着写写玩儿。 周三的时候去参加“编程一小时”活动,过...

3407
来自专栏BeJavaGod

BeJavaGod - 如何正确使用数据字典进行分类统一操作(一)

先说说什么是数据字典,这个玩意一般不太会解释,举个栗子吧~ 每个系统都会有用户表,性别:男(1)女(0) 另外我们做物流的会涉及到车型:卡车(1),轿车(2),...

3567
来自专栏Pythonista

Python之路,Day1 - Python基础1

python的创始人为吉多·范罗苏姆(Guido van Rossum)。1989年的圣诞节期间,吉多·范罗苏姆为了在阿姆斯特丹打发时间,决心开发一个新的脚本解...

1772
来自专栏知识分享

12-MQTT介绍

看到这个项目第一想法肯定需要一个服务器,所有的wifi设备和手机都去连接这个服务器,然后服务器进行信息的中转

2384
来自专栏CDA数据分析师

精选26个Python实用技巧,想秀技能先Get这份技术列表!

【导读】Python 虽然是脚本语言,但是因为其易学,迅速成为科学家的工具,从而积累了大量的工具库、架构,人工智能涉及大量的数据科学,用 Python 是很自然...

1182

扫码关注云+社区

领取腾讯云代金券