傻瓜都能写出计较机可以读懂的代码，只有优秀的措施员才气写出人能读懂的代码！

在我看来，编写简朴的函数是一件简朴又坚苦的工作。简朴是因为这没有什么技能难点，坚苦是因为这是一种思维习惯，很难养成，不写个几年月码，很难写出像样的代码。

大部门的措施员写的都是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 把大概变革的处所封装成函数

编写函数的总体指导思想是抽象和封装，你要把代码的逻辑抽象出来封装成为一个函数，以应对未来大概的变革。以儿女码逻辑有改观的时候，单独修改和测试这个函数即可。

这一点相当重要，不然你会以为怎么需求老变？改代码烦死了。

如何识别大概变的处所，多思考一下就知道了，事情久了就知道了。好比，开拓初期，业务说只有打点员才可以删除某个工具，你就应该思量到后头大概除了打点员，其他脚色也大概可以删除，可能说工具的建设者也可以删除，这就是未来潜在的变革，你写代码的时候就要埋下伏笔，把是否能删除做成一个函数。后头需求改观的时候，你就只需要改一个函数。