转载自: http://www.vcroad.net/ (枣子原创 [email protected])

---

做为一名大四的学生，我去面试过不少的公司，有成功的也有失败的，但是对我来说所有的失败在某种意义上都是一种成功，特别是我下面写的这些，写这篇文章的时候，我已经签了南京的一家软件公司，但是想起今年 2 月 21 日我面试苏州台湾的 IT 公司的经历联想到我们现在学习程式设计的一些情况我真的深有感触，这次面试使我深深的体会到了失败但也收获了很多。

我要说的将分成三部分:

1. 我去面试的具体经过
2. 由面试想到的
3. 现今我应该做的

当然这些话很大程度上是我个人的意见，不可能完全得到大家的赞同，所以在某些观点上如果哪位朋友觉得跟我的有很大出入，请不要介意，也不要对我攻击，就当我没有说过，欢迎和我联系共同探讨这些问题！

1. 面试经过

大约在年前我接到了台湾瑞昱 (Realtek) 苏州公司的面试通知，通知我 2 月 21 日到苏州工业园区面试，接到面试后的几天我把一些专业课程温习了一遍，特别是 C++ 和资料结构，由于大学几年里，我一直钻研这些方面，加上通过了进阶程式设计师的考试，对于一些常用的算法我差不多也达到了烂熟于胸的地步，当时的感觉是如果问了我这些方面的问题我应该是没有问题的！

那天我被安排在 4:30 面试，由一位技术人员单独跟我面试，在问了一些简单的问题之后他给我出了一道程式设计题目，题目是这样的 (由于具体面试的题目比较烦琐，我将其核心思想提取出来分解成了两个独立的简单的问题，有可能问题分解的不当，请大家见谅，实际面试了一个的问题但比其复杂很多，而且涉及一些高等数学转换)：

1) 写一个函数计算当参数为 n(n 很大) 时的值 1-2+3-4+5-6+7...+n

哼，我的心里冷笑一声！没想到这么简单，我有点紧张的心情顿时放松起来！于是很快我给出我的解法：

long fn(long n) {
  long temp=0;
  int i,flag=1;
  if(n<=0) {
    printf("error: n must > 0");
    exit(1);
  }
  for(i=1;i<=n;i++) {
    temp=temp+flag*i;
    flag=(-1)*flag;
  }
  return temp;
}

搞定！当我用期待的眼光看着面试官的时候，他微笑着跟我说，执行结果肯定是没有问题！但当 n 很大的时候我这个程式执行效率很低，在嵌入式系统的开发中，程式的执行效率很重要，能让 CPU 少执行一条指令都是好的，他让我看看这个程式还有什么可以修改的地方，把程式优化一下！

听了这些话，我的心情当时变的有点沉重，没想到他的要求很严格，之后我对程式进行了严格的分析，给出了改进了的方案！

long fn(long n) {
  long temp=0;
  int j=1,i=1,flag=1;
  if(n<=0) {
    printf("error: n must > 0");
    exit(1);
  }
  while(j<=n) {
    temp=temp+i;
    i=-i;
    i>0?i++:i--;
    j++;
  }
  return temp;
}

虽然我不敢保证我这个算法是最优的，但是比起上一个程式，我将所有涉及到乘法指令的叙述式改为执行加法指令，既达到要题目的要求而且运算时间缩短了很多！而代价仅仅是增加了一个整数变量！

但是我现在的信心已经受了一点打击，我半信半疑的看着面试官，他还是微笑着跟我说：“不错，这个程式确实在效率上有的很大的提升！”我心里一阵暗喜！

但他接着说这个程式仍然不能达到他的要求，要我给出更优的方案！天啊！还有优化！我当时真的有点崩溃了，想了一会后，我请求他给出他的方案！然后他很爽快的给出了他的程式！

long fn(long n) {
  if(n<=0) {
    printf("error: n must > 0");
    exit(1);
  }
  if(0==n%2)
    return (n/2)*(-1);
  else
    return (n/2)*(-1)+n;
}

搞笑，当时我目瞪口呆，没想到他是这个意思，这么简单的程式码我真的不会写吗，但是我为什么没有往那方面想呢！

他说的没有错，在 n 很大很大的时候这三个程式执行时间的差别简直是天壤之别！

当我刚想开口说点什么的时候，他却先开口了：“不要认为 CPU 运算速度快就把所有的问题都推给它去做，程式设计师应该将程式码优化再优化，我们自己能做的决不要让 CPU 做，因为 CPU 是为用户服务的，不是为我们程式设计师服务的！”

多么精辟的语言，我已经不想再说什么了！

接着是第二个问题：

2) 用一种技巧性的设计方法来用一个函数实现两个函数的功能

如:

fn1(n)=n/2!+n/3!+n/4!+n/5!+n/6!
fn2(n)=n/5!+n/6!+n/7!+n/8!+n/9!

现在用一个函数 fn(int n,int flag) 实现，当 flag 为 0 时，实现 fn1 功能，如果 flag 为 1 时实现 fn2 功能！他的要求还是效率，效率，效率！

说实在话，如果我心情好的话我应该能给出一种比较好的算法，但我那时真的没有什么心思再想了，我在纸上胡乱画了一些诸如 6!=6*5! 的公式后直截了当的跟他说要他给出他的答案！

面试官也没有说什么，给出了他的思路：

定义一个二维阵列 float t[2][5] 存入 [2!,3!,4!,5!,6!],[5!,6!,7!,8!,9!] 然后给出一个循环：

for(i=0;i<6;i++) {
  temp=temp+n/t[flag];
}

最后得到计算值！

呵呵，典型的空间换时间的算法！

这些总共花了 50 分钟的时间，还有 10 分钟我就跟他很随意的聊聊天，聊了一些程式设计以及生活的问题，那时的我已经很放松了，因为我知道这次面试结果只有一个：失败。

5:30 的时候面试官要我等通知，于是我离开了他们公司。这就是面试的整个经过！

2. 由面试想到的

真的是很失败啊！我记得那天下好大的雨，气温也很低，我边走边想，从 5:30 一直走到 7:30，全身都湿透了，又冷又饿，但是我只是一直走，脑子里面充满了疑惑，我也想让雨把自己淋醒！看到这里有些朋友可能觉得那些面试题目不算什么，如果让自己做的话肯定能全部答对，我肯定相信你，因为我从未怀疑过中国程式设计师的能力，我认为中国有世界上最好的程式设计师，我也从未认为自己是高手，所以我做不出来不代表中国程式设计师比台湾或者别的地方的程式设计师差，所以我就从我的角度，我的所见所想来谈一些感想。

不错，全世界都有优秀的程式设计师，中国也不例外，但是我疑惑的是：到底中国和台湾或者国外优秀的程式设计师的比例到底是多少？台湾我不知道，中国 100 个程式设计师里有几个是优秀的呢？

我根本算不上，从上面的表现就足以说明一切了！是 1 个？5 个？10 个？50 个？这个数字我不敢乱猜，恐遭网友一顿痛骂，那么我们国内有多少人学习电脑呢？拿我们学校来说，电脑 97 级 4 个班，98 级 5 个班，99 级 10 个班，2000 级 17 个班，人多了，老师怎么办？我们学校的做法是让研究生上课，然后呢？补考一抓一大把，大把大把的补考费落入了学校的口袋，还说现在的学生素质低！

真是好笑，我都不知道学校这么做是为了什么，为国内培养大量的程式设计师吗？学生们能真正学到电脑知识吗？好了，我敢讲，在我们学校学习程式设计学生和优秀程式设计师 (注意我指的是优秀，只会写几个糟烂程式的人算不上) 的比例应该是 100:0.1。

在这种比例下虽然我们中国学习程式设计的人铺天盖地，但是想想有多少人能真正为中国软件业发展作出贡献，有多少人能真正写出优秀的程式扬名海外！

我从学习程式设计以来，不管是自学还是老师指导，从来都是解决问题就好，写出程式来就行，我的疑惑是：我们有真正的强调过程式的效率、程式的品质吗？我们有仔细分析过我们写的东西，看看有没有可以改进的地方、有没有简单的方法来达到同样的目的吗？

我扪心自问，我发现，我从来没有对我写出来的程式进行过优化，最多就是进行详细的测试，然后 Debug，但是这就足够了吗？

这些天我偶尔发现我曾经写过的一个游戏，那是一年前我刚加入 www.vcroad.net 做为其中一员时候，感觉应该拿点东西出来，然后花了一个星期的时间写出来的！

程式不算复杂，但是用到了不少资料结构的东西，也用到了一些精彩的算法，加上 Windows 的接口和游戏的可玩性，写完后受到了不少好评，我当时真的很佩服自己！

但是现在看呢：没有一句注解，好多丑陋的函数名称，比如：void chushihua()，好多没有必要的变量，可以用简单叙述式完成的工作，我使用华丽的算法，大量使用全域变量…

说不好听的话，六百多行的程式码除了能执行之外就是一陀屎！

如果一年前我能听到一些反面意见的话，大概我能早一点觉悟，但是自从原始码在网站发布以来听到的都是赞美之词，没有一个人向我提出程式改进的意见，这又说明了一个什么问题呢？很值得思考啊！

还有一个疑惑是：我们说的和做的真的一样吗？

我在学校的时候曾经受学院指派承办过一个电脑程式设计大赛，请了一个老师出决赛的题目，主要是一些算法题目，这个老师可能是我上大学以来唯一敬佩的老师了，从程式除错到评分，对于每个程式都仔细分析其时间效率和空间效率，然后综合评分，四十个人的考卷，老师从下午三点一直除错到晚上十点，在有些写的精彩的叙述式后还加上批注。

我真是高兴能遇到这样的老师，并且和他做深入的交流。但在事后，却发生了一件不愉快的事，在比赛中获得第二名的学生找到了我，说他程式全部除错成功应该给他满分，并且应该得第一，我说不过他，最后调出了他的原程式和第一名的原程式对比，不错，两个程式都执行的很好，这时，那个同学开口了：“我的程式写的十分简捷明了，仅仅数行就完成了题目要求，而他的却写了一大堆，为什么给他的分数多过给我的分数。”

我当时很是气愤，如果不是老师负责的话，那么现在第一名和第二名的位置真的要互调了！拜托，不是程式的行数越少程式的品质就越高，我记得我跟他大谈这方面的道理，最后说服他了！

哈哈，但是我，只能说说而已，我不知道还有多少人一样，说起来头头是道，但心里却压根就从未重视过它！

3. 我打算做的

其实那天我想到的远不止上面那么多，但是我不想再说了，因为我猜想看这篇文章的网友大概都有一肚子的感想，一肚子的抱怨，借用这篇文章发泄可不是我想达到的目的，在上面我把自己骂的一文不值也不是妄自菲薄，但是在某些方面我真的做错了，或者说是偏离了正确方向，现在是矫正方向和重整旗鼓的时候了！就像我前面说过的，我相信中国有世界上最好的程式设计师，我也相信我的水准不会一直保持现状，我现在就收拾起牢骚真正的实干起来！

真的很巧，就写到这里的时候我在网上偶尔发现了一篇手册，我不知道这暗示著什么，但是我想如果我照下面这个基本原则一直踏实做下去，我一定会实现我的理想 - 一名优秀的软件设计师！

（下面这些文字不是我的原创，是我偶尔在网上发现的，我真的很幸运能看到这些，这篇文章也随着下面的文字而结束，我真心的希望您能从这篇文章中得到启发，这篇文章欢迎大家随意转载，您可以不写作者是谁，但是请您写上 ww.vcroad.net 原创，谢谢您的支持）

---

程式设计师的高手之路

作者：金蝶中间件公司 CTO 袁红岗

不知不觉做软件已经做了十年，有成功的喜悦，也有失败的痛苦，但总不敢称自己是高手，因为和我心目中真正的高手们比起来，还差的太远。世界上并没有成为高手的捷径，但一些基本原则是可以遵循的。

1. 扎实的基础

资料结构、离散数学、编译原理，这些是所有电脑科学的基础，如果不掌握他们，很难写出高水准的程式。据我的观察，学电脑专业的人比学其他专业的人更能写出高品质的软件。程式人人都会写，但当你发现写到一定程度很难再提升的时候，就应该想想是不是要回过头来学学这些最基本的理论。不要一开始就去学 OOP，即使你再精通 OOP，遇到一些基本算法的时候可能也会束手无策。

2. 丰富的想像力

不要拘泥于固定的思维方式，遇到问题的时候要多想几种解决问题的方案，试试别人从没想过的方法。丰富的想像力是建立在丰富的知识的基础上，除电脑以外，多涉猎其他的学科，比如天文、物理、数学...等等。另外，多看科幻电影也是一个很好的途径。

3. 最简单的是最好的

这也许是所有科学都遵循的一条准则，如此复杂的质能互换原理在爱因斯坦眼里不过是一个简单得不能再简单的公式：E=mc²。简单的方法更容易被人理解，更容易实现，也更容易维护。遇到问题时要优先考虑最简单的方案，只有简单方案不能满足要求时再考虑复杂的方案。

4. 不钻牛角尖

当你遇到障碍的时候，不妨暂时远离电脑，看看窗外的风景，听听轻音乐，和朋友聊聊天。当我遇到难题的时候会去玩游戏，而且是那种极暴力的打斗类游戏，当负责游戏的那部分大脑细胞极度亢奋的时候，负责程式设计的那部分大脑细胞就得到了充分的休息。当重新开始工作的时候，我会发现那些难题现在竟然可以迎刃而解。

5. 对答案的渴求

人类自然科学的发展史就是一个渴求得到答案的过程，即使只能知道答案的一小部分也值得我们去付出。只要你坚定信念，一定要找到问题的答案，你才会付出精力去探索，即使最后没有得到答案，在过程中你也会学到很多东西。

6. 多与别人交流

三人行必有我师，也许在一次和别人不经意的谈话中，就可以迸出灵感的火花。多上上网，看看别人对同一问题的看法，会给你很大的启发。

7. 良好的程式设计风格

注意养成良好的习惯，程式码的缩进编排、变量的命名规则要始终保持一致。大家都知道如何排除程式码中错误，却往往忽视了对注解的排错。注解是程式的一个重要组成部分，它可以使你的程式码更容易理解，而如果程式码已经清楚地表达了你的思想，就不必再加注解了，如果注解和程式码不一致，那就更加糟糕。

8. 韧性和毅力

这也许是“高手”和一般程式设计师最大的区别。A good programming is 99% sweat and 1% coffee。高手们并不是天才，他们是在无数个日日夜夜中磨练出来的。成功能给我们带来无比的喜悦，但过程却是无比的枯燥乏味。你不妨做个测试，找个 10000 以内的质数表，把它们全都抄下来，然后再检查三遍，如果能够不间断地完成这一工作，你就可以满足这一条。所以抄写也是一种加强记忆的良好方法!

这些是对程式设计师生涯的一点建议，希望能够给大家有所帮助。