程序员版的凡客
现在“凡客诚品”的PS风已经成为了一场运动,详见这里:http://bigfools.com/2010/08/6634.html。这两天,公司内部要出期刊,正好下班没事,于是跟着这股网风,为公司的期刊做了一个插图,那些语句着实花了我很多时间。用PPT乱做的,希望大家喜欢。呵呵。
欢迎你留下你的版本,尤其是那些语句。
现在“凡客诚品”的PS风已经成为了一场运动,详见这里:http://bigfools.com/2010/08/6634.html。这两天,公司内部要出期刊,正好下班没事,于是跟着这股网风,为公司的期刊做了一个插图,那些语句着实花了我很多时间。用PPT乱做的,希望大家喜欢。呵呵。
欢迎你留下你的版本,尤其是那些语句。
以前本站发布过《22条经典的编程引言》、《编程引言补充》、《Linus Torvalds 语录》还有《十条不错的编程观点》。今天向大家介绍“最佳编程语录”,条条都是很不错的语录,如同我们的太阳,照亮了我们的方向(所以我们选用了一个红色的图片,希望能够通过五毛们的网络审查)。其中只有一两条在以前本站发布过的文章中出现过。这篇文章的出处在这里,下面是“Neo”和“陈皓”的翻译,我们的翻译水平有限,所以,我们提供了中英文对照,有不当之处,还请各位指正。
A good programmer is someone who looks both ways before crossing a one-way street. — Doug Linder, systems administrator
好的程序员这样一类人,这类人在横穿一条单行道前都要先看一下路两边。– Doug Linder, 系统管理员
A most important, but also most elusive, aspect of any tool is its influence on the habits of those who train themselves in its use. If the tool is a programming language this influence is, whether we like it or not, an influence on our thinking habits. — Edsger Dijkstra, computer scientist
关于工具,一个最重要的,也是最不易察觉的方面是,工具对使用此工具的人的习惯的潜移默化的影响。如果这个工具是一门程序语言,不管我们是否喜欢它,它都会影响我们的思维惯式。 –Edsger Dijkstra, 著名的计算机科学家。
Being abstract is something profoundly different from being vague… The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. — Edsger Dijkstra
抽象和模糊完全地不同,抽象的目的并不是把事情变模糊,而去创建一个新的语义层,在那里是绝对精确的描述。 — Edsger Dijkstra
Besides a mathematical inclination, an exceptionally good mastery of one’s native tongue is the most vital asset of a competent programmer. — Edsger Dijkstra
除了数学爱好,对于一个有能力的程序员来说,出色地掌握自己的母语是最宝贵的财富。– Edsger Dijkstra
对我来说,一个好的程序员应该是努力去追求尽可能无错的高质量的符合需求的代码实现。 一些人也许认为好的程序员是那些懂得多门编程语言,懂得很牛技术的程序员,是的,这在某些情况下是对的。但归根到底,无论你用什么样的技术,什么样的语言,所有的程序被写出来,其功能都要符合需求以及尽可能地健壮无错和高质量。 我们可以想像一下,如果一个能力普通的程序员有足够多的时间来做测试,那么,其也可以保证他的代码的质量。所以,有一种观点这样认为——要达到质量高的代码只需要有足够多的时间来做测试。这对于以结果为导向的商业软件开发中是可以理解的(我们可以看到那些制汽车的产商在汽车测试上花费的精力和时间就可以明白这一道理)。
但是,很明显,所有的已经开发出来项目都是在不完美的条件下开发出来的,一般来说,几乎所有的项目都是在最大化程序员软件的开发速度。而且,很多情况下,我们似乎对深度测试和压力测试并不是很关心,所以,我们总是在祈祷并期望那些赶工出来的代码可以正常工作,尤其是在上线的时候,这种唯心主义的价值观更为强烈。 其实,开发速度和软件产品质量并不矛盾。好的程序员并一定是技术强的程序员,而是那些可以在不完美的工作环境下保证软件质量和工作效率的程序员。下面是是五个程序员可以在这种不完美的情况下做得更好的观点(它们都和语言和技术没什么关系,只不过是一种你的工作行为,能够和所有的行业相通),这五个观点也许可以让你成为这样的好程序员。
黑客,可能在大家的眼里是那些入侵别人计算机搞破坏的人,其实并不是那样的。如果你这样认为了,只能说明你对计算机文化并不了解,真正的黑客是一种自由的象征,他们挑战权威,追求自由,并和很多非人类的行为作斗争。如果你想了解黑客文化,你一定要去看看我写的《Unix传奇,上篇,下篇》。你会对正宗的计算机文化以及黑客文化有所了解的。而那些只懂得入侵别人计算机搞破坏活动的“黑客”只能称为是街头的小混混,他们根本就不配称黑客。
下面有四篇关于“Hacker’s Code”文章,我觉得相当的不错,可以让你明白什么是黑客的行为规范,道德准则,以及黑客的历史使命,希望能对你有启发。但是翻译水平有限,所以我请Mailper同学帮忙翻译了一下,但还是觉得原文更为传神,尤其是原文中的押韵,双意以及朗朗上口,所以,下面提供了中英文对照。如果有翻译得不好的还请大家指正。
http://muq.org/~cynbe/hackers-code.html
“A hacker of the Old Code.”
在Stack Overflow上有这样的一个贴子《What’s your most controversial programming opinion?》,翻译成中文就是“你认为最有争议的编程观点是什么?”,不过,在400多个主回贴,以及千把个子回贴中,好像并不是很有争议,而是令人相当的茅塞顿开,下面罗列一些,并通过我自己的经历和理解发挥了一些,希望对你有帮助。
1) The only “best practice” you should be using all the time is “Use Your Brain”.
唯一的“Best Practice”并不是使用各种各样被前人总结过的各种设计方法、模式,框架,那些著名的方法、模式、框架只代码赞同他们的人多,并不代表他们适合你,你应该更多的去使用你的大脑,独立地思考那些方法、模式、框架出现的原因和其背后的想法和思想,那才是“best practice”。事实上来说,那些所谓的“Best Practice”只不过是限制那些糟糕的程序员们的破坏力。
2)Programmers who don’t code in their spare time for fun will never become as good as those that do.
如果你对编程没有感到一种快乐,没有在你空闲的时候去以一种的娱乐方式去生活,无论是编程,还是运动,还是去旅游,那么你只不过是在应付你的工作,无时无刻不扎在程序堆中,这样下来,就算是你是一个非常聪明,非常有才华的人,你也不会成为一个优秀的编程员,要么只会平平凡凡,要么只会整天扎在技术中成为书呆子。当然,这个观点是有争议,热情和能力的差距也是很大的。不过我们可以从中汲取其正面的观点。
3)Most comments in code are in fact a pernicious form of code duplication.
注释应该是注释Why,而不是How和What,参看《惹恼程序员的十件事》,代码告诉你How,而注释应该告诉你Why。但大多数的程序并不知道什么是好的注释,那些注释其实和code是重复的,毫无意义。
在某个论坛上看到有人在问——“Which programming language should I learn first?”,看到了下面的这个回答,有点意思。
Depends.
- To program in an expressive and powerful language: Python
- To get a website up quickly: PHP
- To mingle with programmers who call themselves “rockstars”: Ruby.
- To really learn to program: C.
- To achieve enlightenment: Scheme.
- To feel depressed: SQL
- To drop a chromosome: Microsoft Visual Basic
- To get a guaranteed, mediocre, but well paying job writing financial applications in a cubicle under fluorescent lights: Java.
- To do the same thing with certifications and letters after your name: C#
- To achieve a magical sense of childlike wonder that you have a hard time differentiating from megalomania: Objective C
I could go on… but I’m not feeling hateful enough today.
翻译如下:
学习C++很长时间了,也看过很多程序员学习C++的历程。总体来说,C++是一个“双刃剑”式的语言,只有那些熟悉他的人才能把C++这门语言用好。Linus曾说过:“C++是一门很恐怖的语言,而比它更恐怖的是很多不合格的程序员在使用着它”。是的,C++并不是一门速成的语言,其是一门需要长时间磨练和学习的语言,那些说自己熟悉C++语言的程序只能算是轻浮的。详见“21天教你学会C++ ”。
下面是一个C++程序员在学习过程序中的一个自信心曲线图:
程序员在一开始学习C++的时候,用C++的语法写C觉得很牛,也会觉得自己很快掌握了C++语言,对一切都充满了信心。他们告诉你他们懂C++,其它他们错误,但我们不能说他们在撒谎,因为人总是不知道自己不知道什么。此后,当他们在C++的学习历程中,发现了很多很多稀奇古怪的东西,还有很多相当底层和复杂的东西,他们的将会变得很受挫,很沮丧,还始变得怀疑起,自信心开始下降,甚至有时候他们靠人品来编程。只到有一天,开始开窃,觉得C++的世界不能乱来,需要一定的规则,一定的方法,于是通过大量的错误不停地总结和反省,最终自信心又会被建立起来,经历多年的历练后,才能恢复自信。
对于大多数的自称自己熟悉C++的程序员来说,基本上来说他们都是用C++的语法来写C。
下面是一个《Teach Yourself C++ in 21 Days》的流程图,请各位程序员同仁认真领会。如果有必要,你可以查看这个图书以作参照:http://www.china-pub.com/27043
看完上面这个图片,我在想,我学习C++有12年了,好像C++也没有学得特别懂,看到STL和泛型,还是很头大。不过,我应该去考虑研究量子物理和生物化学,这样,我才能重返98年杀掉还在大学的我,然后达到21天搞定C++的目标。另外,得要特别提醒刚刚开始学习C++的朋友,第21天的时候,小心被人杀害。呵呵。
当然,上面只是一个恶搞此类图片,学习一门技术,需要你很长的时间,正如图片中的第三图和第四图所示,你需要用十年的时间去不断在尝试,并在错误中总结经验教训,以及在项目开发中通过与别人相互沟通互相学习来历练自己。你才能算得上是真正学会。
这里有篇文章叫《Teach Yourself Programming in Ten Years》,网上有人翻译了一下,不过原文已被更新了,我把网上的译文转载并更新如下:
在过去的N年中,我遇到了很多使用囧然不同风格的开发者,下面是我所知道的一些,你还知道其它的吗?
这种编程风格是一种开发者使用非常随意的方式对待代码。“嗯,这个方法调用出错了……那么我会试着把传出的参数从 false 变成 true!”,当然依然出错,于是我们的程序员会这样:“好吧,那我就注释掉整个方法吧”,或是其它更为随意的处理方式,直到最后让这个调用成功。或是被旁边的某个程序员指出一个正确的方法。
如果我们把一个正规的程序员和一个撞大运的程序员放在一起做结地,那么,那个正规的程序可以马上变得发疯起来,并且,可以把正规的程序员的智商降到最低。两个撞大运的程序员不应该在一起做结对编程,这是因为他们破坏性的才能会造成的伤害会比只有一个还差。
这是一种比散弹枪编程要温和一些的编程方式,我相信这种方式可能会是大多数程序员都会使用的方式。这种编程方式经常出现于程序员并不确切知道他们在干什么,也不知道所写的程序的本质和实际,但是可以让程序工作起来。他们以一种撞大运的方式在写程序,某些时候,他们根本就不知道某个错误的原因,就开始稀里糊涂地修改代码。一旦出现问题,他们会用两条路:1)停下来,理解一下程序,找到出错的原因。2)使用散弹枪编程方式开始解决问题。
测试驱动开发(Test Driven Development)是一种可以用来拯救上百万的撞大运编程的程序员。于是,他们有了一个更为NB的借口:只要我的程序通过测试了,你还有什么话好说?别骂我,测试驱动开发是一个不错的事物,其主要是用来控制撞大运开发所带来的问题。
下图是一个搞笑的图片——程序员眼中的编程语言。
比如说,
其它的大家自己看吧。还有另外一个关于操作系统的《粉丝眼中的操作系统》