追求神乎其技的程式设计之道(四)

来源:百度文库 编辑:神马文学网 时间:2024/04/20 12:46:24

程式设计到底是什么?

2000年IOI在北京举办,这年台湾的代表队成绩还算不错,拿到三银一铜,比较可惜的是我第一天表现不理想而落到了铜牌,虽然不至于两手空空无颜面对江东父老,但也知道自己的实力大概就在银牌和铜牌的边缘处吧。IOI结束后,我又回到了学校,但因为已经取得大学保送资格,在学校其实也是轻松写意,成天就看自己的书或研究自己有兴趣的东西。

在这段时间中,我开始有所警觉,我发现我虽然很会写程式解题,但那都是一两百行以内的小程式,真实世界的程式根本不是这个样子的!虽然我能很快看出一个问题该用什么演算法效率最高,并且在很短的时间内把自己的想法正确地转换成程式码,但我还是不知道市面上的软体或游戏是怎么做出来的。

我这时才开始接触C++和物件导向的概念,我突然发现要写个大程式还真不是简单的事,除了程式语言外,还有好多琐碎的函式库得学。像是要画图就要学2D的SDL或是3D的OpenGL,要做Windows GUI程式就要学Windows SDK或是MFC,要写网路连线就得学socket,要让游戏执行顺畅甚至得用组合语言写某些部分…。好多好多东西不断涌出来,学这些东西很有趣,因为我一边学就会一边联想到学会这个功能后可以用在游戏里的什么地方,于是整个学习过程就像把我梦想中的拼图一块一块拼上去一样,非常有成就感。

边写这种实用性的程式时,我也发现以往在比赛中累积了很多不好的习惯,像是滥用全域变数、变数随便命名、把整个程式塞在main里…。这些坏习惯在写小程式看不出来有什么差别,但随着程式规模变大,这就变成了很致命的习惯。而这种习惯一但养成,之后会变得更难改,所以强烈建议初学程式设计的朋友们,一开始就不要偷懒,从认真帮变数想个好名字开始吧!

这段期间也让我想了很多关于程式设计的有趣问题,像是写程式到底算是科学+工程,还是艺术?写程式必须要非常非常精确,任何一个字打错都可能会让整个程式跑出完全不同的结果,这对于天生就容易犯错的人类来说实在是艰鉅的挑战。为了避免错误太多,我们只能用一些固定的流程并强迫程式设计师遵守,让可能的错误减到最低,这就是所谓的软体工程。虽然有工程的影子,但写程式却是很难精确管理的工作,因为面对同样的问题,不同的人绝对会写出不同的程式,甚至是提出不同的解决方法﹔有的程式可能要跑三天三夜,有的程式却能在瞬间得到正确解答﹔有的程式码杂乱不堪,也有的程式码井然有序清晰易读﹔有的人要花三天写1000行,也有人能在一天写100行就达到完全相同的效果﹔这些程式的目的可能完全相同,但呈现方法却有千万种,软体工程难道可以限制每个程式设计师大脑运作的方式和速度吗?

从程式码的观点来看,不同的人写出的程式码也一定不相同。从程式码的排版、命名、段落安排、抽象化程度、运作流程可以看出作者的个性、态度、思考逻辑及深度。从这个角度来看,写程式更像是种艺术,就像是画笔或乐器一样是一种表达自我并将思想具体化的工具。

另外我很感兴趣的是,人一定要写程式才能叫电脑做这么多复杂的工作吗?能不能教电脑写程式,让人只要告诉电脑要写什么样的程式就好?或是有没有更简单更方便的方法能和电脑沟通,并且保有同样的控制力?

就在被这个问题困扰着的同时,我意外从一本书看到基因演算法(Genetic Algorithms)这个名词。稍微研究过后让我大吃一惊,因为我发现基因演算法是一个超级有效率的搜寻演算法,可以在几近无限广大的可能解里面很快找到接近最佳解的答案。所以,我很快想到了,如果想要让电脑写程式,其实就是告诉他要写的程式要达到什么目的,并让他在几近无限大的可能程式中找出能跑出我们需要答案的那个程式。这是一种把写程式视为搜寻的概念,我当时想到这件事非常兴奋,但我并不知道其实早就有人想出同样的概念(这叫Genetic Programming),并已经做了许多研究。

其实有时候无知是件好事,这样才会有勇气在不知道这个问题有多难的情况下去尝试看看。如果我当初就知道这问题其实是能拿好几个博士学位甚至是得到图灵奖(Turing Award, 资讯界的诺贝尔奖)的难题,我可能连继续尝试的勇气都不会有了