过度设计，被教育

       昨天完善创建角色的游戏服务端逻辑。创建角色失败时，服务端要告知客户端具体的错误原因——比如角色名不可用，或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，将不同的错误原因编码成不同的包ID，不再采用错误码。这样创建角色的过程中，遇到不同错误时，就发不同的包。

       不过今天开会时，这样的做法被吐槽了，因为这样的思路比较非常规。一来这样的做法如果在项目中推广开来，则会占用很多的包ID。另外一方面，在这种思路下，客户端要为不同的错误原因单独定义一个包处理函数，客户端的代码也不太好写。对于magic number的问题，因为创建角色的错误码不多，且错误码变动的可能性很小，所以完全在这种情况下完全是可以接受的事情。程序老大教育我：Unix下有一个准则，即KISS，尽量不要为看不见的需求写代码。

       师兄知道这事后拍手叫好，说我活该——他终于翻身了- -。 我的代码洁癖是该改改，太完美主义了，在不要紧的地方花费了太多精力。