Creative Commons License
本Blog采用 知识共享署名-非商业性使用-禁止演绎 3.0 Unported许可协议 进行许可。 —— Fox <游戏人生>

游戏人生

游戏人生 != ( 人生 == 游戏 )
站点迁移至:http://www.yulefox.com。请订阅本博的朋友将RSS修改为http://feeds.feedburner.com/yulefox
posts - 62, comments - 508, trackbacks - 0, articles - 7

调整思路——2008年继续努力

Posted on 2008-01-02 02:43 Fox 阅读(708) 评论(6)  编辑 收藏 引用 所属分类: G游戏编程

Author: Fox

元旦放假3天,本来想把前面写的一个存在线程安全隐患的模块推倒重来的,可是改着改着就觉得不对劲了。

既然是返工,就想尽量把现在的理解完全加进去,让后面的人看了不要骂。可是想把几千行的代码改得面目全非并且更加安全准确也并不是一件容易的事,虽然对于功能和逻辑的认识比以前要清晰的多。

拿到一个新的模块,上面一般会给个大致的deadline。除非你对这个模块和整个项目的依赖关系(接口、逻辑、功能)有很好的把握,否则,你根本不知道到底有多少东西是已经实现的,有多少东西是可以复用的,有多少东西是需要修改的,有多少东西是要重写的,有多少东西是要新加的,仅仅根据需求预估的进度是不可能恰到好处的。而脱离了整个项目实现的模块是非常可能出问题的,尤其是在使用多线程的项目中。

当我的这个模块完成并上马之后,我沾沾自喜的跟上面说,应该是不会有问题了,上面跟我说了一句:如果不出问题就是奇迹了,我当时颇不以为然。在后面一两周之内真的就是没有什么问题,我真想告诉他是我创造了奇迹。

“奇迹”在2007年的最后一周破灭了。在我从西岭雪山回来的那天,为了增加新功能把代码修改了一些,结果第二天更新之后,服务器就老是有问题,找了一下午,才发现在修改代码的时候居然忘记对一个pointer做NULL判定!我心想,这种错误居然都出来了!死了算了!而且这个问题出在非主线程中。然后就和同事在考虑,这个东西如果线程同步出现问题,你就是每次使用前都做NULL判定也没用,所以就决定把这个模块重写了。

在这儿我就不想就线程安全问题多说了,以后想好了再专门去写点多线程的东西吧,今天只是想说点琐碎的东西。

因为是放假,心思未必就全部放在上面了,代码没改多少,倒是玩了很长时间的游戏。后来想想,也不全是时间问题,几千行的代码改来改去,难保不出现更多的问题。必须把它当作一个新的模块去写,先要把逻辑结构完全理出来,能多细化就多细化,最好能够精确到变量的使用,而且把文档做细,这样就可以在写文档的过程中把问题尽可能想全想清楚。改代码先改文档,这几乎是所有学过软件工程并写过项目的同学都能认识并理解的常识,可是在实际工作中,上有任务催赶,下有闲心杂念,很难把文档和注释写好。而做不到这一点的话,你就不敢保证你的模块不出差错。

所以,对于一个一般的需求,如果deadline是2个月的话。读需求、评估依赖关系、量进度要花掉1周,画逻辑结构、写文档要花掉3周,相当于前面一半的时间没有动手写代码,然后写代码大概只用1周,甚至更少,其他时间就留给测试和修改文档、代码了。从软件工程的角度,这样的分配是合理的,而且是应该的,但到了实际项目里面,又做不到!看来,不管是manager,还是coder,都不能急,软件工程不能白学了。

我发现,我的软件工程就是白学了,以后得改改。

/*****************************************************************************
 不想回头去动以前的代码,每次看以前写过的东西,都有一种想把它彻底删除的冲动。
 把需求看好、文档写好、时间安排好,这才是硬道理……

 毕竟是新年,还是祝大家:新年快乐!
 重要的是,新的一年,别荒废了……
*****************************************************************************/

Feedback

# re: 调整思路——2008年继续努力  回复  更多评论   

2008-01-02 11:45 by eXile
这个问题, 称之为重构.
在没有单元测试的保证下, 进行重构是一种危险的行为. 正如你说的一样, 要指望不出问题, 那是奇迹. 这也不能怪软件工程没学好, 因为我们学的软件工程本身就是有缺陷的.

"把需求看好、文档写好、时间安排好,这才是硬道理…… "
这是不对的, 设计的唯一不变的特点就是: 它总是在变化.
--是不是有点有饶口 :) , 这是<<设计模式Head First>>中的一句话.
所以我们做的, 是如何应对变化.
推荐看一下: <<重构,改善既有代码的设计>>



# re: 调整思路——2008年继续努力  回复  更多评论   

2008-01-02 12:41 by Fox
@eXile
呵呵,谢谢!
设计模式、重构、重构与模式,我都看过,只是在实际工作中很多东西被我们自己打了折扣……而且,上面的东西,看看开阔开阔思路还是好的。
设计总在变化这句话我也依稀有点印象,但不变的东西更多,你总不能让玩家今天这样做明天那样做啊……

# re: 调整思路——2008年继续努力  回复  更多评论   

2008-01-02 13:52 by eXile
我觉得, 好象你理解的设计总在变化这句话有偏差, 设计变化的原因主要有两点:
1) 需求的变化, 主要是系统功能的改进, 扩充, 版本的升级
2) 需求的细化, 主要是需求本身不会考虑到所有的实现细节, 在实现时才发现有设计不当的地方.

# re: 调整思路——2008年继续努力  回复  更多评论   

2008-01-02 14:01 by eXile
另外, 保证你的模块不出差错, 不是靠文档和注释, 而是靠测试,
文档和注释,也分两种, 一种是给自己看的, 一种是给别人看的, 这两种写法是不一样的,
对于写给自己看的文档, 如果会影响开发进度的话,为什么要写它呢?这说明写文档的方法不对.

# re: 调整思路——2008年继续努力  回复  更多评论   

2008-01-02 18:06 by Fox
@eXile
有道理~~~文档写起来痛苦啊~~~~~
还是要适当的写点,适合自己吧

# re: 调整思路——2008年继续努力  回复  更多评论   

2008-01-05 17:06 by fallhunter
从二位的讨论中受益,感谢~~

只有注册用户登录后才能发表评论。
【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理