从BUG到TASK

　　修杂七杂八的小BUG有一个多月了，最近也感觉渐入佳境。大型网游涵盖的技术面真是非常广。从前端的UI、3D引擎，甚至是脚本编译器，到后端的网络和持久层优化、安全……几乎面面俱到。前几天改一个小BUG，发现是因为客户端和服务端对某个条件进行了重复验证，于是就把服务端的验证删掉了。结果黄金哥告诉我：这么改是不行D，服务端验证是必要的，因为我们要防止外挂；客户端进行验证只是出于性能和玩家体验上的考虑。

 

　　一个多月下来，大约修了40多个BUG，也就是平均一天修一个BUG。最快的时候， 我已经能在几分钟之内查到原因，顺手把BUG修好。随着手头积的BUG越来越少，领导们可能也觉得我基本上手了，于是便给我派了一个TASK——改进原有的组队功能。

 

　　从同事那里得知了原有组队功能代码的大致位置，花了一两天时间读了读，然后又跟策划开了个小会讨论下需求和设计，于是就这么开干了！说实话，真是感觉有点措手不及。一开始策划和美工向我征求意见，问哪种设计在程序上会更易于实现，以及UI资源应该怎样配置，我也没能很好地回答上来——因为我心里根本没谱，根本不知道哪些UI控件、怎样的布局能满足策划的需求，还以为美工会知道应该怎样配置UI。后来继续摸索了一下，才发现其实美工并不需要对控件了解得很清楚。

 

　　首先在布局上，策划和美工只需要设计视觉上的布局，至于控件之间的逻辑关系（通常是父子关系）如何布置，他们是不需要考虑的。其次，至于哪些控件才能满足要求，策划和美工也是不需要那么清楚的。美工只需制作好Style（样式），然后随便挑一种控件放置在编辑器中，以便设计视觉上的UI布局就行了，之后程序员可以将其替换为真正准确的控件。打个比方：有时设计上可能会要求一个UI元素在外观上是个文本编辑框，但在行为（功能）上却是个按钮；这时前半部分的工作就是由美工负责，他会制作一个文本编辑框样式，然后随便挑一个控件（可能是EditBox，甚至可能是个Image）应用这个样式，进行布局上的设计；后半部分的工作就是由程序员负责，我会将美工放置的控件替换为Button，但是样式保持不变。也就是说，美工放置的控件其实只起占位符的作用。这也是合理的——让各个工种能专注在自己真正擅长的领域中。当然了，这种制作方式是基于虚幻引擎的，其它引擎就不清楚了。

 

　　接下来也逐渐有了思路。大部分的工作量还是在客户端，服务端的逻辑应该都已经开发好了——包括查询队员、就位确认、HP和MP有变化时通知客户端，等等。我准备先完成显示功能，然后再做交互功能。能否在期限内完成任务，其实我心里也没底，不过尽力做吧。之前在修BUG阶段做得挺杂的，几乎每个BUG都要花很长时间去查。现在终于有机会能专注在一个模块上了。