写点什么

编码习惯 - 函数编写建议

  • 2021 年 11 月 12 日
  • 本文字数:1670 字

    阅读完需:约 5 分钟

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


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


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


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


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


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


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


/**


  • !!!错误代码示例

  • 和业务无关的参数 locale,messagesource

  • 输入输出都是 map,根本不知道输入了什么,返回了什么


*/


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 把可能变化的地方封装成函数


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


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


如何识别可能变的地方,多思考一下就知道了,工作久了就知道了。比如,开发初期,业务说只有管理员才可以删除某个对象,


【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开:qq.cn.hn/FTf 免费领取
复制代码


你就应该考虑到后面可能除了管理员,其他角色也可能可以删除,或者说对象的创建者也可以删除,这就是将来潜在的变化,你写代码的时候就要埋下伏笔,把是否能删除做成一个函数。后面需求变更的时候,你就只需要改一个函数。


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


/**


  • 删除配置项


*/


@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) {

评论

发布
暂无评论
编码习惯-函数编写建议