代码诊所的第二次诊断

几年前，我有机会负责一个项目的咨询。团队很小，目标是对旧有系统的后端用Java改写，而团队的开发人员全为C程序员。我的工作职责是负责项目设计、开发，以及担任项目开发过程敏捷化的教练，并培养Java开发人员。

创新互联公司专注于成都网站建设、网站建设、网页设计、网站制作、网站开发。公司秉持“客户至上,用心服务”的宗旨,从客户的利益和观点出发,让客户在网络营销中找到自己的驻足之地。尊重和关怀每一位客户，用严谨的态度对待客户，用专业的服务创造价值，成为客户值得信赖的朋友，为客户解除后顾之忧。

我在团队工作室的墙角落，开了一个小小的诊所，广而告之——“每日一贴，包治百病”。这是当时我在项目上的第二次诊断。

1. 变量的声明应尽量与使用放在一起

本规则与代码的可读性有关，倘若方法还没有保持短小，这个问题就更要命。或许这是C语言开发者容易犯的毛病。当然也有许多Java程序员从前辈程序员处继承了这一陋习。我曾经在一个遗留项目中看到过一个长达几千行的Java方法，在方法头部堆砌了数十个变量定义，让人目不暇给!

除了影响代码的可读性之外，还可能导致隐藏的缺陷。很多程序员之所以习惯在一开始就声明变量，就是将这种局部变量当做了存储中间状态的容器，在方法内部反复使用该变量，这种中间结果的变迁未必符合开发者意图，又或者后来的代码维护者没有理清这种变化，从而做出变量值的误判。

2. 对常量和枚举的使用

本规则本不足道，写在这里，为了进一步惊醒一下团队成员。在咨询过程中，我看到有这段代码：

 
 
 

  
  
  
Integer.parseInt(freeFlash, 16);
 
 
 

这个16，究竟是什么鬼?Magic Number，很多时候会让人感到困惑。

在JDK没有提供枚举之前，很多Java程序员喜欢使用接口类型来包装一大堆常量。如果常量存在内聚的分类意义，还是使用枚举为佳。

3. 进行合理封装，避免方法调用顺序错误

封装是非常有必要的。有时候，暴露太多的细节会让调用者感到无可适从。

对于TelnetService类，我们需要依序调用connect()、login()、enterUShell()，然后在执行命令后，必须依序执行exitUShell()，disconnect()。这让我想起事务处理，FTP访问等与资源有关的逻辑，都需要在执行逻辑前后包裹一些基础设施的处理逻辑。为了避免在执行命令前后忘记连接或断开telnet，***能将此过程封装。

这是从调用安全性来考虑。

如果从调用的简洁性考虑，封装亦有必要。当我们需要通过TelnetService发送telnet命令时，为何还需要了解内部的执行逻辑呢?

那么，该如何封装才能两全其美，既满足对执行逻辑顺序的重用，又满足对命令逻辑的扩展?

通常做法是将真正的执行逻辑提取为接口，如Java中Runnable的方式。这其实可以看作Command模式的运用。当然，我更愿意看做是对函数的封装，例如Guva中的tranform()、filter()之类的方法，接受更具有函数气质的Function或者Predicate接口(当时，Java 8还未问世呢)。

因此，我的做法如下：

 
 
 

  
  
  
public class TelnetService {
  
  
  
    public T withCommand(ExecutionCommand command) {
  
  
  
        connect();
  
  
  
        login();
  
  
  
        enterUShell();
  
  
  
        T result = command.send();
  
  
  
        exitUShell();
  
  
  
        disconnect();
  
  
  
        return result;
  
  
  
    }
  
  
  
}
 
 
 

可以这样调用：

 
 
 

  
  
  
String result = telnetService.withCommand(new ExecutionCommand() {
  
  
  
        @Override
  
  
  
        public String send() {
  
  
  
            return telnetService.transfer();
  
  
  
        }
  
  
  
    }
  
  
  
);
 
 
 

4. 遵循异常处理的架构规则

团队成员对异常极为陌生，面对java的受控异常、非受控异常，不知如何选择;也不知道该何时捕获异常，何时抛出异常。因而我针对该项目确定了异常处理的架构原则，其目的是为了让整个架构变得更简单，让异常处理更加一致。

我的目的是减轻开发人员的负担，但同时又不降低代码质量，并利于未来对代码的维护。规则如下：

• 同层之间的调用不做try-catch，上层调用下层的对象，必须try-catch。即使对象抛出了异常，只要不是checked exception(我们尽量避免使用checked exception，以避免它对接口的污染)，就无需考虑去捕获这个异常。这样的设计并不会导致异常泄露，因为我们要求在上一层捕获。至于最顶端的Application Layer，则只做捕获异常的事儿，不干抛异常的活儿。
• 为各层(即领域层和基础设施层)定义各自的异常超类。其中，领域层定义的异常要求提供Error Code。Error Code并非我所愿，但对于本系统的上游系统，却需要该值，不得不为。
• 领域层。若是结合实际情况由自己抛出异常，则只需考虑异常消息和错误码;若是捕获了异常再抛出，则在捕获时记录日志，再度抛出的异常需要包裹原始异常对象。

在代码诊所中诊断出来的疾病，可以作为代码评审的一个标准，同时这些处方则可以当做团队内部分享与交流的知识库。长期累积下来，非常有利于团队成员编码能力的成长。

【本文为专栏作者“张逸”原创稿件，转载请联系原作者】

当前题目：代码诊所的第二次诊断
网站路径：http://www.shufengxianlan.com/qtweb/news4/408954.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联