本末倒置之规范

Categories: 程序设计
Tags: Java

故事

在一个项目里看到一个奇怪的“规范”。

如果需要用到缓存，必须将这个Service再包一层CacheService。

举一个不符合该“规范”的例子

public class RuleService{
    
    @Cacheable(cacheNames="rules", key="#expr")
    public Rule calcRule(String expr){
        Rule rule = complexCalculate(expr);
        return rule;
    }
}

按该“规范”，你必须要改成

public class RuleService{

    public Rule calcRule(String expr){
        Rule rule = complexCalculate(expr);
        return rule;
    }
}

// 增加一个 cacheService
public class RuleCacheService{

    private RuleService ruleService;
    
    @Cacheable(cacheNames="rules", key="#expr")
    public Rule calcRule(String expr){
        return ruleService.calcRule(expr);
    }
}

我真的是百思不得其解。问，为什么要这样做？

答，统一、规范、方便管理。

观点

我真的是麻了。

这是一个典型的本末倒置的错误。

规范从始至终就不是目标，规范只是手段而已。

我们的目标从来就是建设一个可维护、好维护、易维护的系统。

为了实现这个目标，解决一些特定的问题，我们才去针对性制定了一些规范， 期望通过这些规范去避免那些可预料的问题，或者给我们带来一些额外的好处。

你要统一，你要方便管理？

就上面这个cache的例子，你要管理什么？

以前缓存都是硬编码在业务代码逻辑内，如

public class RuleService{
    
    public Rule calcRule(String expr){
    
        //先试图从cache拿
        if(cache.get(expr) != null){
            return cache.get(expr);
        }
        
        Rule rule = complexCalculate(expr);
        
        // 放到cache
        cache.set(expr, rule);
        
        return rule;
    }
}

大牛们将cache抽离成@Cacheable，让我们可以专注于业务逻辑，不必再关心cache这些技术性问题。

现在他一个“规范”下来，硬是让大家回到了解放前。

理解规范比执行规范更重要

架构师的水平往往决定了一个系统的设计上限（到底能有多好），架构师能力不足就别指望他设计一个很好的系统了。

但是系统的下限（到底能有烂）却是由一线开发的程序员决定的。

就算架构师设计的架构再好，如果架构、规范得不到落地，系统最终也会变成一坨屎。

但是，执行规范的前提是大家能理解规范。

这个规范为什么要这样子设计？它解决了什么问题？带来了什么好处？如果不这样做会有什么问题或麻烦？

如果这些问题不回答好，一些初级成员可能并不理解这些规范，甚至不一定认可这些规范。

不理解或理解错了的话，可能就会写出一些似是而非的代码来。

不认可的话，可能就会偷偷按自己想法来，就赌你代码review时漏了没发现。

给开发人员说清楚规范的背景、目的、作用是件一举多得的事。

在讨论规范的过程中，互相印证，你这样设计是考虑了哪些场景？如果是我设计我会怎样处理？

大家的差异在哪？是你思考漏了还是我漏了？

在各种观点的碰撞中，大家都能得到提高。

当然，规范也用不着事无巨细都拿来讨论，共同制定。

毕竟，除非你定的规范太辣眼睛，不然的话大家也是没有动力推翻一个70分的规范重新制定一个80分的。

如果你觉得本文对你有帮助或不错，可略表心意，请我喝一杯冰可乐。 ☕

Comments