标签归档:程序员

程序员经典幽默之恶搞对联

看了文章的标题,各位程序员千万别误会,程序员这种死板的生物怎么可能会写对联。下面的这些对联都非常有趣,看到别人这样恶搞自己也不免会淡淡的一笑,哎,苦逼的程序员。

对联一

上联:受苦受累起得比鸡还早。

下联:累死累活干得比驴还多。

横批:禽兽不如。

对联二

上联:一个项目两部电脑三餐盒饭之为四千工资搞得五脏俱损六神无主仍然七点起床八点开会处理九个漏洞十分辛苦。

下联:十年编码九年加班八面无光忙的七窍生烟到头六亲不认五体投地依旧四肢酸软三更加班只为两个臭钱一身孤苦。

横批:苦逼程序员。

对联三

上联:为系统而生,为框架而死,为debug奋斗一辈子!

下联:吃符号的亏,上大小写的当,最后死在需求上!

横批:杯具程序员。

对联四

上联:这个其实很简单。

下联:原理细节我不管。

横批:立马上线。

对联五

上联:我这儿没干啥它自己就好了。网络这事吧不明觉厉。

下联:你那儿不行吗我运行正常呀!需求想改呀十动然拒。

横批:细思恐极

对联六

上联:足不出户一台电脑打天下

下联:窝宅在家两只巧手定乾坤

横批:我最碉堡

 

IT旅途——程序员面试经验分享

http://www.csdn.net/article/2013-05-09/2815198-programmer-interview

摘要:本文从IT人员的角度,一起分享面试道路上的坎坷。文章汇集几个知名公司的面试题,从出题的角度到分析问题的方法到解决问题较为全面的讲解面试题目,以供读者参考。

面试是职场的永恒话题,如何在职场面试中脱颖而出,获得心仪职位?这里搜集了关于面试经验的热文,其中汇集了阿里巴巴、百度、微软几个知名公司的面试题以及部分答题方法、技巧、面试的心得体会,供读者参考。
[1] 教你如何迅速秒杀掉:99%的海量数据处理面试题

本文分成两部分。第一部分、从set/map谈到hashtable/hash_map/hash_set,简要介绍下set/map/multiset/multimap,及hash_set/hash_map/hash_multiset/hash_multimap之区别(万丈高楼平地起,基础最重要),而本文第二部分,则针对上述那6种方法模式结合对应的海量数据处理面试题分别具体阐述。

[2] 百度最新面试题集锦

最新的面试题集有时也代表公司近来的研发方向甚至科研趋势,这里,博主收集了一些百度最新的面试题集,其中有较为有趣的试题,

比如:
蚂蚁爬杆问题:
有一根27厘米长的细木杆,在第3厘米,7厘米,11厘米,17厘米,23厘米这五个位置上各有一只蚂蚁,木杆很细,不能同时通过两只蚂蚁,开始时,蚂蚁的头朝向左还是右是任意的,他们只会朝前走或掉头,但不会后退,当两只蚂蚁相遇后,蚂蚁会同时掉头朝反方向走,假设蚂蚁们每秒钟可以走1厘米的距离。求所有蚂蚁都离开木杆的最小时间和最大时间。
答案:
两只蚂蚁相遇后,各自掉头朝相反方向走。如果我们不考虑每个蚂蚁的具体身份,这和 两只蚂蚁相遇后,打个招呼继续向前走没有什么区别。
所有蚂蚁都离开木杆的最小时间为
max(min(3,27-3),min(7,27-7), min(11,27-11), min(17,27-17),min(23,27-23))=11
所有蚂蚁都离开木杆的最大时间为
max(max(3,27-3),max(7,27-7), max(11,27-11), max(17,27-17),max(23,27-23))=24

三个警察和三个囚徒的过河问题:
三个警察和三个囚徒共同旅行。一条河挡住了去路,河边有一条船,但是每次只能载2人。存在如下的危险:无论在河的哪边,当囚徒人数多于警察的人数时,将有警察被囚徒杀死。问题:请问如何确定渡河方案,才能保证6人安全无损的过河。
答案:
第一次:两囚徒同过,回一囚徒
第二次:两囚徒同过,回一囚徒
第三次:两警察同过,回一囚徒一警察(此时对岸还剩下一囚徒一警察,是安全状态)
第四次:两警察同过,回一囚徒(此时对岸有3个警察,是安全状态)
[3] 阿里巴巴的面试

博主在文中指出,进入技术面试之前,先要做一套相应的试题,这里面涉及到平常不怎么注意的问题:
一是没有定义访问范围的构造函数,前面未加public、protected或private限制等,默认protected,编译会报错;

二是页面中定义两个同名的JS函数,调用会是什么结果,后面尝试了一下不报错,会调用第二个方法;
[4]苹果面试8大难题及答案

苹果这样的公司通常会在面试过程中向求职者抛出一些逻辑的问题来考研面试者,所以,如果你对进入苹果感兴趣,或者只是对逻辑问题感兴趣,这些面试难题值得你仔细研究。

比如:
“逻辑学家们围成一圈坐着,他们的额头上面画有数字……”又来一个逻辑学家围成一圈的问题,这次是这样的,三个拥有完美逻辑推理能力的人围成一圈坐在一个房间里,每个人的额头上都画着一个大于0的数字,三个人的数字各不相同,每个人都看得见其他两个人的数字,看不见自己的。
这三个数字的情况是,其中一个数字是其他两个数字的和,已知的情况还有,其中一个逻辑学家的数字是20,一个是30。游戏组织者从这三个逻辑学家后面走过,并问三个人各自额头上的数字是什么。但第一轮每个逻辑学家都回答他们无法推测自己的数字是什么。游戏组织者只好进行第二轮的发问,这是为什么?你能据此猜出三个逻辑学家的数字吗?

[5]12个有趣的C语言面试题

12个C语言面试题,涉及指针、进程、运算、结构体、函数、内存等内容,比如:
内存泄露:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
1.  #include<stdio.h>
2.  
3.  void func(void)
4.  {
5.      printf("\n Cleanup function called \n");
6.      return;
7.  }
8.  
9.  int main(void)
10. {
11.     int i = 0;
12. 
13.     atexit(func);
14. 
15.     for(;i<0xffffff;i++);
16. 
17.     _exit(0);
18. }

这是因为_exit()函数的使用,该函数并没有调用atexit()等函数清理。如果使用atexit()就应当使用exit()或者“return”与之相配合。

[6]Java程序员面试中的多线程问题

这篇文章收集了 Java 线程方面一些典型的问题,

比如:
为什么需要 run ()和 start ()方法,我们可以只用 run ()方法来完成任务吗?
我们需要 run ()&start ()这两个方法是因为 JVM 创建一个单独的线程不同于普通方法的调用,所以这项工作由线程的 start 方法来完成,start 由本地方法实现,需要显示地被调用,使用这俩个方法的另外一个好处是任何一个对象都可以作为线程运行,只要实现了 Runnable 接口,这就避免因继承了 Thread 类而造成的 Java 的多继承问题。

[7]设计模式大集锦 程序员面试全攻略

无论你是参与Java面试还是C#面试,设计模式和软件设计问题在程序员面试中是必不可少的一部分。本文总结了在各种面试过程中经常被提及的一些设计问题。文中分为两部分,一类为初学者,另一类专为中高级技术人员准备。

[8]如何在面试时写出高质量的代码

如何在面试时能写出高质量的代码,是很多程序员关心的问题。作者总结自己多年面试他人以及被他人面试的经验,发现应聘者可以从代码的规范性、完整性和鲁棒性三个方面提高代码的质量。

[9]编程技术面试的五大要点

编程面试是程序员面试过程中最为重要的一个环节,其中主要关注应聘者五种素质:

(1)扎实的基础知识

(2)能写高质量的代码

(3)分析问题时思路清晰

(4)能优化时间效率和空间效率

(5)具备包括学习能力、沟通能力、发散思维能力等在内的综合能力。

[10] 谈谈对于技术面试的心得体验

博主在文中谈到,一个公司的技术面试需要有良好的经验传承,不光光只是留来一些题库;也不光光是一句要相互尊重,你代表公司的形象;更重要的如何去主导一场面试,全面、准确的了解对方的能力。一般情况下,软件公司招人总会对这三个方面的能力做一下考核,一是编程语言,二是数据结构与算法,三是系统设计。

延伸阅读: 编程技术面试的五大要点

华为的JAVA面试题及答案(部分)

IT求职经验总结——面试和准备策略

程序员成熟的标志

http://www.cnblogs.com/n216/archive/2011/05/16/2047327.html

程序员在经历了若干年编程工作之后,很想知道自己水平到底如何?自己是否已经成为成熟的程序员?虽然程序员会对自己有一个自我评价,但是,自己的评价和社会的评价、专业的评价会有差异,所以程序员自己并不能肯定这个评价。现实中,除了各种证书之外,很少有人会专门给出一个程序员的成熟度的评价。人们往往是偶发性地就事论事地对程序员的工作作出好与不好,行与不行的评论。因此,程序员对此感到很茫然,不知道要从那些方面去评价自己的能力。

一个程序员到底成熟不成熟,我想从以下几个方面谈谈自己的看法。

1、技术标志

如果程序员不会编程序那决不是程序员,程序员至少要掌握一门程序设计语言,要能够用这种语言去编写程序去解决他想解决的问题。但是,成熟的程序员往往掌握不止一种程序语言,三到四种语言的掌握是必须的,一种二种语言的精通也是必须的。

除了从掌握程序设计语言个数之外,我们还可以从其他几个方面去看看程序员在技术上水平。例如,函数编写能力(命名、格式、大小、分类、参数、复用等),面向过程的能力,面向对象的能力,数据库技术能力,效率处理能力,安全处理能力,网络处理能力,软件构架能力,人机交互能力,通用软件能力,软件文档能力等等。尤其是面向对象技术的掌握和运用,以及面向服务的技术都是成熟程序员所必需掌握的。

    2、时间标志

虽然程序员的天资、素质、基础知识各不相同,所经历的工作内容以及环境也不相同,但是,时间也是程序员成熟程度的标志之一。一般程序员需要经过三到五年的时间才能日趋成熟。其中入门需要一年,成长需要两年。这是我经过长期观察得到平均数据。我并不认为成熟时间越短程序员就越聪明,就越了不起。享受每个阶段充分的时间,会让自己成长更加充实、更加成熟。当然,也有超期而不成熟的情况,这也是很正常的。

    3、项目标志

程序员的社会性是程序员成熟的标志之一。没有参加过项目的程序员,程序编得再好,只能是纯程序类的程序员,是一个孤独的高手,是一种个人型的程序员,远没有成熟。项目作为社会性活动,体现了项目的社会价值。所以项目能力也是程序员成熟的重要标志之一:项目能力包括参加项目的个数、项目的大小、在项目中承担的角色等等。就项目承担的角色而言,主持开发(项目经理)3个以上项目是必须的,这是一个必要条件。一个程序员如果没有主持过开发,无论参加过多少项目的开发,无论是在程序编写或项目设计上发挥了多大的作用,是很难被称之为成熟的,因为项目的组织、协调和管理是反映一个程序员成熟程度的又一个标志。就如同一个程序员能参与过10个以上大大小小的项目或能参加或能主持两个以上大型项目的开发,其成熟程度是可以信赖的。若低于此数,则说明程序员离成熟还有相当的空间。“我们在项目中成长”可见项目对于程序员的意义是多么的巨大。

另外,一般程序员只是为一个企业客户进行开发一个或多个项目,或同行业的企开发项目,如果程序员能够如果程序员能够开发过多个行业的项目,其成熟度要比一般人要高一些。

    4、思维标志

幼稚和成熟在思维方式上还是有很明显的区别的。就程序员而言,不成熟的程序员逻辑性不强,程序编得没有条理,即使程序员自己进行了解释也没人能看懂。而成熟的程序员应该具有很强的逻辑性,程序编得井井有条,不用解释别人也能看得懂。这种逻辑性还体现在软件的构架设计、数据库设计、算法设计等多个方面。程序员通过全集子集概念、时间概念、顺序概念、重点非重点概念等对各种事物进行逻辑分析。例如,以顺序概念为例,不成熟的程序员往往会采用自底向上的思维方式来开发程序。他们先考虑程序的具体实现,然后再考虑功能设计、最后考虑构架设计。而成熟的程序员则采用自顶向下思维方式,先考虑构架设计、再考虑功能设计、最后才考虑编程的具体实现。前者思维方式主要是出于工作惯性,只适合入门阶段,而后者思维方式反映了后者的进步,适用于各种项目开发或大型项目的开发。

除了在思维内容上的逻辑性之外,程序员还应该处理好动脑和动手的关系。重视思维本身就是一种成熟的标志。成熟的程序员的思考时间要大于动手编程时间,想好之后只要一次就编程成功,而不成熟的程序员往往动手编程时间要远大于思考时间,而且是边做边想,通过反复来逼近最终目标。

另外,在思维范围上,成熟的程序员要比普通的程序员有更开放视野。他们更容易去接受新的东西,更容易不受各种约束去考虑问题,更勇于去挑战自己和高手。

 5、与人交往

很多人认为程序员是和计算机打交道的行业。这只是这个职业的特点。但是,只要是工作必然就是一种社会劳动。而社会劳动则必须和人进行交流和沟通。尽管程序员的劳动工具是计算机,但并不意味着程序员只想着这个工具。从这个工具的下游来看,程序员还是要考虑用这个劳动工具生产出来的软件产品是否有人购买,是否有人使用,是否运行正常,从这个工具的上游来看,是谁让程序员了解设计方案的,是谁让程序员编程序的,是谁让程序员程序通过验收的等等。因此程序员在软件制作各个环节都会与其他人打交道。只有和人进行有效的交流和沟通我们的工作才能进行下去才能做的更好。

如果一个程序员还沉浸在个人劳动的意境之中,对外界持有冷漠、无奈、恐惧的心理,内心里不愿意和外界打交道,无论自己感觉自己的技术水平有多高,还是一个不成熟的程序员。而成熟的程序员一定是特别重视与人的交往,无论是上级领导、外部客户、项目经理、团队同伴这些与自身工作密切相关的人还是那些非同单位同行朋友、网友等他们都会认真去听取别人的阐述、要求、意见、建议、反馈等。从中得到更多的工作上的、技术上的、生活上的好的想法,以便自己参考和吸收。与此同时,与人交往也反映你有好的想法和好的技术水平交流出去,而这些想法和技术水平也是你成熟度一种反映。那些没有想法和技术水平的程序员的确是怕和别人交流的。

与人交流的有两个基本能力,一个是理解能力,一个是表达能力。两者缺一不可。例如,有的程序员理解能力差,不能理解项目经理提出的要求,有的程序员表达能力差,无逻辑,无重点,啰里啰唆,让别人不知所云。这都是不成熟的表现。

   6、别人评价

别人的评价尤其是单位同事以及对自己工作情况比较了解的人对自己的评价是有参考价值的。一般而言,评价差的,一定是不行的,是不成熟的。评价好的要看情况而定,单位同事对人的评价会从两个方面来考虑,一个是这个人的为人情况,一个是这个人的工作能力。如果两者都不错,我们有理由认为这个程序员是成熟的。反之,无论是工作能力强,但为人不好,为人很好,工作能力不强,我看都不能算一个成熟的程序员。

所以,程序员要注重别人对自己的评价,在提高自己技术水平的同时,学会做人,做好人,学会与他人分享,这样别人才会给自己更好的评价。

无视别人评价其实,也是一种不成熟的表现。只有自己感觉好,大家感觉好,那才是真的好。

其实,别人的评价如果仅限于自己单位的话,恐怕这种评价的价值会打折扣,如果这个单位技术人员的人数很少,水平普遍很低,即使你鹤立鸡群,大家对你的评价很好,但是,你和其他公司和单位的程序员来比,你真的不一定的成熟。所以,我说别人的评价仅仅是一个参考。

   7、收入标志

收入也是成熟程序员一个参考标志。收入的大小往往是对程序员社会价值的认可度,表明程序员的劳动值这个价钱。一般而言,成熟的程序员能够挣得软件业平均收入的中上水平,或者在一个单位或部门中能够挣得比80%左右员工要高的收入。而刚参加工作不久的程序员收入应该与其相差很大的。另外,单位的项目奖金发放也可以看出程序员在项目中的地位和作用。

现实中,我们知道程序员的收入和其付出是不是正比的,而且,越是能力强的、贡献大的程序员,可能不一定比那些不如其它能力不如他的程序员高出许多。这不是软件行业的通病,几乎所有行业都存在这种情况。通过分析我们认为程序员成熟度应该是和其收入高低挂钩的。如果,我们知道我们能力和贡献大大超出我们的收入,我们就有理由向上级领导提出自己的收入要求。

   8、心理素质

程序员常常面对各种各样的成功和失败,尤其是失败更是多于成功,这也是程序员这个职业特点之一。以编程为例,几乎没有一个人一次就能把程序给编好的,它总是要遇到各种语法错误,总要遇到各种遗漏,一个程序要反复多次修改调试才能完好。有的程序员因找不出来程序的bug,束手无措,哀声叹气,心里极其不爽。以工作为例,有的程序员因工作进度和程序出错常常受到别人的批评和指责,心里极其不满,认为批评人不了解造成这个结果的客观原因,批评错了人。从而对人产生意见,甚至对工作造成了影响。面对失败和挫折,成熟的程序员会坦然面对:编程时出现问题不可怕,有什么问题就解决问题,解决不了的问题可以想其他方法进行解决,不在一棵树上吊死。面对别人的批评和指责,首先从自身查问题,是自己的问题,那就要主动承担责任,并尽快改正。不是自己的问题,应该换位思考,理解批评人的焦急心态,并找机会给予说明。良好的心理素质在面对困难和挫折的时候,就会很坦然,很坚强,很自信。

程序员也会面对成功的。有些程序员因开发了某个项目,因编写了某个程序而感觉良好,在不自觉中表现出我最牛,我最好的样子,面对他人夸夸其谈,而对其他人不屑一顾。而更有甚者并其无成果,表现平平,却依然会摆出一个高手的样子,有的仅仅参与了某个项目,而且不是项目主要开发者,却会贪天之功,归其所有,好像这个项目是他主持开发的。这些其实也是心理素质不成熟的另一种表现。成熟的程序员面对成功并不会感觉到高人一等,该是自己的功劳就是自己的功劳,该是别人的功劳就是别人的功劳,即使自己比别人水平高出许多,他还是在想还有更高的技术顶峰等待攀登,不可自傲,看到别人取得的成绩首先感到去祝贺,然后去学习,而不是心怀嫉妒,从中挑刺,尽量贬低。

良好的心理素质使得程序员更加理性地处理好各种成功和失败带来的各种问题,更有利于程序员超越自我,以平常之心去迎接更大的挑战。

当然一个程序员是否成熟是一个仁者见仁,智者见智的话题。有的人强调程序员的个人能力方面,有的人强调是程序员的社会能力方面。我认为从以上8个方面综合地去评判一个程序员是否成熟应该能说明些问题了。我们标志成熟,一个目的是对程序员前面成长过程给与一个肯定和鼓励,让程序员认清自己的所处的阶段,让自信找出依据。另外一个目的是对程序员未来成长提出更高的要求。走向优秀是程序员面临的更大的挑战。

10步让你成为更优秀的程序员

作者: Paul Firth  来源: 外刊IT评论  发布时间: 2013-01-01 20:29  阅读: 11031 次  推荐: 89   原文链接   [收藏]  

  英文原文:10 steps to becoming a better programmer

这篇文章要介绍的,是我作为专业程序员这些年来学到的能真正提高我的代码质量和整体工作效率的 10 件事情。

1. 永远不要复制代码

不惜任何代价避免重复的代码。如果一个常用的代码片段出现在了程序中的几个不同地方,重构它,把它放到一个自己的函数里。重复的代码会导致你的同事在读你的代码时产生困惑。而重复的代码如果在一个地方修改,在另外一个地方忘记修改,就会产生到处是 bug,它还会使你的代码体积变得臃肿。现代的编程语言提供了很好的方法来解决这些问题,例如,下面这个问题在以前很难解决,而如今使用 lambda 却很好实现:

/// <summary>
/// 一些函数含有部分重复代码
/// </summary>
void OriginalA()
{
    DoThingsA();
    // unique code
    DoThingsB();
}
/// <summary>
/// 另外一个含有部分重复代码的函数
/// </summary>
void OriginalB()
{
    DoThingsA();
    // 没有重复的代码
    DoThingsB();
}

现在我们重构含有部分相同代码的函数,用 delegate 模式重写它们:

/// <summary>
/// Encapsulate shared functionality
/// </summary>
/// <param name="action">User defined action</param>
void UniqueWrapper(Action action)
{
    DoThingsA();
    action();
    DoThingsB();
}
/// <summary>
/// New implmentation of A
/// </summary>
void NewA()
{
    UniqueWrapper(() =>
    {
        // unique code
    });
}
/// <summary>
/// New implementation of B
/// </summary>
void NewB()
{
    UniqueWrapper(() =>
    {
        // unique code
    });
}

2. 留意你开始分心的时候

当你发现自己在浏览 facebook 或微博,而不是在解决问题,这通常是一种你需要短暂休息的信号。离开办公桌,去喝一杯咖啡,或去跟同事聊 5 分钟。尽管这样做看起来有点反直觉,但长久去看,它会提高你的工作效率。

3. 不要匆忙赶任务而放弃原则

当带着压力去解决一个问题或修改一个 bug,你很容易失去自制,发现自己匆匆忙忙,甚至完全忘了一直坚持的重要的测试过程。这通常会导致更多的问题,会让你在老板或同事眼里显得很不专业。

4. 测试你完成的代码

你知道你的代码能做什么,而且试了一下,它确实好用,但你实际上需要充分的验证它。分析所有可能的边界情况,测试在所有可能的条件下它都能如期的工作。如果有参数,传递一些预期范围外的值。传递一个 null 值。如果可能,让同事看看你的代码,问他们能否弄坏它。单元测试是到达这种目的的常规方法。

5. 代码审查

提交你的代码之前,找个同事一起坐下来,向他解释你做了哪些修改。通常,这样做的过程中你就能发现代码中的错误,而不需要同事说一句话。这比自己审查自己的代码要有效的多得多。

6. 让代码更少

如果你发现写了大量的代码来解决一个简单的问题,你很可能做错了。下面的 boolean 用法是一个很好的例子:

if (numMines > 0)
{
   enabled=true;
}
else
{
   enabled=false;
}

这时你应该写成这样:

enabled = numMines > 0;

代码越少越好。这会使 bug 更少,重构可能性更小,出错的几率更小。要适度。可读性同等重要,你可不能这样做而使代码丧失可读性。

7. 为优雅的代码而努力

优雅的代码非常的易读,只用手边很少的代码、让机器做很少的运算就能解决问题。在各种环境中都做到代码优雅是很难的,但经过一段时间的编程,你会对优雅的代码是个什么样子有个初步的感觉。优雅的代码不会通过重构来获得。当你看到优雅的代码是会很高兴。你会为它自豪。例如,下面就是一个我认为是优雅的方式来计算多边形面积的方法:

static public double GetConvexPolygonArea (Vector2[] vertices)
{
    double area = 0;
    for (int i = 0; i < vertices.Length; i++)
    {
        Vector2 P0 = vertices[i];
        Vector2 P1 = vertices[(i + 1) % vertices.Length];
        area += P0.Wedge (P1);
    }
    return area / 2;
}

8. 编写不言自明的代码

勿庸置疑,注释是编程中很重要的一部分,但能够不言自明的代码更胜一筹,因为它能让你在看代码时就能理解它。函数名变量名要慎重选择,好的变量/方法名字放到语言语义环境中时,不懂编程的人都能看懂。例如:

void DamagePlayer (Player player, int damageAmount)
{
    if (!player.m_IsInvincible && !player.m_IsDead)
    {
        player.InflictDamage ( damageAmount );
    }
}

能自我说明的代码不能代替注释。注释是用来解释“为什么”的,而自我说明的代码是来描述“是什么”的。

9. 不要使用纯数字

直接把数字嵌入代码中是一种恶习,因为无法说明它们是代表什么的。当有重复时更糟糕——相同的数字在代码的多个地方出现。如果只修改了一个,而忘记了其它的。这就导致 bug。一定要用一个命名常量来代表你要表达的数字,即使它在代码里只出现一次。

10. 不要做手工劳动

当做一系列动作时,人类总是喜欢犯错误。如果你在做部署工作,并且不是一步能完成的,那你就是在做错事。尽量的让工作能自动化的完成,减少人为错误。当做工作量很大的任务时,这尤其重要。

11. 避免过早优化

当你要去优化一个已经好用的功能代码时,你很有可能会改坏它。优化只能发生在有性能分析报告指示需要优化的时候,通常是在一个项目开发的最后阶段。性能分析之前的优化活动纯属浪费时间,并且会导致 bug 出现。

好吧,我说是 10 个,但你却得到了额外赠送的一个!

这些就是我要说的,我希望它们能帮助你改进编程开发过程。

下次再见!祝快乐!

Cheers, Paul.

摘自:http://kb.cnblogs.com/page/168183/