推荐学习书目 Learn Python the Hard Way Python Sites PyPI - Python Package Index http://diveintopython.org/toc/index.html Pocoo 值得关注的项目 PyPy Celery Jinja2 Read the Docs gevent pyenv virtualenv Stackless Python Beautiful Soup 结巴中文分词 Green Unicorn Sentry Shovel Pyflakes pytest Python 编程 pep8 Checker Styles PEP 8 Google Python Style Guide Code Style from The Hitchhiker's Guide
这是一个创建于 4334 天前的主题，其中的信息可能已经有所发展或是发生改变。
http://blog.est.im/post/69161031446
非常有意思的一个讨论
引用：“任何流程，任何规范，任何review，任何代码检查工具，都阻止不了程序员缓慢地一点一点地滥用语言特性，也阻止不了一个软件代码自身的腐败。Python本身鼓励滥用Mock因为没有不用mock就可以方便写unit test的测试工具。Python还鼓励不定义清晰的类接口和类关系，如果你写了一个接口继承，就会有Python大牛跳出来说你不Pythonic。系统复杂性在大型软件中是不可避免的，但是如果我们可以付出一些写code的时候的小小冗余，带来长期的代码可维护性改善，那就是值得的。Java不是完美的，用Java一样可以写出不可维护的代码，但是Java至少比Python在这方面强很多。我们的经验证实了这点，信与不信就是看官的事了。”
非常有意思的一个讨论
引用：“任何流程，任何规范，任何review，任何代码检查工具，都阻止不了程序员缓慢地一点一点地滥用语言特性，也阻止不了一个软件代码自身的腐败。Python本身鼓励滥用Mock因为没有不用mock就可以方便写unit test的测试工具。Python还鼓励不定义清晰的类接口和类关系，如果你写了一个接口继承，就会有Python大牛跳出来说你不Pythonic。系统复杂性在大型软件中是不可避免的，但是如果我们可以付出一些写code的时候的小小冗余，带来长期的代码可维护性改善，那就是值得的。Java不是完美的，用Java一样可以写出不可维护的代码，但是Java至少比Python在这方面强很多。我们的经验证实了这点，信与不信就是看官的事了。”
 | 1 dimfox 2013-12-08 03:19:39 +08:00  2 任何一个新项目，由于需求不清晰，系统得整体设计不可能做到完美。随着项目的进行，不得不做出违背最初设计的补丁，时间越长，补丁越多，代码越混乱。把原来得代码推倒重来，新的设计者有着最初设计者没有的优势，一切需求清晰可见，系统自然可以设计得很好。不可以因此说这个语言比那个语言好。不能否认编译的语言有它得优势，尤其团队变大，交流成本变高。但是不能用这种事情作为证据。 下面这段是关键： “刚开始写的时候以为就是随便hack一个小系统临时用用，结果慢慢发展到成为关键系统，” |
 | 2 justfly 2013-12-08 03:45:36 +08:00 1 点进去看了，讨论焦点是 python 语言层面上的约束力不够。其实也有些略微标题党的感觉，作者自己都说「我觉得代码行数的节省也在于新系统更严谨的设计」。『随便hack一个小系统临时用用』的代码，在运行过程中不断向里面修修补补、添加东西到了8W行，跟已经完成了这个系统，站在制高点上综观整体进行重构，使用了4W 行，不怎么具有可比性。 我的感觉，python 作为动态语言的灵活性有利有弊。 在多人合作的大型项目中，它的灵活性（没有接口，不是强类型，参数可以是任意类型等）对人的『约束力』不够，从语言层面上它就比 java 等语言更容易带来可维护性问题。 但它的语法特性能提高人们的开发效率，更容易实现产品的快速迭代，在互联网产品中还是很有用。但是如果项目大到维护性开始成为问题（像里面说到8W），可能更需要语言层面上的约束性。 所以，还是看具体的 case 吧。 |
 | 3 efi 2013-12-08 03:59:47 +08:00 1 Python实现原型创造80%的价值，Java重写维护创造20%的价值。 |
 | 4 jjgod 2013-12-08 04:03:45 +08:00 “Guido搞的那个code review系统就是我说的那个维护不了的系统，最后的结果就是用Java重写了。” 按这个说法那就是 Rietveld 被 Gerrit 替代了的故事，Gerrit 确实是很不错的系统，可惜目前还有很多 Google 的项目在用 Rietveld，比如 Chromium。 |
 | 5 initialdp 2013-12-08 08:31:24 +08:00 via iPad 我觉得作者弄错了。初始系统是当初随便弄一下的，必然很多东西会欠考虑。后续扩展中，也只能缝缝补补，代码自然会越来越糟。重构一个系统，一来已经对整个系统比较了解，二来会更合理地通盘考虑和设计，自然效果会好很多。这和使用什么语言没什么关系。 翻过来说，如果一开始用JAVA随便去弄，后期用PYTHON重构，估计效果也会是这样。 |
 | 6 pythonee 2013-12-08 08:48:06 +08:00 via Android 为什么感觉就是不愿意承认python的欠缺呢，我虽然喜欢python，也写了不少，但我觉得楼主说的情况确实存在 |
 | 10 pepsin 2013-12-08 09:15:40 +08:00 动态语言这个问题是比较严重，一些人自以为聪明滥用一些偏门技巧，沾沾自喜，导致后续接手的人浪费很多时间去研究这些Hack，有些Hack还很核心，导致别人只能跟着那种错误的节奏来。 类型声明清晰的就好很多，限制多，自然小魔法就少。 |
| 11 initialdp 2013-12-08 09:23:39 +08:00 3 @pythonee python同样适合大规模软件，比如现在比较热的openstack等。 我也认为行数不是关键，但是“可维护性”这个东西就得再考虑一下。作为一个随便弄一下的系统，您觉得会有太多的考虑么？我认为不会考虑太多。系统变大后，如果不重写某些部分甚至调整架构，哪怕单纯出于系统兼容性考虑，也只能沿用原来的处理方式，这也就是为什么会越来越糟的原因之一。 这也就是为什么我认为作者的这个项目，如果反过来，先用java随便弄一下，系统大了之后，再用python去重构，估计会有同样的结论。 所以我觉得作者这个问题，其实无关语言，换谁都这样。这更多反应的是软件工程问题，是大规模软件V1版本和V2版本演进重构的问题。比如我们自己的软件，以前全部用C/C++，后来重构了业务模块，将业务逻辑独立出来用python实现，整个系统可维护性、扩展性等各方面都更好了，但我就不能因此得出结论：python比c/c++的可维护性方面强很多，对吧？ |
 | 12 moroumo 2013-12-08 10:03:59 +08:00 这个和语言的关系不大 更多的是因为项目发展的一定规模，需要推到重来。在这个重来的过程中，因为对需求和功能的重新规划，使项目规模减小了。 我现在就在做这件事，推倒5年前的ROR，和Ruby service，用JRuby和Java来重新做。 |
 | 13 jtacm 2013-12-08 10:53:22 +08:00 发个原帖吧， http://www.newsmth.net/nForum/#!article/Python/109344。 水木的帖子，回复中不乏一些自以为是的大拿啊。 |
 | 14 bombless 2013-12-08 10:57:12 +08:00 我觉得未必要做深入解读 他们有个项目要重写，而Google现在的要求就是尽量用Java 于是就用Java了。 至于说稳定性、可维护性的问题，那也许是重写导致的，也不能全部归功到语言吧？ |
 | 15 geeklian 2013-12-08 11:03:22 +08:00 Python有缺点也有优点，我经常用Python写的东东，过了半年重构成.net了。 若当初不用Python，则可能工期会完不成，可能赶不上需求方的变化，全因Python的高开发效率.. 重构时换成.net，是因为单位以前的应用都是.net的..... |
 | 16 raincious 2013-12-08 11:07:03 +08:00 via Android 引： “Python很好，只是你们这些外行不会用”，这是我听 到的最多的所谓Pythonic人的论调。事实是Python 作者自己亲自带领的那个项目也是一塌糊涂。他们遇到 的最主要问题就是可维护性低和性能差。世界上有没有 人比Python作者本人更Pythonic?如果他自己的项目 都不行，谁能做得更好？ 不知道说出这句话的根据是什么。不过个人很喜欢java风格。 |
 |
| 18 efi 2013-12-08 11:15:18 +08:00 @pythonee 你想表达什么？我没有表达任何价值评判。创造和验证新的利润点比维护现有利润点更重要。原型开发创造和验证idea的商业价值，维护保持idea的商业价值。Python适合创建原型，Java适合维护。所以Python创造比Java更多的价值。这个逻辑可以吧？ 当然你对价值有不同的定义另当别论。 |
 | 19 aminic 2013-12-08 15:02:38 +08:00 你们都弱爆了，#LISP一行搞定一切# |
 | 21 wizardoz 2013-12-08 15:21:01 +08:00 8W行的python能被4W行Java重写，那一定是本来设计的有问题吧 |
 | 22 Ricepig OP 题目是有点儿标题党的意思，但是文章里面还是有值得思考的地方： 1. 任何流程，任何规范，任何review，任何代码检查工具，都阻止不了程序员缓慢地一点一点地滥用语言特性，也阻止不了一个软件代码自身的腐败。 2. “Python很好，只是你们这些外行不会用”，这是我听到的最多的所谓Pythonic人的论调。事实是Python作者自己亲自带领的那个项目也是一塌糊涂。 3. Python程序的问题之一就是“腐烂”得很快，程序刚写好的时候看起来很简洁，一旦开始维护就快速地变成一堆乱七八糟的东西，动态语言代码腐烂速度远远超过强类型语言。 4. 如果用一个语言开发出可维护的代码需要的能力超过了Google能招聘到程序员的平均水平，我认为这个语言就不是一个可以用来开发可维护代码的语言。 5. 现在随着某Python之父的离开，公司里面粉Python的人也越来越少了。 |
 | 23 dorentus 2013-12-08 16:05:38 +08:00 这八万行的 python，假如这次是用 python 来重写，估计也可以变得更好，所以…… |
 | 24 ovear 2013-12-08 16:18:41 +08:00 @dorentus 发信人: daluobu (阿土仔), 信区: Python 标 题: Re: 终于把一个8万行的Python程序用Java重写了 发信站: 水木社区 (Sat Dec 7 00:48:05 2013), 转信 这个项目里面，重构是一直在进行的，在过去的八年里面，用Python大规模地重构也发生过好几次。 为什么不仔细看内容就下结论。。 |
 | 25 wdlth 2013-12-08 20:51:46 +08:00 既然是Google自家的，为何不用Golang呢？Python 8W行换成Java 4W行，看来原来Python的版本就有很多冗余的东西。 |
 | 26 mikale 2013-12-08 21:35:14 +08:00 python版竟然比java版多4W行，这代码确实有问题。 我所知道的情况，认识一哥们把C++的3W行代码改成python变成了6千行 就我个人和周围的朋友，用python写超过100行代码十倍以上的，多的是情况 这里唯一的问题，公司是google，按照此文的楼主的描述，我看google的水平差别很大啊，竟然会出楼主这种水平的员工。 |
| 27 Ricepig OP @wdlth 你稍微看一下你楼上的回帖。另外“如果用一个语言开发出可维护的代码需要的能力超过了Google能招聘到程序员的平均水平，我认为这个语言就不是一个可以用来开发可维护代码的语言。” |
| 28 mikale 2013-12-08 21:41:06 +08:00 发信人: iJava (简单美好), 信区: Python 标 题: Re: 终于把一个8万行的Python程序用Java重写了 发信站: 水木社区 (Sat Dec 7 14:28:56 2013), 转信 这个帖子满精彩的,俺就8了一下: 楼长说的那个系统应该就是Mondrain,从来没有开源的.这里有详细的介绍,包括对g公司的code review process. 发信人: yueq (yueq), 信区: Python 标 题: Re: 终于把一个8万行的Python程序用Java重写了 发信站: 水木社区 (Sat Dec 7 16:09:34 2013), 转信 根据楼主的描述，是Google的内部code review工具：）。 发信人: yueq (yueq), 信区: Python 标 题: Re: 终于把一个8万行的Python程序用Java重写了 发信站: 水木社区 (Sat Dec 7 16:15:16 2013), 转信 旧系统Mondrian 新系统Critique 如大家上所述，我觉得楼主对于UT、OOP的理解还有待加强。 （我也在G家某组用PYTHON） |
 | 29 Nver 2013-12-08 21:49:29 +08:00 没有错，不好讲是语言的区别。更多在于重构。 |
| 30 mikale 2013-12-08 22:07:59 +08:00 没有方法可以解决人的水平问题，方法只是给出了指导原则。任何软件规模慢慢庞大起来，又要可维护性高，一定会面临重写，不管是用什么语言重写。java语言的优势还是无可比拟的JVM的性能优势和几乎人人都知其语法。 繁琐的软件工程流程，适合于所有语言，团队越大越繁琐，动态语言不解决这问题。软件工程一旦发生问题，再牛的人也要趴下，合作是软件开发的难题。一堆牛人做出一个破项目，在软件开发的历史上不算少见的事情。 牛人在技术的所有领域都很牛，那是上古传说。 |
| 31 mikale 2013-12-08 22:34:26 +08:00 其实动态语言追求的是更少的人来做事，就个人工程实践经验而言，更高效的开发有助于让人数增加的速度减缓，从而控制软件工程的复杂度，这个道理跟算法的时间复杂度的想法类似，想必都能体会。 软件工程的大规模合作的难题难以解决，没有好方法可以处理此问题。坦白说，OO也不是解决方法。当前解决这个问题的主流思路是，避免大规模合作，降低代码行数，即避免庞大化，这是动态语言之所以流行的原因。 开源软件开发名著《大教堂和市集》，首次表达了避免庞大化的是如何可以做到的。github.com之类都是这条思路的当前最佳实践。在牛人总数整体不变的前提下，这几乎是唯一的方式。也是最自然的方式，社会也是这么运作的。 这个故事的槽点：python版改java版竟然没增加团队的人数，看来项目压力还是比较小。 |
 | 32 clino 2013-12-08 22:49:46 +08:00 gerrit 我们现在一直在用,还是很不错的,不过性能部分有问题,例如有些大的git提交会失败,怎么也提交不上去,已经给了几十G的内存给gerrit了还是不行,而同样的提交用 ssh push 就没问题,原因大概是用java实现的 jgit 不如用c实现的性能好的原因 不过我在想如果用纯python实现git在性能上应该会糟糕很多,当然一般来说会用c+python的方式来实现这种库的使用了 以前我就知道gerrit的前身是用python来实现的,也会想python是不是不合适去实现这样的一个项目,但这种问题应该是木有答案的 不过有一种场合我觉得python不合适去做应该是比较确定的,就是像android这样的一个系统,用python来做主打语言应该是不合适的,至少性能上会很渣 |
 | 33 standin000 2013-12-08 23:42:01 +08:00 |
| 34 mikale 2013-12-08 23:45:42 +08:00 @standin000 那是项目正在开发中不能增加人手，都推倒重来了，可以增加人手。不然软件公司根本不需要招人了。 |
 | 35 est 2013-12-09 09:07:59 +08:00 @clino 大文件上传，很多系统不会考虑很周到。。。比如给 git 上传个8G的 iso 文件很多系统也要跪。现在如果做git 也没有人会sb到用纯python实现，都是直接用这个了 https://github.com/libgit2/pygit2 python在桌面，移动端都没有任何优势。 |
| 36 clino 2013-12-09 09:49:27 +08:00 @est 基本同意在桌面和移动终端上无优势的看法.另外gerrit这样的系统不是跑在桌面也不是移动终端,但这种系统的python实现被java实现替代了,可能说明确实python也不适合做这样的项目,或者即使可以,在沟通成本和人员要求上可能比用 java 的代价还要高. |
 | 37 Livid MOD PRO Same story at Twitter. From Ruby to Java. |
| 38 standin000 2013-12-09 14:02:50 +08:00 @mikale 项目的需求不变，算是同一个项目了。估计增加人手，未必都同意改JAVA。 |
Select Language