程序猿

本文从一篇转载文章说起,该文章其中一个话题我认为很有现实意义:论述了为什么不要编写庞大的程序;另外,文章抛出了一个问题:同样的项目,为什么在windows上编译比在freeBSD要慢很多很多呢?

看了这篇文章,结合自身的经历,在文章后面也谈谈自己的感受。欢迎探讨。

为什么说不要编写庞大的程序?

注:以下段落内容转自http://blog.codingnow.com/2009/04/ieaeeoaooaeio.html

《Unix 编程艺术》中总结的 Unix 哲学中有这么一条:除非确无它法,不要编写庞大的程序。并且在第 13 章 花了一章讨论复杂度的问题。(第 13 章 复杂度:尽可能简单,单别简单过了头)

下周一,是我们项目的一个进度线。所以,周末我安排了加班。当然,我最近两年,每个休息日都给自己安排的加班,无所谓周末。不过给团队安排加班还是比较稀少的事情。

由于种种原因,不是每个人都能够把自己的休息时间贡献出来的。作为团队负责人,我的原则是,生活大于工作。如果有生活上的事情,就可以拒绝加班。对于项目,也不应该把某件事情依赖到特别的某个人身上,虽然某些东西由特定的人去做(比如维护自己写的模块/程序)会效率高一些,但是其他人也应当可以顶替。

所以,偶尔维护一下不是自己写的代码,且能够在很短时间进入状态,就是团队每个人应该具有的能力。在这方面,我们的团队做的还不是很好,不是每个人都有这样的能力。但、这也并非个人能力单方面的因素。

同样,光靠提升代码质量也不是能完全解决问题的。整个项目的模块切分、文档定义等等更为重要。

说起来,我的感触就是:”除非确无它法,不要编写庞大的程序“ 。简洁小巧的程序总是好维护的。尤其是容易进入状态的。我说的进入状态即:在出现 bug 的 30 分钟内可以弄明白那些不是自己写的、陌生的没有读过的代码的脉络。并且开始着手解决问题。

强调进入状态的速度,是因为,如果需要去读几个小时的代码才摸清楚结构的话,还不如等到下个工作日,让原作者给你解释或由原作者去解决问题。

其实,不仅仅是这个周末。已经有太多周末以及夜晚,办公室里人员不齐,遇到问题必须自己解决了。虽然不是所有问题都可以自己弄明白,偶尔也需要打电话给相关代码的作者问清楚。但是,大部分问题都还是可以搞定的。我觉得很大程度上,就是因为,我们从来没有编写庞大的程序,即使是迫不得以编写庞大的程序(比如游戏的 client ),也把层次和模块分的很清晰,每个都不大。

最后想说的是:不要把问题推给别人。即便不是为自己的项目工作,作为程序员,发现问题就应该着手考虑解决。这也是开源的精神(当然,使用闭源软件就很难做到了)。作为程序员,解决问题,是自身能力提高的源泉。

有时,修补他人的代码,甚至是不被你的美学所接受的代码,更能增强对代码的把握能力。比如:我放弃用 C++ 编写软件,但我不排斥阅读 C++ 项目。即便我一边用嘲讽的语气去评论那些“精巧的”设计,另一方面也会客观的去理解是什么需求导致了如此的结构。


最近,工作太忙。没时间看书。只是把《Unix 编程艺术》放在手边,累了就翻一下。其实呢,许多道理本就明白,可每次看见白纸黑字,还是觉得的确很有道理。最近一年,觉得自己悟了许多。悟:并非明白了以前不明白的东西.知识还是那些知识,道理还是那些道理,似乎没有学到新的,又胜过学了新的东西。


一则有趣的对比:

我们的项目在 Windows 下,使用 mingw make 全部需要 47 秒(很干净的 Windows XP ,没有装任何杀毒软件)。

但是在 freeBSD 上用同样的机器,做同样的事情只用 18 秒。

谁可以解释这个差异?

因为 Windows 开进程太慢?文件系统太糟糕?Console 速度太慢?mingw 的 gcc 太慢?

读后感(原创)

说说自己对“为什么不要编写庞大的程序”的感受。就这个话题,看完上面的论述,我理解其意为:我们应该尽量编写简洁小巧的、容易维护的程序。

看到上面内容之前几个小时,在21IC BBS上看到一篇文章帖子——《论技术的极致》,链接:http://bbs.21ic.com/icview-604773-1-1.html。这篇文章也描述了一个现象:很多技术人员喜好挑战高难度,追求技术上的极致和完美。

自己而言,感同身受。在做系统的事情,在编写程序的时候,一个现象就是:尽展所学、绞尽脑汁让自己编写的程序表现的多么高深、多么的技巧、多么的玄美;功能上极尽地想做到最大兼容、预留强大的扩展性。而往往这样做下来的结果是:

  1. 舍本琢末,忽略需求的本质;
  2. 简单问题复杂化,工作强度加大累得自己半死。
  3. 代码冗余,不易维护。

为什么这么说呢?

比如说一个功能模块,它本来需求是管理3种在功能和性能上有一些差异的芯片(基本功能相同,某一硬件板只用其中一种)。为使软件代码统一、方便维护和管理、而且设计时想当然认为是不是要预留第4种芯片的管理,因此,设计为屏蔽这3种芯片的差异向上层提供统一的API接口,结果弄了个中间层,一堆结构体和函数指针。

屏蔽差异力求统一,本来初衷是好的。但问题是,这些芯片本身就具有较大差异,强行统一必然导致整个模块实现的复杂化,而且还想当然有第4种芯片,则有可能留下多余的代码和信息。这种情况是,如果是设计者本身维护可能问题不大,然换成其他人来维护呢?其他人不得不花费不少精力来理清这个复杂的设计架构,期间可能还会被设计者留下多余的代码和信息搞得云里雾里。

所以,作为一名程序员,一切的程序设计应该从最本质的需求出发,回归自然,而不是刻意地炫耀你的编程水平。

第2个话题:同样的项目,为什么在windows上编译比在freeBSD要慢很多很多呢?

我觉得如果你对这个问题有兴趣,不妨去看看那文章的评论。我摘录一些自已认为比较有用的评论在这里。

“…MinGW aims to provide native functionality and performance via direct Windows API calls….” 所以mingw某种程度上说,是一个仿真器。

而GCC在unix/linux下面,gcc静态库libgcc.a,kernel,libc一般都实现了处理器级优化的。

另外,我一直坚信unix文件系统的buffer和cache性能从来都是领先于window的。两个证据:1.window从dos文件系统诞生到nt的微内核技术,一直是跟着unix学的;2.服务器系统从来都是unix的天下,文件系统性能是关键指标,而大型工程编译过程对FS系统的buffer&cache是个很好的经验。

我觉得基本上是这两个原因,做下benchmarking,内核&文件系统差异很快就能得到量化的参考值。

个人觉得,更多的是商业和学术之间的差异。商业的成功,就是要追求利润,多少的成本,带来多少的收益。

对于M$而言,他们的程序员应该不差FreeBSD那样的技术能力,但他们更多的在意投入的成本,至少出来的结果嘛,够用就行,能赚到钱就OK。所以,他们并不会太过追求运行效率。

而对于FreeBSD这种更技术、更学术的东西,商业利益的地位远在技术之下,所以BSD的程序员们,能够写出更优秀的程序。

我个人认为是pipe的原因导致了编译速度的差别.

我写了个VI插件, 在LINUX下和在WINDOWS下的速度差别很大很大, 其中最最明显的差别处就在于当调用外部命令执行管道重定向时.

更多的自己去看了,看别人的观点,吸取精华,去其真伪,这也是一个自我提高、自我积累的过程。

» 文章出处: reille博客—http://velep.com , 如果没有特别声明,文章均为reille博客原创作品
» 郑重声明: 原创作品未经允许不得转载,如需转载请联系reille#qq.com(#换成@)
分享到:

 Leave a Reply

(必须)

(我会替您保密的)(必须)


*

   
© 2012 velep.com | reille blog | 管理| 粤ICP备12094833号-2| 谷歌地图| 百度地图| Suffusion theme|Sayontan Sinha

无觅相关文章插件,快速提升流量