Posted on 2008-01-02 02:43
Fox 阅读(765)
评论(6) 编辑 收藏 引用 所属分类:
G游戏编程
Author: Fox
元旦放假3天，本来想把前面写的一个存在线程安全隐患的模块推倒重来的，可是改着改着就觉得不对劲了。
既然是返工，就想尽量把现在的理解完全加进去，让后面的人看了不要骂。可是想把几千行的代码改得面目全非并且更加安全准确也并不是一件容易的事，虽然对于功能和逻辑的认识比以前要清晰的多。
拿到一个新的模块，上面一般会给个大致的deadline。除非你对这个模块和整个项目的依赖关系（接口、逻辑、功能）有很好的把握，否则，你根本不知道到底有多少东西是已经实现的，有多少东西是可以复用的，有多少东西是需要修改的，有多少东西是要重写的，有多少东西是要新加的，仅仅根据需求预估的进度是不可能恰到好处的。而脱离了整个项目实现的模块是非常可能出问题的，尤其是在使用多线程的项目中。
当我的这个模块完成并上马之后，我沾沾自喜的跟上面说，应该是不会有问题了，上面跟我说了一句：如果不出问题就是奇迹了，我当时颇不以为然。在后面一两周之内真的就是没有什么问题，我真想告诉他是我创造了奇迹。
“奇迹”在2007年的最后一周破灭了。在我从西岭雪山回来的那天，为了增加新功能把代码修改了一些，结果第二天更新之后，服务器就老是有问题，找了一下午，才发现在修改代码的时候居然忘记对一个pointer做NULL判定！我心想，这种错误居然都出来了！死了算了！而且这个问题出在非主线程中。然后就和同事在考虑，这个东西如果线程同步出现问题，你就是每次使用前都做NULL判定也没用，所以就决定把这个模块重写了。
在这儿我就不想就线程安全问题多说了，以后想好了再专门去写点多线程的东西吧，今天只是想说点琐碎的东西。
因为是放假，心思未必就全部放在上面了，代码没改多少，倒是玩了很长时间的游戏。后来想想，也不全是时间问题，几千行的代码改来改去，难保不出现更多的问题。必须把它当作一个新的模块去写，先要把逻辑结构完全理出来，能多细化就多细化，最好能够精确到变量的使用，而且把文档做细，这样就可以在写文档的过程中把问题尽可能想全想清楚。改代码先改文档，这几乎是所有学过软件工程并写过项目的同学都能认识并理解的常识，可是在实际工作中，上有任务催赶，下有闲心杂念，很难把文档和注释写好。而做不到这一点的话，你就不敢保证你的模块不出差错。
所以，对于一个一般的需求，如果deadline是2个月的话。读需求、评估依赖关系、量进度要花掉1周，画逻辑结构、写文档要花掉3周，相当于前面一半的时间没有动手写代码，然后写代码大概只用1周，甚至更少，其他时间就留给测试和修改文档、代码了。从软件工程的角度，这样的分配是合理的，而且是应该的，但到了实际项目里面，又做不到！看来，不管是manager，还是coder，都不能急，软件工程不能白学了。
我发现，我的软件工程就是白学了，以后得改改。
/*****************************************************************************
不想回头去动以前的代码，每次看以前写过的东西，都有一种想把它彻底删除的冲动。
把需求看好、文档写好、时间安排好，这才是硬道理……
毕竟是新年，还是祝大家：新年快乐！
重要的是，新的一年，别荒废了……
*****************************************************************************/