Python的编程哲学

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Beautiful is better than ugly.
优美胜于丑陋。
Explicit is better than implicit.
明了胜于晦涩。
Simple is better than complex.
简单胜过复杂。
Complex is better than complicated.
复杂胜过凌乱。
Flat is better than nested.
扁平胜于嵌套。
Sparse is better than dense.
间隔胜于紧凑。
Readability counts.
可读性很重要。
Special cases aren’t special enough to break the rules.
即便假借特例的实用性之名,也不可违背这些规则。
Although practicality beats purity.
虽然实用性次纯度。
Errors should never pass silently.
错误不应被无声的忽略。
Unless explicitly silenced.
除非明确地沉默。
In the face of ambiguity, refuse the temptation to guess.
当存在多种可能,不要尝试去猜测。
There should be one– and preferably only one –obvious way to do it.
应该有一个 – 最好只有一个 – 明显的能做到这一点。
Although that way may not be obvious at first unless you’re Dutch.
虽然这种方式可能不容易,除非你是 Python 之父。
Now is better than never.
现在做比不做好。
Although never is often better than *right* now.
虽然过去从未比现在好。
If the implementation is hard to explain, it’s a bad idea.
如果这个实现不容易解释,那么它是个坏主意。
If the implementation is easy to explain, it may be a good idea.
如果这个实现容易解释,那么它或许是个好主意。
Namespaces are one honking great idea — let’s do more of those!
命名空间是一种绝妙的理念,我们应当多加利用。

閱讀他人的程式碼

下面是我用工具转换的简体版本。精简版在我的另一篇博文中:阅读开源程序的方法
读懂程式码,使心法皆為我所用
程式码是别人写的,只有原作者才真的了解程式码的用途及涵义。许多程式人心裡都有一种不自觉的恐惧感,深怕被迫去碰触其他人所写的程式码。但是,与其抗拒接收别人的程式码,不如彻底了解相关的语言和惯例,当成是培养自我实力的基石。对大多数的程式人来说,撰写程式码或许是令人开心的一件事情,但我相信,有更多人视阅读他人所写成的程式码為畏途。许多人寧可自己重新写过一遍程式码,也不愿意接收别人的程式码,进而修正错误、维护它们、甚至加强功能。这其中的关键究竟在何处呢?若是一语道破,其实也很简单,程式码是别人写的,只有原作者才真的了解程式码的用途及涵义。许多程式人心裡都有一种不自觉的恐惧感,深怕被迫去碰触其他人所写的程式码。这是来自于人类内心深处对于陌生事物的原始恐惧。

读懂别人写的程式码,让你收穫满满
不过,基于许多现实的原因,程式人时常受迫要去接收别人的程式码。例如,同事离职了,必须接手他遗留下来的工作;也有可能你是刚进部门的菜鸟,而同事经验值够了、升级了,风水轮流转,一代菜鸟换菜鸟。甚至,你的公司所承接的专案,必须接手或是整合客户前一个厂商所遗留下来的系统,你们手上只有那套系统的原始码(运气好时,还有数量不等的文件)。 继续阅读

一个阿里巴巴码农的六年回眸

10月 13 日,关于淘宝开放平台技术部分的分享看到有些同学留言说有这样的机会和环境是幸运的,的确在阿里这些年赶上了公司的发展,赶上了互联网技术的发展,是幸运 的,但是背后这个普通的人,从进入公司的低级程序员一步一步成长起来到底是怎么走过来的,也许可以让一些正在走的同学有值得思考的地方,我尽量少加一些自 己的收获在里面,因为每个人看到这些场景感到了什么那就是什么。

继续阅读