可读代码编写炸鸡九 - 抽取子问题

 关注
发布于: 2020 年 07 月 20 日
大家好，我是多选参数的一员 —— 大炮。
原本想专门写个第三层的简介，但篇幅过短，也不会多少人看，就在本篇炸鸡简略提一下，然后便进入第三层的第一篇炸鸡就好。
我们回顾一下，可读代码编写第二层主要是讲了 代码逻辑 上的优化。
第三层便是更大的范围了，是关于代码组织，可以说是函数级别的代码组织优化。
﻿
其实第三层还是可以分成两个部分：
当你面对已经出现的不好代码该咋办
在你写代码前如何尽量避免不好代码
废话不多说，先上一个第三层的概览导图：
后台回复 「第三层」获取源文件
所以本篇炸鸡从 抽取不相关的子问题 这一点入手可读代码编写。
写在前头对于代码的编写，大事化小，小事化了。模块化是我们很需要的一个思想。
本篇炸鸡主要是讲 提取无关的子问题。
公众号后台回复 「抽取」获得源 pdf 文件
为了达成这个目标，来个自问三连。
看一下整个代码块或者一个函数，问一下自己，这个代码的 最终目的 是什么？
对于代码的每一行，问一下自己，这样对这个目标有 直接作用 吗。还是这代码用于解决其他的不相关的子问题。
如果解决不相关的子问题的代码开始变多，问一下自己，是不是需要提取，封装为函数。
本炸鸡主要关注：不相关的子问题的提取。所以本炸鸡需要提供不同条件下的例子，来阐述提取的技术。
而这个不相关的子问题，并不是和代码目的毫无干系的代码块，而是 篇幅过大，但解决的问题只是很小一部分 的代码块。
芜湖，如何抽取首先要抽取不相关的子问题之前，得知道啥是不相关的子问题？
可以参考在上文的自问三连中的第一问：
这个代码的最终目的是什么
也就是与最终目的相关性不高的代码，都可以算作不相关的子问题，是附着代码。
我们看一段代码：
function wananDoA()
    -- do something about a
    ...
    -- do something about b
    ...
    ...
    ...
    ...
    ...
    -- do something about c
    ...
    ...
    ...
    ...
    ...
    
    -- do something about a
    ...
end
我用了一个比较抽象的代码，这段代码目标是 wananDoA，也就是做 A 相关的事情，但是函数里充斥着大量的解决其他子问题的附着代码 B 和 C。
所以就需要将 B 和 C 相关代码抽取，比如这样：
function wananDoB()
    -- do something about b
    ...
    ...
    ...
    ...
    ...
end
﻿
function wananDoC()
    -- do something about c
    ...
    ...
    ...
    ...
    ...
end
﻿
function wananDoA()
    -- do something about a
    ...
    wananDoB()
    wananDoC()
    -- do something about a
    ...
end
我们可以发现，抽取完的代码整体：
不占用调用函数的篇幅
专注调用函数目标
被抽取代码拥有更好的拓展性，解耦合
其实抽取子问题的核心实现就是这样而已。今天的炸鸡到此结束，谢谢大家。
我开玩笑的兄弟，再接一些具体的抽取方法吧。
工具代码大概各位的项目中都会有一个 「工具人」模块。就是存放一些工具代码，供各开发人员使用。
例如，字符串操作，日期操作等等，这些完全可以抽取为工具代码。
如下代码是游戏跨天要做的事情：
function onDayPass()
    -- 获取玩家数据
    ...
    ...
    
    -- 结算
    ...
    ...
﻿
﻿
    -- 数据落地
    ...
    ...
end
如果再结算的逻辑中，需要判断玩家的活跃时间是否在指定的时间区间内，同时需要知道玩家的最近上线时间与上一次离线时间是否在同一天。
function onDayPass()
    -- 获取玩家数据
    local user = getUser()
    ...
    ...
    
    -- 结算
    ...
    
    -- 指定区间    
    local beg, ending = readActiveIntervalConfig()
    local curTime = os.time()
    if curTime > ending then return false end
    if curTime < beg then return false end
    
    
    -- 上下线时间是否同一天
    local elapse = user.logoutTime - user.loginTime >= 0 and user.logoutTime - user.loginTime or user.loginTime - user.logoutTime
    if elapse > 86400 then
        return false
    end
    if os_date("%j",user.logoutTime ) != os_date("%j",user.loginTime) then
        return false
    end
    ...
    ...
﻿
    -- 数据落地
    ...
    ...
end
很明显，上述代码的结算逻辑中，判断时间区间，是否同一天等一系列逻辑都是 篇幅大，但是解决的问题是很小的 代码逻辑，也是复用性很强的代码，也就是前头说的 实用工具代码。
这些正是 相关性较小的子问题。
我们将其分出来。
-- 当前时间是否在一个区间内
function isInInterval(beg, ending)
    local curTime = os.time()
    if curTime > ending then return false end
    if curTime < beg then return false end
end
﻿
-- 绝对值
function mathAbs(t1, t2)
    return t1 - t2 >= 0 and t1 - t2 or t2 - t1
end
﻿
-- 是否在同一天
function isSameDay(t1, t2)
    if mathAbs(t1, t2) > 86400 then
        return false
    end
    
    if os_date("%j",t1 ) != os_date("%j", t2) then
        return false
    end
    
    return true
end
于是原本的代码被简化为：
function onDayPass()
    -- 获取玩家数据
    local user = getUser()
    ...
    ...
    
    -- 结算
    ...
    -- 指定区间    
    local beg, ending = readActiveIntervalConfig()
    if not isInInterval(beg, ending) then
        return false
    end
    
    -- 上下线时间是否同一天
    if not isSameDay() then
        return false
    end
    ...
    ...
﻿
    -- 数据落地
    ...
    ...
end
芜湖，多了几个工具代码，还缩小了函数篇幅，岂不美哉。
简化已有接口什么是已有接口呢。其实这也有两个情况。
一个是语言层面已有的接口不能适应项目需求，导致一些函数体量得到不必要的增加。
我拿 lua 举例，lua 中只有一个复杂的数据结构叫做 table。table 有相应的 table 库对其操作，但是不存在一个清空操作。如果在一串代码中，我需要清空一个 table，那我得写这样的代码:
for key, _ in pairs(t) do
    t.key = nil
end
所以我还不如对 table 这个库再加一个 clear 方法。
table.clear = function(t)
    for key, _ in pairs(t) do
        t.key = nil
    end
end
还有一种情况，面对现有接口，参数过多的情况：
function interface(uid, aid, params, isSave, ...)
    ...
    ...
    ...
end
针对现有业务功能，完全可以在此接口上再封装一层接口：
function saveInterfaceWithRewardParams(uid, aid, ...)
    local params = {
        id     = 1001,
        type   = 1,
        amount = 3,
    }
    return interface(uid, aid, params, true, ...)
end
所以面对已有的接口，完全可以再进行包装。对于代码可读性来说，还是对调用的方便来说，都是有裨益的。
而且其实在调用方便这一层面，利用函数合适的命名，也是增强了代码的可读性。
不要过分抽取看完前面的内容，最怕的情况是过度抽取。
看一下如下的抽象代码：
function _doA()
    ...
end
﻿
function _doB()
    ...
end
﻿
function _doC()
    ...
end
﻿
function _doD()
    ...
end
﻿
function _doE()
    ...
end
﻿
function wannaDoA()
    _doA()
    _doB()
    _doC()
    _doD()
    _doE()
end
我们可以看到，抽取了多个子问题，反而需要我们不断地跳转查看具体逻辑，反而增加了思想包袱，违背 明确函数目标 的初心。
总结好了，这篇炸鸡算是到结尾了，其实这个炸鸡最关键的就是。
阅读者注意力。
函数的目的。
篇幅。
所以为了使阅读者专注于函数的目的，我们需要将对于目的而言 相关性较小的子问题 抽取出来，变成一个独立的函数，甚至是库。这个取决于这个子问题使用的范围是一个文件，还是一整个项目。
本篇炸鸡基于此，罗列了许多抽取不同子问题的不同情况，但是总而言之，便是合理地将代码块抽取和封装。