自上而下面向能力的编程思想

野性酷女 2022-10-30 11:22 104阅读 0赞

# 前言： #

行业里对码农的描述有很多种抬头：研发、开发、工程师等，我个人觉得描述最准确的应该是“工程师”，因为软件产品的开发本来就是个工程学的问题，只不过软件工程和土木工程的施工过程是正好相反的。土木工程是自下而上，先把地基搞好再一层层往上建设；软件开发是自上而下，先搭建空中楼阁，下面是怎么实现的并不重要。

# 新概念： #

我们都接触过很多编程思路的名词，面向对象、面向过程、面向服务等，其实做为一个软件工程师最应该具备的是“***面向能力编程***”。面向能力编程是软件架构和开发时的一种方法论，只关注自己需要实现的功能，依赖的或者不在自己服务边界的部分是其它部分该实现的问题，只需要写好抽象，至于怎么实现并不关心，我们暂且默认它们应该具备该有的能力。

# 开发步骤： #

## 1 模型设计 ##

模型贯穿整个应用开发全周期，所以要把模型设计放在首位。有什么样的模型基本决定了你能够提供什么样的服务，能解决哪个领域的问题。

## 2 扩展性设计 ##

一个不能扩展的代码那只叫玩具，生命周期会非常的短暂。扩展性需要考虑两个维度和一个复杂度。  
  第一个维度是性能维度，也就是横向扩展，如何设计才能让软件提供更高算力或存储能力的服务。  
  第二个维度是功能维度，也就是纵向扩展，如何在现有模型基础上提供这个领域更深层次的功能。  
  一个复杂度是指两个维度扩展的成本，尽量选用常数阶O(1)的复杂度。

## 3 面向能力编程 ##

以Java开发为例，自上而下面向能力编程的步骤是Restful-->controller-->service-->provider  
  RestFul是整个产品结果性的产出，代表着能提供能提供什么样的能力，整个应用的服务边界在哪里，RestFul决定了controller要定义成什么样子，也就是说controller应该具备什么能力，所以开发controller的过程也就变得有的放矢，成为一个极容易的事情。  
  同样在controller开发过程中业务编辑部份就直接丢给service层去做，controller层决定了要怎么使用service层，也就是说controller层决定了service层的抽象。  
  service层负责业务编辑部份，provider层负责原子操作级别的具体实现，service层本质是就是对provider层的上层编辑与计算，所以service层又再一次决定了应该有哪些provider，每个provider应该具备怎样的能力。  
  所以整个架构过程就变成了这样的模式：永远只面对具体的方法，新写的代码是否应该放在这一层？如果在下一层实现那是否有可以利旧的类或方法？如果没有那需要编写个怎样的抽象？

## 4 provider实现 ##

程序开发到上面第三步其实就已经开发完了，或者说已经成功了，至于provider的具体实现那就是无脑体力活了。例如DBProvider就是做存储用的，接口和方法在编写service阶段都定义好了，至于你想选择用什么样的数据库去存那是impl自己的事情，不影响上层功能。我们曾经有个项目开始用的是redis，后来改成了cassandra，只用了半天换了个provider的impl而已。

内功心法：“***自上而下，能力驱动抽象，最后解决实现***”。  
用这套工程学理论再去架构和开发一个新产品就把复杂问题简单化，从此你会发现写出高质量、零冗余、高可读性代码变成了很easy的事情。

# 纠正习惯： #

很多人写代码总是“我有啥所以我写啥”自下而上的开发过程，这是个大错特错的做法，应该是“我需要啥我抽象啥”。  
  举个例子，在我们的程序设计中需要用到缓存功能，所以你一上手就写了个缓存的抽象类（运气差的话你可能还完成了实现），代码如下：

public interface CacheProvider {
    
        InstanceInfo getInstance(String instanceId);
    
        //当前缓存更新
        void put(InstanceInfo instanceInfo) ;
    
        //剔除
        void remove(String instanceId);
    
        //查询
        List<InstanceInfo> get(InstanceInfoCriteria instanceInfoCriteria);
    
        //查询All
        List<InstanceInfo> getAll();
    
        //带分页查询
        PageInfo<InstanceInfo> getWithPage(InstanceInfoCriteria instanceInfoCriteria);
    
    
    }

但是你程序上层真正用到缓存provider的地方只有一个地方，是这样子的：

if(resourceList!=null && resourceList.size()>0){
            //存入缓存
            cacheProvider.putCache(resourceConfigModel.getResourceKey(),System.currentTimeMillis(),resourceList);
        }

这时你才发现你不仅写了一堆没用的废代码，而且应该实现的能力却没暴漏出来，最关键的是你的service希望缓存的provider要做到物理隔离，用到了桶的概念，需要带时间戳，用到了版本管理的概念，这将让你前面写的这provider全部推到重来。如果按自上而下面向能力的编程，你只需要抽象一个这样的接口：

public interface CacheProvider {
    
        /**
         * @param bucket
         * @param timestamp
         * @param instanceInfo
         */
        void put(String bucket, long timestamp,List<InstanceInfo instanceInfo> instanceInfos) ;
    }