高效、稳定开发功能的一些心得

在开始编码前一定要足够了解案子，了解各种特殊情况，和美术、策划、服务器沟通好，最后写好伪代码。

一些建议

1.尽量复用，例如重复的对象单独抽出来做成item，别的模块也用到的做成通用item，不要写重复代码。

2.做功能前先考虑别人会不会用到，用到可能是什么情况，也可以询问策划，例如下面这个界面有7个业务用到，每个业务的需求都不太一样。做的时候可以先考虑进去。不然后面大概率还是在你的界面做修改，还得反工。

3.能配置的尽量走配置，特别是一些细微的差别，这个很重要。就比如上面的界面可以这么配置

DungeonsDefine.BattleType = enum
{
    ARMY_DETAIL       = 1, -- 军团详情
    SLG               = 2, -- 出征军团
    FORMATION       = 3, -- slg校场编队

    GUARD_WALL      = 4, -- 守城
    RPG_MONSTER       = 5, -- RPG战斗魔物

    RPG_DUNGEONS       = 6, -- RPG战斗,副本
    RPG_ARENA       = 7, -- RPG战斗竞技场
    ARMY_MONSTER_DETAIL       = 8, -- 猎魔军团详情
}

local BattleType = DungeonsDefine.BattleType
--isRpg:是否是rpg类型，  rpg:显示英雄技能、英雄类型  slg:显示英雄军团技能，带兵量
--isShowAdd:格子为空时是否显示加号， true:显示
--isSizerState:是否筛选英雄状态， true:正常状态排在前，出征英雄排在后
--canSelectOutManor:是否可以选择不再城内英雄 true:可以（isSizerState 为true时才有用到）
--isShowState：HeroFormationItem是否显示英雄状态图标  true:显示
--isNotFullTips：自定义英雄结束时，出战英雄未满是否需要提示， true:提示 您还可以选择更多英雄，确定要继续吗
--autoClose:点确定自动关闭界面，默认关闭

--title:界面标题，默认 自定义英雄
--btnTxt按钮文本，默认 确定
--showHelp  是否显示帮助按钮
DungeonsDefine.BattleConfig = enum
{
    [BattleType.ARMY_DETAIL]     = {isRpg = false, isShowAdd = false, isSizerState = false, canSelectOutManor = true,
                                   isShowState = false, isNotFullTips = false, autoClose = true},
    [BattleType.ARMY_MONSTER_DETAIL]     = {isRpg = true, isShowAdd = false, isSizerState = false, canSelectOutManor = true,
                                           isShowState = false, isNotFullTips = false, autoClose = true},
    [BattleType.SLG]             = {isRpg = false, isShowAdd = true, isSizerState = true, canSelectOutManor = false,
                                   isShowState = true, isNotFullTips = false, autoClose = true},
    [BattleType.FORMATION]         = {isRpg = false, isShowAdd = true, isSizerState = true, canSelectOutManor = true,
                                     isShowState = false, isNotFullTips = false, autoClose = true},

    [BattleType.GUARD_WALL]       = {isRpg = false, isShowAdd = true, isSizerState = true, canSelectOutManor = true,
                                  isShowState = true, isNotFullTips = false, autoClose = true, title = "des_360", btnTxt = "des_618", showHelp = true},
    [BattleType.RPG_MONSTER]       = {isRpg = true, isShowAdd = true, isSizerState = true, canSelectOutManor = false,
                                   isShowState = true, isNotFullTips = true, autoClose = true},

    [BattleType.RPG_DUNGEONS]     = {isRpg = true, isShowAdd = true, isSizerState = true, canSelectOutManor = false,
                                    isShowState = true, isNotFullTips = true, autoClose = false},
    [BattleType.RPG_ARENA]         = {isRpg = true, isShowAdd = true, isSizerState = false, canSelectOutManor = true,
                                     isShowState = false, isNotFullTips = true, autoClose = false},
}

4.每个功能尽量拆分成一小块（每个小块逻辑在30行以内），定位bug比较方便，策划改案子也比较方便实现，只需要改对应的小块就好了。

详细步骤

1.需求案：尽量对比竞品，详细的看3-4遍。

1-1.需要知道这个功能包括哪些界面。

1-2.策划案是否有遗漏（考虑多种情况，例如有道具怎么展示，没有道具怎么展示）。

1-3.比对竞品，询问策划和竞品不一致的地方。

1-4.如果有多语言，提前配置，方便拼界面时直接使用。

2.美术示意图：

2-1.关注多语言是否超框，一般英语比较长。

2-2.比对案子，是否和案子一致，不一致要及时跟策划沟通。是否有一些情况遗漏了。例如锻造时显示进度条，不锻造时显示文本。

2-3.记录需要用到的数据（服务端、配置读取）

2-4.记录所有的界面按钮，知道按钮的反应事件（请求服务器、打开界面、修改界面逻辑如选中状态、调用其他模块如设置），额外关注需要请求服务端的按钮，第四步定协议用得上。

3.比对服务端协议。例如

3-1.初始化需要数据，例如主界面的小红点。

3-2.需要同步的数据，例如平叛会导致英雄状态、经验值、等级变化，那么都需要同步给英雄模块。

3-3.请求类，基本都是按钮触发，关注请求需要的数据，服务端需要返回的数据。

4.拼界面，经过上面三步，基本案子就很清楚了。

4-1.拆分界面，尽量拆分的细一点，尽量把重复的对象拆分成一个item，例如AcquiredHeroItem。划分后大概是下面这个样子的。拆分规则为：子界面>子item>方法。

按方法划分是指：每个方法负责一部分界面逻辑（例如替换该部分的图片、文本，设置显示隐藏等等）

4-2.界面适配，主要关注宽高比2：1的，4：3的，示意图的比例三种。

4-2.关注多语言，尽量拉长、拉高文本框，因为英语和阿语都比中文长很多。

导图大概是这样子的：

 5.写数据类（逻辑类）

5-1.接受并保存服务端下发的数据，对外提供获取数据接口，例如

-- 获取已获得英雄
-- containRecruit 是否包含可招募英雄
-- 是否要排序
function HeroCtrl:GetAcquiredHero(containRecruit, sort)
    local heros = {}

    if containRecruit then
        for k,v in pairs(self._recruitData) do
            table.insert(heros, v)
        end
    end

    for k,v in pairs(self._heroData) do
        table.insert(heros, v)
    end

    if sort then
        table.sort(heros, HeroCtrl.SortHeroList)
    end

    return heros
end

5-2.收到服务端数据后更新本地数据，分发相对应的事件通知业务更新界面（消息系统参考：https://www.cnblogs.com/wang-jin-fu/p/11255831.html）

5-3.请求服务端的接口，例如

--请求穿戴战利品
function HeroCtrl:ReqDressBootyo(sort, pos)
    local data = {sort = sort, slotid = pos}
    NetMsg.SendMsg("reqherodressbooty", data)
end

5-4.尽量将相同类型数据单独分装数据类，由该模块的ctrl维护。例如每个英雄生成一个HeroData的数据类，该类对外提供所有业务需要的接口，例如获取服务端数据和配置数据的接口。

5-5.逻辑计算尽量放在数据类里，例如是否显示小红点，计算都在HeroData，业务只要通过返回值设置小红点的显示、隐藏就好了。

--计算小红点
function HeroData:ComputeHint()
    if self.own == HeroOwnState.RECRUIT then
        return true
    end

    local heroCtrl = PlayerTop:GetModule("HeroCtrl")
    if self:CanUpRank() and not heroCtrl:IsUpRank(self:GetHeroSort()) then
        return true
    end

    if self:CanUpQuality() and not heroCtrl:IsUpQuality(self:GetHeroSort()) then
        return true
    end

    for i=1,#self.equip do
        local state = self.equip[i].state
        if state == EquipState.CAN_DRESS or state == EquipState.COMPOSE then
            return true
        end
    end

    return false
end

6.实现界面逻辑

这步就只是单纯的填界面了，需要的数据，数据类的获取接口都写好了。只要调用数据类获取数据（文本内容、图片名字、显示和隐藏），再把获取的数据设置给对象就好了。

 最后，审案子、ui示意图一定要仔细再仔细，以为这个涉及到你后面的定服务端协议、界面拼接。逻辑理清楚了，拆分够小块了（也不能太小块了，方法调用也是要消耗性能的，大概一块的逻辑在10-30行左右），你的程序就不容易出逻辑bug，很更好维护、修改。