道简

最近读了TopLanguage上关于编程风格的一些讨论,拜读了下云风老大的两篇佳作。 感触良多。 做为一个“码头工人”,每天都在coding,不由会想,我们的脑细胞和陪mm的时间都耗在了哪行代码上。诚然,在C++这样的语言中,我们大把的时间花 在了等待编译以及做一些繁杂而和coding无直接关联的事情。Toplanguage上有老大说,他的C++生涯25%在等待编译,5%在各种字符串中 转换,狂赞。只是对我而言,起码还有5%的时间耗费在了在.h和.cpp文件中添加和维护相同的代码上。对此,我们能做的除了等待各位委员会老大高抬贵手 外,只能选择放本书在电脑旁,编译和看书并发进行。
恩。抛开这种问题不提。个人觉得,做一个程序,主要的复杂度和耗时都来自于两个方面。一是算法逻辑,另一个是有平台和语言带来的细节性问题。关于算法逻 辑,我们学各式各样的算法,数据结构,我们偶尔灵光乍现把算法复杂度提上一个档次,这样的工作,本应该是程序最核心的内容,但往往在只占用我们花在工程上 的一小部分时间。对于很多项目而言,我们关心的是时刻在变化的算法逻辑。见佛杀佛,遇鬼杀鬼,只可惜,很多时候连我们自己都不知道我们面对的是什么。这世 界上,最复杂易变的东西就是人本身,最恐怖的是变化的需求。于是,我们又有了模式,它使得我们程序更容易适应某种类型的需求变化。我们抓住它,作为解决问 题的套路,方案,捷径。就像影响力里 面所描述的一样,我们找到了一个思维的高速公路,当我们提到xx模式的时候,就像“哔”的一下按了快门,“它适应于xx变化,可以解决xx类型的问题”之 类的内容,汹涌而出。但是,走多了夜路总会遇到鬼,走多了捷径,恩,我们需要重构。模式和重构,就像xx套和xx药(BS自己一下...越来越WS... ==!),事前事后帮助我们写出更符合需求的算法逻辑,或说算法的结构。这样的算法,解决的不只是当下的问题,还有未来可能的问题。
无论算法设计的难度有多大,变化的可能性有多高,对于程序员,我觉得,这是我们份内的事情。我们没有借口去拒绝或埋怨它。程序员的定义,理想上,应该是设 计算法和结构解决某个问题的人。当然我明白,在当前满足这个定义的人,已经不会再叫程序员了,而是xx师、xx家。对于大部分的程序员而言,我们的工作是 另一个方面,就是利用自己对语言和平台的熟悉度,去实现某个已设计好的方案。这个需求本身并不过分,就像你空有奇想却不会使用画笔的人,不能称为画家一 样。过分的是,很多时候,它让我们离一些创造性的内容越来越远,深深陷入了细节的泥沼,并沉醉其中。百万程序员堕落沦为码工的旷世惨案就这样发生了。
Sorry,又习惯性跑题了。言归正传。说另一个耗费我们头发的方面,语言和平台的复杂性。现实总是很残酷。我们想到了一个完美的算法解决方案,和遗憾, 这还远远不够。方案到实现,绝对不是汇编到机器码的复杂度。我们还需要关心大量的与算法本身无关的细节。比如,这个指针的对象何时归还,有人传了错误的参 数移走了我们需要的文件需要如何报错,平台的API和我们需要的不一样该如何使用。诸如此类。就是它,成为我们高效写程序的阻碍和绊脚石。在实验室中,每 周都有老大讲述老百姓自己的C++,倾诉着绕来绕去的语义,纷繁复杂的注意事项。我们能不听吗?不能,因为老大们有大把的例子说明,在我们的项目中,由于 对细节理解的不够BT,我们正在犯着各种各样的错误。对个人而言,了解更多的细节,机理是非常有益的,就像武侠小说中常出现的,服下xx大补丸内功暴涨 (只是请注意不要向东方不败一样走了火入了魔...)。但对于项目而言,从程序员的角度出发,来解决这个实现细节问题,过于的不现实。就像云风老大说的一 样,这是比window比unix更安全一样的笑话(转述的MS有点偏差...)。我们不能奢望程序员都是蝙蝠侠,在没有睡眠只有可乐的日子里像赵子龙一 样,在海量的细节面前屹立不倒(不要以为只有C++才有海量的细节,想handle任何一门语言的所有细节都绝对不是大众活)。我知道在大量的开源类库 中,大量的实践类书籍中,人们都是这么做的,用各种奇技淫巧解决细节问题。但是,那只是通用的方式,适合于任何情况任何场合。而对于特定的工程特定的场合 而言,我们需要做的是在架构和规范(此规范与101那样的通用规范不是一个概念...指的是在某个局部范围内简单的几条需要遵循的原则,比如在这些模块内 不能用引用,在这些模块内不能用指着之类的...)的层面上,事先将实现的复杂性控制在一定范围之内,扼杀在摇篮中。而不是放任各中各样复杂的实现细节蔓 延到程序的各个角落之后,在启用飞机大炮原子弹开始处理。云风老大在网易游戏引擎中的设计,从架构开始把所需要各个模块需要了解的实现细节规划的清清楚 楚。底层传值用POD、容器中用GC管理指针之类的。在一定范围内,你需要注意的实现细节只有一点点,完全处于人脑可控的范围内。同理, Toplanguage中各位老大对引用say no,也是这个道理。这里举这些例子,不是提供另一个捷径,触发流水般思维的快门。而只是一个单纯的例子,告诉你这样的方式是更好的解决之道。对于特定的 项目而言,我想,还是要具体问题具体分析,绝对不存在一成不变的规矩。在C++中提供了很多高阶的手段(相比存C...),它们能更容易在一定实现细节内 解决一些特定的问题。当你的工程中触及大量的这样的问题,而你却恰恰限制这样的使用的话,简约反而不简单了。多的自由,意味着多的麻烦。从根本上限制自 由,大大减少了麻烦。反之,限制如果加的不对,那反而是画蛇添足没事找事了。说的就是这个理。
但现实的残酷性有再次提上了议程。我的地盘我可以做主,但出了这一亩三分地,谁是老大就不一定了。在我的程序世界,总是充斥着大量的遗留代码,或者是必须 面对的接口需求。在这样的地方,你不再能为所欲为了,很多看似美好的方案都会化成一卷废纸。面对遗留代码,我们可以选择一起堕落,或力挽狂澜, 更多时候是划清楚界限(模块化,服务化,就是这个理...)。在接口受限的情况下也是一样。对外的接口已经确定,但我想提供更多的内容出去,所能做的就是 将该接口的表征能力挖到极限。在这种情况下,我想将细节复杂性确定在一个有限的范围内是比较可行的方案。一面是花花世界,一面是清静的世外桃源。中间,是 混沌的地域。带着你们最NB的老大,和所有的奇技淫巧,去往这个地狱,搞定它,这个世界就清净了。。。

posted on 2007-12-18 01:12 duguguiyu 阅读(...) 评论(...) 编辑 收藏

导航

统计