大学毕业4年-回顾和总结(6)-技术研发-重构之法

大部分的公司，开发项目都是作坊式的，没有产品和项目的需求分析，进而做出技术架构和详细设计。很多人，听到上级和老板的一个想法，就开始写代码，边写边改，甚至推倒重来。
最终，导致的常见结果之一，项目代码混乱，新员工甚至老员工，对项目理解比较吃力。如果你去改造代码，改好了，没有任何功劳。改出问题了，领导、测试、产品，很可能会说你不行。这一点，是让很多程序员纠结的地方。
我个人还是倾向重构的，先熟悉项目总体环境，从易到难。项目开发，从外部看，就是一个个的功能。从内部看，不就是一个个函数和API吗。只要输入和输出是稳定的，就不会出现重大的失误，导致牵一发动全身的不良后果。
下面记录一些，我个人自己揣摩的一些重构方法，阅读《重构》这本书，也带给了我一些启发。
1.命名规范化 包名、类名、方法名、变量名，取合适的英文单词。 比如在一个电商项目中。 包名：com.company.shop.front.controller，前端系统的控制层 类名：OrderController，处理订单的控制器 方法名：findById，根据id查找对象，我个人更喜欢用get。 变量名：List<String> memberIdList = new ArrayList<String>(); 会员id的list集合 比较坑的命名：Object tagcode = map.get("tagCode"); 变量命名，没有按照Java驼峰式命名规范来写，“tagcode”和“tagCode”竟然同时存在。 在Java内部代码变量名，如果错了还有提示，在Freemarker和JSP等界面中，字符串的值，用错了，根本没有提示。 大小写不统一的bug，还很难发现。 命名要一致：Controller、Service、Dao等，同一个人和不同人的，尽可能遵循一定的标准，阅读和修改其他人代码也更顺利。 2.代码合理组织 controller：控制器，响应请求，路由控制 service:服务层，处理业务逻辑 dao:数据访问层 model:数据库模型 bean:内部用的实体类 util:工具代码 interceptor:拦截器 其它代码，可以按照功能等进行划分，让人一眼望去，就知道这个包下的代码，大致做了什么事情。
3.项目合理组织 合理拆分项目： 移动端，mobile项目 Web前端，front项目 后端管理：backend项目 合理服务拆分： 商品服务系统：ProductService项目 会员服务系统：UserService项目 登录服务系统：LoginService项目 订单服务系统：OrderService项目 公共代码：Model模型、Util工具类
听说淘宝和京东的电商网站，有几百上千个服务。 4.使用最小最恰当的作用域 类，大多数类用的是public，public class ProductService，如果只是在包内部使用，可以去掉public。 字段，尽可能用private, private ProductService productService。如果需要，通过get和set方法，来获得和修改值。 方法/函数，对外被调用的用public,只在类的内部使用的，尽可能用private。

public void  add(){
doAdd();
}

private void doAdd(){

}

很多人，内部代码都搞成public，乍一眼看上去，还以为外部有调用。 必须得看看依赖，才确定。 对外暴露了过多的接口，不该被调用的被调用了。
5.常量提取 "success"，把作用一致并且相同的字符串，提取成常量，统一管理。 其中一种方式：

public class FrontConst {

public static final String COOKIE_LOGINNAME = "loginNameCookie";

public static final String COOKIE_PASSWORD = "passWordCookie";

}

6.重复代码提取和封装 业务代码，提取成私有方法，内部重复使用。 工具代码，提取到工具类中，可以复用，比如日期处理、把list转换成map。

public class BizUtil {
/**
* 把1个集合，转换成Map。用法示例：Map<String, Dictionary> dictionaryMap = BizUtil.listToMap("BIANMA", dictionarys);
* @param keyName 集合元素唯一字段的名称
* @param list 集合元素
* @return map
*/
public static <K, V> Map<K, V> listToMap(final String keyName, List<V> list) {
if(CollectionUtils.isEmpty(list)){
return null;
}
return Maps.uniqueIndex(list, new Function<V, K>() {
@Override
public K apply(V v) {
try {
return (K)PropertyUtils.getSimpleProperty(v, keyName);
} catch (IllegalAccessException | InvocationTargetException | NoSuchMethodException e) {
e.printStackTrace();
return null;
}
}
});
}

/**
* 把1个集合，转换成Map。用法示例：Map<String, Dictionary> dictionaryMap =
* BizUtil.listToMap(String.class, Dictionary.class, "BIANMA", dictionarys);
*
* @param k
*            Map的key的class
* @param v
*            Map的value的class，集合list元素的类型
* @param keyName
*            集合元素唯一字段的名称
* @param list
*            集合元素
* @return map
*/
//这种方式，废弃了，需要多传2个参数
public static <K, V> Map<K, V> listToMap(Class<K> k, Class<V> v,
String keyName, List<V> list) {
Map<K, V> map = Maps.newHashMap();
if (CollectionUtils.isNotEmpty(list)) {
for (V val : list) {
try {
PropertyDescriptor pd = new PropertyDescriptor(keyName, v);
Method getMethod = pd.getReadMethod();// 获得get方法
Object o = getMethod.invoke(val);// 执行get方法返回一个Object
if (o != null && o.getClass().equals(k)) {
map.put((K) o, val);
}
} catch (IllegalAccessException | IllegalArgumentException
| InvocationTargetException | IntrospectionException e) {
e.printStackTrace();
}

}
}
return map;
}

7.函数拆分 1个函数，有5个参数，有2种不同的使用场景。 同一个函数完成了2件不同的事情。 void add(int a,int b,int c); 换成 void addOrder(int a,int b); void addProduct(int c)。 8.函数合并 2个函数，完成了类似的事情，简化成1个，
函数是拆分，还是合并，要具体分析。 9.单一职责原则 一个项目、一个模块、一个类、一个函数，完成一件事。 如果完成了多件事，需要进行拆分成多个独立的函数，至少内部需要进行拆分。 比如： void add(int a,int b,int c) 可以拆分成 void add1(int a,int b)和void add2(int c) 也可以拆分成 void add(int a,int b,int c){ add1(a,b); add2(c); }
10.控制类和函数的行数 一个类，如果函数太多，往往是承载了太多的功能。 把不紧密相关的功能，堆积在了一起。 一个方法，如果代码超过了100行，存在问题的可能性就增大了很多。 在我自身的经历中，很多同事的函数，只要超过100行，一眼望去就能发现问题。 另外，函数代码过多，修改bug和新增业务逻辑的时候，很容易引入新的问题。 因此，函数拆分、降低作用域，可以保证过去稳定的代码逻辑，不会有改动。 11.提前返回 先检查错误，如果有问题，直接返回，以免嵌套过深。

public String add(){
Member member = this.getMember();
if(StringUtils.isBlank(...){
return error("地址信息有误！");
}
}

经常出现下面的情况 if(...){ if(...){ if(...){ } ｝ } return ...; 12.定义枚举 枚举是常量的进一步封装。

public enum OrderPayStatusEnum {
NO("0", "未支付"), YES("1", "已支付");

private String code;
private String remark;

OrderPayStatusEnum(String code, String remark) {
this.code = code;
this.remark = remark;
}

public String getCode() {
return code;
}

public void setCode(String code) {
this.code = code;
}

public String getRemark() {
return remark;
}

public void setRemark(String remark) {
this.remark = remark;
}

public static String getPayStatus(String code){
if(StringUtils.isEmpty(code)){
return null;
}
if(code.equals(NO.getCode())){
return NO.getRemark();
}else if(code.equals(YES.getCode())){
return YES.getRemark();
}
return null;
}
}

13.统一API交互接口 后端和移动端，后端和Web前端的交互，都是Result的json字符串。 后端，所有请求，统一都是返回Result。public class Result { private Integer code; private String desc; private Object data;} 多人开发的时候，如果没有架构师之类的角色，各自为战，真是乱套。
14.模块化和依赖 大多数项目，都会有诸如邮件、短信验证码、登录服务、图片云服务等。 把配置文件单独拿出来，可以手动通过Spring的配置文件，配置bean。 如果需要，引入配置文件，不引入，代码也不会报错。 spring-mail-config.xml

<context:property-placeholder location="file:${config_path}/config/mail.properties" ignore-unresolvable="true" />
<bean id="javaMailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
<property name="host" value="${mailServerHost}" />
<property name="port" value="${mailServerPort}" />
<property name="javaMailProperties">
<props>
<prop key="mail.smtp.auth">true</prop>
<prop key="mail.smtp.timeout">25000</prop>
</props>
</property>
<!-- 发送者用户名 -->
<property name="username" value="${mailUserName}" />
<!-- 发送者密码 -->
<property name="password" value="${mailPassword}" />
<property name="defaultEncoding" value="UTF-8" />
</bean>

<bean id="mailClientServer" class="com.shop.common.mail.MailClientServer">
<property name="javaMailSender" ref="javaMailSender" />
<property name="configuration" ref="freeMarkerConfigurationFactory" />
<property name="mailFromAddress" value="${mailFromAddress}" />
</bean>

还比如，咱们的图片用的阿里云的OSS。 统一封装。 配置文件 oss.properties oss.xml

<context:property-placeholder
location="file:${config_path}/config/oss.properties"
ignore-unresolvable="true" />
<bean id="ossConfig" class="com.shop.common.oss.OssConfig">
<property name="endpoint" value="${oss.endpoint}" />
<property name="bucketName" value="${oss.bucketName}" />
<property name="accessKeyId" value="${oss.accessKeyId}" />
<property name="accessKeySecret" value="${oss.accessKeySecret}" />
<property name="imgDomain" value="${oss.imgDomain}" />
<property name="fileDomain" value="${oss.fileDomain}" />
</bean>

Java代码 public class OssUtil {} 15.代码复用 代码复用，是一个广泛的话题。 前文提到的枚举、常量、函数拆分，目的之一就是为了方便代码复用。 一个优秀的程序员，抵得上十个差的程序员，其中一个原因就是“代码复用多”。 总是写重复的代码，把程序员这个智力密集型工作，干成了体力密集型，早晚被累死。 梳理业务需求、做好业务方面的架构设计。 另外，技术方面的架构设计，完全掌握在技术人员手中，对业务的依赖不大。 开发一个功能时，先想好思路，技术方案，再写代码。 架构复用、设计复用、工具类、枚举、常量。 另外还有一种，非常常见的，流程复用。 前端系统： 1.构造url和参数 2.执行请求，获得数据 3.根据状态码，执行不同的操作 4.正常状态，渲染数据，或执行动作 移动端： 流程类似 后端： 1.稳定并且统一的API接口 2.业务逻辑封装 无论内部怎么变，接口稳定，就不会影响Web前端和移动端。 在合适的时机，内部项目拆分，项目服务化。
重构的技巧，还是有很多的，更多还是看个人对编程的理解。 对于有经验的程序员来说，《重构》是一本不错的书，可以用来快速加深平时对项目代码的梳理。 对于新手来说，《重构》和设计模式，这种书，受益偏小。
小雷-一个有独立见解的年轻人
2016年4月16日~清明节刚过，五一又要来了
湖北-武汉~听说最近有几条公交专线要开通了

最近，有好多好多的想法和话题要写，时间不太够。
更准确来说， 时间是有的，写文章，也要看心情。
写一篇严肃一点的长篇大论，一般都需要1小时以上。
在写作之前，大脑里面一直在不断地“打草稿”，写的过程中，需要不断发散，要有条理，还要严谨，站得住脚。

一些问题的根源，也许是我的身价还是太低了，更多时间忙着搞钱，一些有价值的事情，只能慢慢地去做。