这是一个创建于 3383 天前的主题，其中的信息可能已经有所发展或是发生改变。
受朋友委托，然后跟另一个朋友一起开发的，
一起开发的这个，之前 2 年没联系，
结果 ........
看完我一句也不想说
第 1 条附言 · 2015-08-19 23:05:15 +08:00
他的多种命名方式，强迫症表示受不了。。。还有 buxue ()之类....
有一个 class 里面全是第二张图里面大片这种雷同 method ，就是改了改 magic number...
我仿佛看到了他无数次的 copy paste
并且每个 method 也带个 hwnd 参数.. 如果是为了方法灵活性 可重用，也完全没用。。
因为需要操作的游戏句柄只有一个，调用的 Click ()里也写死了的
ORZ 其实好像是我要求高了点
有一个 class 里面全是第二张图里面大片这种雷同 method ，就是改了改 magic number...
我仿佛看到了他无数次的 copy paste
并且每个 method 也带个 hwnd 参数.. 如果是为了方法灵活性 可重用，也完全没用。。
因为需要操作的游戏句柄只有一个，调用的 Click ()里也写死了的
ORZ 其实好像是我要求高了点
第 2 条附言 · 2015-08-20 14:31:42 +08:00
又被顶上来了
我只是吐槽+问问 V2 各位怎么解决这种情况，绝无任何秀优越
如觉不适，请立即关掉此贴
第 3 条附言 · 2016-01-28 02:33:57 +08:00
快半年了啊。。。写一下反思，不知道有没有人看得见
其实怪我当初没沟通好。
我的想法是做一个类似于基础框架平台的东西，在此基础上用 lua 类似的脚本进行扩展
而他直截了当地写完了逻辑，而且灵活性不是很好。几乎不修改不能用作其他用途
so ，团队内部务必及时做好沟通
而且我当时有些过度提前优化的倾向
这里推荐一篇文章《克服编程直觉》 http://www.tuicool.com/m/articles/ZV7Zzq
其实怪我当初没沟通好。
我的想法是做一个类似于基础框架平台的东西，在此基础上用 lua 类似的脚本进行扩展
而他直截了当地写完了逻辑，而且灵活性不是很好。几乎不修改不能用作其他用途
so ，团队内部务必及时做好沟通
而且我当时有些过度提前优化的倾向
这里推荐一篇文章《克服编程直觉》 http://www.tuicool.com/m/articles/ZV7Zzq
104 条回复 • 2015-10-20 21:53:43 +08:00
 |
102
mzer0 2015-10-20 21:34:50 +08:00
@tchekai704 用 C++举一个例子. 例如, 一个 2D 游戏中的人物朝向可以被描述为一个集合
{up, left, right, down} |
|
103
mzer0 2015-10-20 21:46:19 +08:00
@tchekai704 例如, 一个 2D 游戏中的人物朝向(towards)可以被描述为一个集合{up, left, right, down}, 常见的处理手法为:
if(up == towards) {} else if(left == towards) {} else if(right == towards) {} else if(down == towards) {} else {} 如果用结构体来优化: class towards_handle { enum {up, left, right, down} towards; void handle(void) { /* do something */ } }; 每个角色都拥有一个 towards_handle 对象, 它的 towards 值必然为{up, left, right, down}其中之一. towards_handle th; th.towards = 1; // 1 means up th.handle(); 这样的过程就比 if-else 漂亮许多, 并且可以用派生类来做相应的优化. |
|
104
mzer0 2015-10-20 21:53:43 +08:00
@tchekai704 在 C++中, 还可以通过抽象类与函数容器来实现跳转表(map), 这是对 if-else 的进一步优化, 因为可以在抽象类中方便地设置日志记录器, 或者 bug 记录器, 这是游戏编程中非常有用的技术. 非算法类的代码中不应该出现多层嵌套 if-else, 也不应该出现连续的 if-else 和 switch, 因为这会把逻辑弄得很复杂, 相反, 应该"分治", 将逻辑分离.
|
Select Language