过度设计,被教育

在完善游戏服务端创建角色逻辑时,作者遇到如何优雅地传递错误信息给客户端的问题。原本的错误码方案因涉及magic number而不满意,于是改为通过不同的包ID来表示不同错误,但这一做法在团队讨论中被认为是过度设计,因为它可能占用过多包ID,并增加客户端代码复杂性。最后,程序老大引用KISS原则,提倡避免为不明确的需求编写额外代码,让作者反思过度追求完美的问题。
摘要由CSDN通过智能技术生成

       昨天完善创建角色的游戏服务端逻辑。创建角色失败时,服务端要告知客户端具体的错误原因——比如角色名不可用,或SQL语句错误等。代码中原有的思路是,向客户端发一个ID为CREATE_PLAYER_ERR的包(这个ID是应用层的协议),包内含有具体的错误码,客户端在CREATE_PLAYER_ERR包的处理函数中根据错误码向玩家显示具体的出错消息。


       我们的服务端是由C++和lua编写,客户端则是用C#编写。包的ID写在一份lua文件中,叫msg.lua。项目构建时,会根据msg.lua生成相应的.h和.cs文件,这样C++代码和C#代码就可以直接在代码中书写CREATE_PLAYER_ERR这样的ID,而不用写ID数值这样的magic number。但是像错误码这样的二层协议却没有这样相应的自动生成机制。错误码的ID(如CREATE_PLAYER_NAME_INVALID)只在lua中可用,C++和C#里则只能使用ID的数值,比如 if (errcode == 2)这样。


       我在编码时是很难容忍magic number的,然而又不想大动干戈地为错误码添加自动生成机制。因此就对报错逻辑进行了改动,利用msg.lua,将不同的错误原

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值