终于有了间茅草棚

——我走时,会否有随风飘散的痕迹?

外面的风好大,雨也淅淅沥沥的。

世间种种的诱惑不惊不扰我清梦,山高路远不绝我追踪你绝美的笑容,登高一呼时才懂始终在为你心痛,俯首对花影摇动都是东风在捉弄

世间种种的迷惑都是因你而猜错,水光月光又交融描述这朗朗的夜空,生死到头的相从似狂花落叶般从容,当一切泯灭如梦就在远山被绝
随笔 - 42, 文章 - 2, 评论 - 269, 引用 - 3

导航

<2010年3月>
28123456
78910111213
14151617181920
21222324252627
28293031123
45678910

留言簿(10)

随笔档案

文章档案

收藏夹

其它的我

友情连接

网页连接

搜索

最新评论

  • 1. re: 陈刚
  • 中间件主要的好处在于便于整合,就像一个接口规范和标准。像游戏开发中3D图形技术有两套,有的游戏直接基于D3D或OenGL开发,现在更多的是基于一些图形引擎,像Ogre,Irrlicht等,在这些图形引擎下面去和具体的图形API打交道,从这个意义上来说Ogre和Irrlicht拥有一定的中间件的涵义(这些图形引擎不只是中间层,还包含有场景管理、渲染逻辑等更多内容)。加了这样一层后,当支持新的D3D10和D3D11时,中间层作出修改,原应用不需要修改就可运行,还有移植到支持OpenGLES的设备时,也是可行的。
  • --清风雨
  • 2. re: linux常见开发问题,.JPEG parameter struct mismatch
  • 你说的3.JPEG parameter struct mismatch没看明白,我现在也遇到了同样的问题,
    ”编译libjpeg的make文件里定位输出生成jpeg的地方“指的是哪啊,
    “打印出相关参数”也不明白
    “前台运行同样的./configure”什么意思?
    帮帮我了,谢谢!我邮箱litao_hao@16.com   qq;40362095
  • --haolitao
  • 3. re: linux移植建议
  • 这个学习了
  • --陈刚
  • 4. re: 软件开发模式猜测
  • 脚本在其可配置性、可扩展性上性能应该是已经超越了中间件技术。

    中间件在对其扩展、更新、配置时不知是否能做到依赖它的程序不中断运行呢
  • --陈刚
  • 5. re: 软件开发模式猜测
  • 对 “中间件模式” 还真不太了解。 

    不知 “中间件模式” 是否会影响运行、调试以及维护成本,以及如何能抽象出中间层?
  • --陈刚
  • 6. re: void *几用
  • class Sample
    {
    public:
        void draw( void *g );
    };

    我个人其实并不太认同这种做法,虽然实现了抽象但会加大维护代价
  • --陈刚
  • 7. re: 用自己的话浅谈封装
  • 封装也是一个不断完善的过程,当然再经过一段时间后随着技术的进步思想的成熟,也会推翻重来。
  • --陈刚
  • 8. re: linux常见开发问题
  • xargs不错,蛮有用的。
  • --hATEmATH的网上田园
  • 9. re: 关于“元编程”的浅思考
  • --免费打工仔
  • 10. re: 关于质数(素数)的算法

  • 是AKS方法。
    http://mathworld.wolfram.com/AKSPrimalityTest.html


  • --perry
  • 11. re: 关于质数(素数)的算法
  • 为了在数字比较小时计算得快些,可以应用一些初等数论的结论:

    1]
    仅计算6n+1和6n+5(n=1,2,3,...)形式的数。易知6n+2和6n+4是2的倍数,6n+3是3的倍数。因为2和3的倍数最多。
    2]
    根据“合数的最大的素因数都不大于它的平方根”定理,每次分解仅算到被分解的平方根为止即可。
    证明(一般的证明都不完整):
    设N=P*Q,P和Q是N的不少于1个素因数的乘积(指出这点很重要)。反证法可证P和Q都小于或等于N的平方根(否则P*Q>N)。等号当且仅当P=Q=N的平方根时成立(这时N是一个素数的平方)。

    1]可减少2/3的计算量,2]可再减少1/2的计算量。即为原计算量的1/6。

    几百位数位的数,建议采用ASK方法。





  • --perry
  • 12. re: 关于质数(素数)的算法

  • 素因数分解是一个NP问题。
  • --perry
  • 13. re: 关于质数(素数)的算法
  • 1121=19*59
  • --李圆欢
  • 14. re: void *几用
  • 方法都不错
  • --员工生日礼物
  • 15. re: void *几用
  • to oshj:
    最近才悟道这个用法,没想到你都用了很多了。

    to brent:
    不是为了玩才玩,这里每种用法在特定的情况下,都有他相应的好处。不过,我是做为自己记录的,指不定什么时候就忘记了,还可以这么用。
    1. 可以使得头文件简单,而且出于实现保密的需要,还是很有用处的。
    2. 很多时候对象本身应该简洁,但往往应对不同的需要,通常需要数据对应。举个例子,比如玩家在哪个房间,在哪个房间最好不要直接记在玩家身上,用数据注入的方式,能够很快的获得该信息。
    3. 因为是做为库暴露头文件的,使用者并不关心void *的实际意义,而且能够加快编译速度。真正要关心时,就Graphics.h这个头文件是不够的,通常会需要了解整底层个实现,才能较好的扩充。
  • --清风雨

阅读排行榜

评论排行榜

有感公司一次郁闷的服务器重写

郁闷!

花了我四天,重写整个游戏服务器(安慰一下自己的郁闷,看起来很强)。

代码开始是一个同事写的,写到一半,转交了给我。当时觉得好多接口和我的习惯太不一样(不评论好坏),也不能重写啊,毕竟他努力的结果,贸然重写,一不小心什么地方没注意,搞坏了,还反而不好。

没想到,这次的新功能,我估计了两天时间,结果发现,根本就不可能。原有接口完全无法支持。没办法,全部重写了(害怕,强行添加,只会更麻烦,以后会问题多多)。

自己的痛,做个反面的例子提供给大家。以后,也可以引起注意。

第一:设计底层接口时,一定要尽量考虑通用性;
        专门为某一具体问题设计的特定接口,当后期需要加入新的功能或支持时,就不可避免的无法适应了。所以,同时也提提优化,优化应该是保证正确性和可扩充性后才做的事。

第二:设计结构时,一定要自身功能完备,考虑可扩充和可维护;
        如果确实无法抽象出公共层,那么就不应该增加这个中间层。要不,又是特殊化了,本来就不是抽象。一定要避免。顺便,功能完备指自身能成为一个整体,做到这个整体功能集是完整的(想了好半天,也不知道怎么表述,自己不是做软件工程的^_^)。

第三:模块结构一定要独立;
        要不,是想出错了,搞死人?鬼知道哪里出的错,满世界找。

第四:负责人最好一直负责,要么很强;
        由于思想背景、习惯、方法、方式的不同,接手者很难保证原负责人的目的和思想的完备。这样两个人的思维混杂,很容易导致各种问题和遗留。
        或者,原设计者很强,确实能够做到自身的结构或接口的功能完毕、全面、独立,易扩充、维护。

好了,如果你那里有架构师,或许就没问题了。出了问题,他吃白饭的啊!^_^


郁闷之中,言词难免有些犀利!见谅见谅了!

posted on 2005-06-06 09:59 终于有了间茅草棚 阅读(3252) 评论(21)  编辑 收藏

评论

# re: 有感公司一次郁闷的服务器重写

兄弟的服务器是linux下的还是win下的,现在采用哪种socket模型。
2005-06-06 10:53 | me

# re: 有感公司一次郁闷的服务器重写

同郁闷
2005-06-06 10:55 | kaikai

# 其实主要问题还是自己

自己接手时,处理的不好。处理的好!也不需要重写,毕竟大部分工作都是自己做的。
惭愧之极!

是win下的,现在还没有移植linux的工作。没有采用原始soket,用的是TNL网络库(虽然自己不怎么喜欢这个库)。
2005-06-06 10:58 | 清风雨

# re: 有感公司一次郁闷的服务器重写

太强了吧。。。
4天重写一遍。是指游戏逻辑接口处理吗

很多情况下都是没有办法的,为了完成整个项目,许多设计不好的地方都不敢去改,结果类与类之间的耦合程度越来越高,最终变成蜘蛛网。。。唉~~
2005-06-06 11:06 | 好人

# 不是指逻辑,是整个结构

哪里啊。 只是把结构和逻辑理了一遍,感觉更清楚了。基本上,逻辑都是以前的成果嘛,即使重写,也是有以前的基础的。

客户端也感觉受不了了,不过,没办法,这个是不可能重写的了。除非不要做了。
2005-06-06 12:07 | 清风雨

# re: 有感公司一次郁闷的服务器重写

开始总是不能把所有的事情全部考虑周全的,我也经常做重构这种事情
2005-06-06 13:08 | netsin

# 游戏服务器?

rt
2005-06-06 13:36 | ksl

# 不这么认为

呵呵。虽然,确实不能全部考虑周全。
但是,基本上,还是能够做到修改很小的。

以前公司,自己写就还好,可能是公司本身技术成熟。
自己给自己设计的东西,修改也很小,都不那么巨大。

所以,软件工程的东东还是真的有用,只是很难具体说清楚!
2005-06-06 21:56 | 清风雨

# re: 有感公司一次郁闷的服务器重写

中国人每个人都是英雄主义,每个人都认为其他人写的是垃圾代码,其实道理很简单,是因为每个人都没有按一定的规范去写,这也是软件工程中的一部分。
2005-06-07 08:27 | E

# 哈哈!说的很有道理!

就是我怎么听起来不爽呢!
我想你针对错人了。

要不,我们可以用事实说话,同样设计,同样编码。

或者,我们每人提供一套编码规范。给国外专家来评。如果你好,我这里道歉。
如果不是,你就针对错对象了。

当然,还是很赞同你的观点的。就是attack我的,看起来,有点不怎么happy。^_^

个人英雄是不好,但是,混乱中,好坏还是有的。——只是大家很多都没有这个能力能评判罢了。——或者,压根他就不懂。

软件和程序是两码事。软件好像编码部分的比例很小。所以你的英雄,或许应该审视一下,是不是自己过于情绪的发言了。
2005-06-07 09:07 | 清风雨

# 如果非要盖帽子,我就接受了

如果不接受那几顶帽子。恐怕也还是会送的。

只是,站我这边的,我就是坚持真理;我对面的,我就是食古不化了。

还是,不要针对个人。就是论事。:}

俺不是谈编码哦,因为已经老化的问题,答案都在那。

我是说,大家的设计和结构。——也就是很多时候有人觉得写写框框的那些人,有点不服的(也包括曾经的我)。^_^
2005-06-07 09:14 | 清风雨

# 想想又跑回来了

大家不要看别的。那是我这人的问题。^_^

还是看观点好了。绝对管用。好多国外著作里都说过的。

只是想用自己的事实,给大家点借鉴和建议。

开工前,多考虑架构和接口。
不要急着动手,会得不偿失。尤其是对主管有点借鉴,比较有点前车之鉴的意味。
2005-06-07 09:33 | 终于有了间茅草棚

# re: 有感公司一次郁闷的服务器重写

嗯。这次对结构进行重写主要责任并不在写程序的人,是因为需求的急速变动而造成的。任何在这种需求急速变动的情况下写程序的程序员都不可避免的会遇到许多问题。如果是正常情况下,在后期添加新功能需要与程序员进行商量,程序员有权否决(如策划坚持,则由此造成的问题可以一概不负责)

不过话说回来,小公司开发程序不能进行重量级的开发模式,轻量级的开发模式本来就是个不断迭代的过程。习惯了就好。HOHO~

《设计模式》这本书在俺床头,俺来来回回翻了几遍,发现一般情况下还真用不上多少。设计时最重要就是考虑功能模块的内聚性了。一般情况下只要考虑到内聚性问题就不会太大。
2005-06-07 09:52 | 好人

# re: 有感公司一次郁闷的服务器重写

嗯,像易变的地方还是迭代或者XP来得有用些。
再怎么写能重用的代码,最后基本上还是不行。
2005-06-07 10:00 | W

# 不是很赞同哦!

个人一直觉得好的结构是可以的。

关于公司,我现在的公司还算大公司,以前的公司下,感觉效率还高。个人觉得,还可以高很多。

关于设计模式,个人认为可以超越何发展的。它是经验和积累,就像人类发展是个累积和发展的过程。然后,这个东西在一定程度上,会的人就是会,不会的就是不会。得其表,不得其内,反而还被搞得莫明奇妙。
2005-06-07 19:37 | 清风雨

# re: 有感公司一次郁闷的服务器重写

房主看起来是做游戏服务器的吧。我也是。最近我也做了和房主类似的事情,感觉重构要时时做、频繁的做,把软件架构始终保持在良好的状态,而不是周期性地大改(这样会带来较大的风险)。但可惜的是目前的软件公司基本上在筹划时都没有把“维护软件架构”的时间加到日常时间表里去。。。
2005-06-30 17:45 | diclogic

# re: 有感公司一次郁闷的服务器重写

关于“每个人都认为其他人写的是垃圾代码”:

“会看到别人写的具体实现的代码,需要改别人写的具体实现的代码”本身就是问题,出现了这种情况就已经出问题了。

就像一个朋友问我如何解决有环依赖,我看了一下,发现根本就是类的职能划分就有问题,所以留下了“怎么也解决不了的环”
2005-06-30 17:50 | diclogic

# re: 有感公司一次郁闷的服务器重写

“开工前,多考虑架构和接口。不要急着动手,会得不偿失。”是一个很容易用直觉发现的、但目前还不是最好的 方法。(至少我个人觉得是这样)

架构会随着开发的进行而变化,起初对于模块的划分很可能就会变成错的或者至少是不良的。模块该怎么划分呢?以什么为原则划分呢?想清了这些,就会发现模块划分的根本需求其实来源于代码,而代码是在不断成长变化的,因此模块的划分(至少是最小模块单位的划分)是会随之改变的。。。
2005-06-30 19:16 | diclogic

# re: 有感公司一次郁闷的服务器重写

我的职能不是很好划分。
服务器也做、客户端也做、平台也做的。

业界普遍有种划分:图形、网络、逻辑,其实总觉得缺点什么?
这个划分,有个前提,那就是能够模块化到这个层度。哈哈,其实国内有哪个敢说自己有这个实力?我表示怀疑。

至于架构的问题,就像写windows程序一样,有个通用的模式,这个模式是可以抽象出来的,至少对某一类问题。—— 只是有的人做的好,有的做的差。

模块的划分原则:模块间耦合度小、模块内内聚大。——很抽象,因为本身对应的就是抽象问题。

怎样才小、怎样才大?这个就要涉及经验、知识、能力...等等。给出统一的答案很难,往往都需要根据具体的实际项目而定。

如果有个好的设计和结构,可能你就不会有上述疑问和看法了。—— 至少我这么认为。
2005-07-05 20:05 | 清风雨

# re: 有感公司一次郁闷的服务器重写

清风雨,你在哪个公司?
2005-10-17 12:42 | alick

# re: alick

不知阁下是哪位。
2005-10-18 19:34 | 清风雨
标题  
姓名  
主页
验证码 *
内容   
  登录  使用高级评论  Top
[使用Ctrl+Enter键可以直接提交]