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

               
大部分的公司,开发项目都是作坊式的,没有产品和项目的需求分析,进而做出技术架构和详细设计。
很多人,听到上级和老板的一个想法,就开始写代码,边写边改,甚至推倒重来。

最终,导致的常见结果之一,项目代码混乱,新员工甚至老员工,对项目理解比较吃力。
如果你去改造代码,改好了,没有任何功劳。改出问题了,领导、测试、产品,很可能会说你不行。
这一点,是让很多程序员纠结的地方。

我个人还是倾向重构的,先熟悉项目总体环境,从易到难。
项目开发,从外部看,就是一个个的功能。
从内部看,不就是一个个函数和API吗。
只要输入和输出是稳定的,就不会出现重大的失误,导致牵一发动全身的不良后果。

下面记录一些,我个人自己揣摩的一些重构方法,阅读《重构》这本书,也带给了我一些启发。

1.命名规范化
  包名、类名、方法名、变量名,取合适的英文单词。
  比如在一个电商项目中。
  包名:com.company.shop.front.controller,前端系统的控制层
  类名:OrderController,处理订单的控制器
  方法名:findById,根据id查找对象,我个人更喜欢用get。
  变量名:List memberIdList = new ArrayList();
   会员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 dictionaryMap = BizUtil.listToMap("BIANMA", dictionarys);  * @param keyName 集合元素唯一字段的名称  * @param list 集合元素  * @return map  */ public static  Map listToMap(final String keyName, List list) {  if(CollectionUtils.isEmpty(list)){   return null;  }  return Maps.uniqueIndex(list, new Function() {   @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 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  Map listToMap(Class k, Class v,   String keyName, List list) {  Map 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">trueprop>    <prop key="mail.smtp.timeout">25000prop>   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小时以上。
在写作之前,大脑里面一直在不断地“打草稿”,写的过程中,需要不断发散,要有条理,还要严谨,站得住脚。

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

再分享一下我老师大神的人工智能教程吧。零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到我们人工智能的队伍中来!https://blog.csdn.net/jiangjunshow

你可能感兴趣的:(大学毕业4年-回顾和总结 6 -技术研发-重构之法)