吐槽代码可维护性

写代码的时候要给维护留条后路，你可能永远不会想到或许有一天一个维护你代码的暴力偏执狂提着斧头找上你家门。不是开玩笑的！我这会正在磨斧头。

python语言因为弃掉了大括号，以缩进安排语句块，所以写出来的代码看着整洁、清晰。故从理论上来说，python代码的可维护性应该很好。

但是，事在人为。永远不要低估程序员的创造力以及离经叛道，事实上，他们任何事都能做出来。

乱七八糟的python代码和乱七八糟的C++、Perl、Java等一样难以维护，不要因为用的是python就有优越感。好的代码风格都略同，同样，糟糕的编码风格都一样平庸。所以整洁代码之道任重道远，从来没有免费的午餐！

因此，面对这样一团乱糟糟的东西，我们该怎么办？因为难以理解而辞职？还是在Twitter和日常日狗（Daily WTF）上当个键盘侠骂娘？到底该怎么办？有什么东西能拯救我这颗伤痕累累的心？

唯一解决途径：从我做起，从现在做起，编写具有良好风格的代码。什么样的风格算是良好的，这个自古没有定论，各种语言之间也千差万别。

因为代码风格而在Google和Stack Overflow上发起的各派混战自程序诞生之日起就没消停过，而且往往敌友难分，甚至恶语相向，论素质，不分中外，不论今古，各在伯仲。

但无论哪种风格，代码的最终目的是既要能运行还要可维护即让维护者轻易看明白到底干了个啥事。

为了能让维护者明白，我们可能给代码编写大量的注释文档，详尽的单元测试，并且每天保持review代码至少3遍，但是无论如何，要记住一句—代码为王。

虽然你以记叙文或议论文的方式编写了大量注释文档，但你的代码真的是按这个思路走的吗？你遵循了良好代码的设计理念了吗？

对于良好风格的代码，即使有错误，也很容易找到bug点。好风格代码大大减轻了自己和读者的认知负担。

一旦你get到了一门语言的编程风格，你将会把大部分时间花在理解代码能干什么上而不是纠结于“等等，为什么这家伙要在函数返回时用一个namedtuple而不是tuple”

如果你真正理解了该门语言的编程风格，那么，阅读道友的代码那就跟看小说一般，这就是所谓的志趣相投吧。

第一重境界，逐行浏览，为作者所使用的一些奇技淫巧而赞不绝口。

第二重境界，一目一个函数，视野在调用关系上，一眼看穿原作者写这些个小玩意的用意和目的，比如“嗯，对，打开一个文件，对文件内容做一个查重处理然后保存到一个sorted list里，最后以线程安全的方式生成一个giant report”。

第三重境界，浏览一遍代码就知道bug藏在哪怎么fix，哪里需要优化以及N多种优化方案。

当你达到第二重时，就可以下山维护一方和平了；如果达到了第三重，那就是华山之巅把剑论，武林道上话盟主之日了。

最后，python之禅要铭记在心，时时揣摩，昼夜参悟，达到融会贯通，最终无招胜有招。（可通过python 彩蛋import this打印出禅意。）

PEP 20 – The Zen of Python
by python的先驱、python之父Guido van Rossum的忠诚追随者、将为人民服务(BDFL’s guiding principles)牢记在心的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!

汉语翻译过来：

优美胜于丑陋（Python以编写优美的代码为目标）
明了胜于晦涩（优美的代码应当是明了的，命名规范，风格相似）
简洁胜于复杂（优美的代码应当是简洁的，不要有复杂的内部实现）
复杂胜于凌乱（如果复杂不可避免，那代码间也不能有难懂的关系，要保持接口简洁）
扁平胜于嵌套（优美的代码应当是扁平的，不能有太多的嵌套）
稀疏胜于拥挤（优美的代码有适当的间隔，不要奢望一行代码解决问题）
可读性很重要（优美的代码是可读的）
即便假借特例的实用性之名，也不可违背这些规则（这些规则至高无上）
不要包容所有错误，除非你确定需要这样做（精准地捕获异常，不写except:pass风格的代码）
当模棱两可时，不要尝试去猜测
而是尽量找一种，最好是唯一一种明显的解决方案（如果不确定，就用穷举法）
虽然这并不容易，因为你不是 Python 之父（这里的Dutch是指Guido）
做也许好过不做，但不假思索就动手还不如不做（动手之前要细思量）
如果你无法向人描述你的方案，那肯定不是一个好方案；反之亦然（方案测评标准）
命名空间是一种绝妙的理念，我们应当多加利用（倡导与号召）

最后奉上开山祖师Guido van Rossum的一字箴言：life is short , you need Python。（人生苦短，请用python—鲁迅翻译）。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
（内容同步更新到微信公众号python数学物理，微信号python_math_physics）