ZT:疑Google员工把8w行Python项目用4w行Java重写了

[Ricepig]

http://blog.est.im/post/69161031446

非常有意思的一个讨论

引用：“任何流程，任何规范，任何review，任何代码检查工具，都阻止不了程序员缓慢地一点一点地滥用语言特性，也阻止不了一个软件代码自身的腐败。Python本身鼓励滥用Mock因为没有不用mock就可以方便写unit test的测试工具。Python还鼓励不定义清晰的类接口和类关系，如果你写了一个接口继承，就会有Python大牛跳出来说你不Pythonic。系统复杂性在大型软件中是不可避免的，但是如果我们可以付出一些写code的时候的小小冗余，带来长期的代码可维护性改善，那就是值得的。Java不是完美的，用Java一样可以写出不可维护的代码，但是Java至少比Python在这方面强很多。我们的经验证实了这点，信与不信就是看官的事了。”

[dimfox]

任何一个新项目，由于需求不清晰，系统得整体设计不可能做到完美。随着项目的进行，不得不做出违背最初设计的补丁，时间越长，补丁越多，代码越混乱。把原来得代码推倒重来，新的设计者有着最初设计者没有的优势，一切需求清晰可见，系统自然可以设计得很好。不可以因此说这个语言比那个语言好。不能否认编译的语言有它得优势，尤其团队变大，交流成本变高。但是不能用这种事情作为证据。

下面这段是关键：

“刚开始写的时候以为就是随便hack一个小系统临时用用，结果慢慢发展到成为关键系统，”

[justfly]

点进去看了，讨论焦点是 python 语言层面上的约束力不够。其实也有些略微标题党的感觉，作者自己都说「我觉得代码行数的节省也在于新系统更严谨的设计」。『随便hack一个小系统临时用用』的代码，在运行过程中不断向里面修修补补、添加东西到了8W行，跟已经完成了这个系统，站在制高点上综观整体进行重构，使用了4W 行，不怎么具有可比性。

我的感觉，python 作为动态语言的灵活性有利有弊。
在多人合作的大型项目中，它的灵活性（没有接口，不是强类型，参数可以是任意类型等）对人的『约束力』不够，从语言层面上它就比 java 等语言更容易带来可维护性问题。
但它的语法特性能提高人们的开发效率，更容易实现产品的快速迭代，在互联网产品中还是很有用。但是如果项目大到维护性开始成为问题（像里面说到8W），可能更需要语言层面上的约束性。

所以，还是看具体的 case 吧。

[efi]

Python实现原型创造80%的价值，Java重写维护创造20%的价值。

[jjgod]

“Guido搞的那个code review系统就是我说的那个维护不了的系统，最后的结果就是用Java重写了。”

按这个说法那就是 Rietveld 被 Gerrit 替代了的故事，Gerrit 确实是很不错的系统，可惜目前还有很多 Google 的项目在用 Rietveld，比如 Chromium。

[initialdp]

我觉得作者弄错了。初始系统是当初随便弄一下的，必然很多东西会欠考虑。后续扩展中，也只能缝缝补补，代码自然会越来越糟。重构一个系统，一来已经对整个系统比较了解，二来会更合理地通盘考虑和设计，自然效果会好很多。这和使用什么语言没什么关系。

翻过来说，如果一开始用JAVA随便去弄，后期用PYTHON重构，估计效果也会是这样。

[pythonee]

为什么感觉就是不愿意承认python的欠缺呢，我虽然喜欢python，也写了不少，但我觉得楼主说的情况确实存在

[pythonee]

@efi 没有发生的事情，为什么你如此肯定

[pythonee]

@initialdp 行数少不少不是关键，可维护性，不断往系统加特性是关键

[pythonee]

@justfly python适合一个人的项目，我现在的认知是这样，看openstack了

[pepsin]

动态语言这个问题是比较严重，一些人自以为聪明滥用一些偏门技巧，沾沾自喜，导致后续接手的人浪费很多时间去研究这些Hack，有些Hack还很核心，导致别人只能跟着那种错误的节奏来。

类型声明清晰的就好很多，限制多，自然小魔法就少。

[initialdp]

@pythonee python同样适合大规模软件，比如现在比较热的openstack等。

我也认为行数不是关键，但是“可维护性”这个东西就得再考虑一下。作为一个随便弄一下的系统，您觉得会有太多的考虑么？我认为不会考虑太多。系统变大后，如果不重写某些部分甚至调整架构，哪怕单纯出于系统兼容性考虑，也只能沿用原来的处理方式，这也就是为什么会越来越糟的原因之一。

这也就是为什么我认为作者的这个项目，如果反过来，先用java随便弄一下，系统大了之后，再用python去重构，估计会有同样的结论。

所以我觉得作者这个问题，其实无关语言，换谁都这样。这更多反应的是软件工程问题，是大规模软件V1版本和V2版本演进重构的问题。比如我们自己的软件，以前全部用C/C++，后来重构了业务模块，将业务逻辑独立出来用python实现，整个系统可维护性、扩展性等各方面都更好了，但我就不能因此得出结论：python比c/c++的可维护性方面强很多，对吧？

[moroumo]

这个和语言的关系不大
更多的是因为项目发展的一定规模，需要推到重来。在这个重来的过程中，因为对需求和功能的重新规划，使项目规模减小了。

我现在就在做这件事，推倒5年前的ROR，和Ruby service，用JRuby和Java来重新做。

[jtacm]

发个原帖吧， http://www.newsmth.net/nForum/#!article/Python/109344。
水木的帖子，回复中不乏一些自以为是的大拿啊。

[bombless]

我觉得未必要做深入解读
他们有个项目要重写，而Google现在的要求就是尽量用Java
于是就用Java了。
至于说稳定性、可维护性的问题，那也许是重写导致的，也不能全部归功到语言吧？

[geeklian]

Python有缺点也有优点，我经常用Python写的东东，过了半年重构成.net了。
若当初不用Python，则可能工期会完不成，可能赶不上需求方的变化，全因Python的高开发效率..
重构时换成.net，是因为单位以前的应用都是.net的.....

[raincious]

引： “Python很好，只是你们这些外行不会用”，这是我听 到的最多的所谓Pythonic人的论调。事实是Python 作者自己亲自带领的那个项目也是一塌糊涂。他们遇到 的最主要问题就是可维护性低和性能差。世界上有没有 人比Python作者本人更Pythonic?如果他自己的项目 都不行，谁能做得更好？

不知道说出这句话的根据是什么。不过个人很喜欢java风格。

[msg7086]

动态语言做快速原型开发，等跑起来了形成规模了，再用更合适的环境去重构，这本来就是挺正常的事情

pythonic的问题我感觉还是有点偏激了，prototyping我觉得是只要能做出东西来就OK，具体实现上的微调我觉得可以等重构来做。

[efi]

@pythonee 你想表达什么？我没有表达任何价值评判。创造和验证新的利润点比维护现有利润点更重要。原型开发创造和验证idea的商业价值，维护保持idea的商业价值。Python适合创建原型，Java适合维护。所以Python创造比Java更多的价值。这个逻辑可以吧？

当然你对价值有不同的定义另当别论。

[aminic]

你们都弱爆了，#LISP一行搞定一切#

[aku]

@aminic 哈哈，这个一行，估计没人能看得下去吧。
不过，话说回来，真的是一行搞定。

[wizardoz]

8W行的python能被4W行Java重写，那一定是本来设计的有问题吧

[Ricepig]

题目是有点儿标题党的意思，但是文章里面还是有值得思考的地方：
1. 任何流程，任何规范，任何review，任何代码检查工具，都阻止不了程序员缓慢地一点一点地滥用语言特性，也阻止不了一个软件代码自身的腐败。
2. “Python很好，只是你们这些外行不会用”，这是我听到的最多的所谓Pythonic人的论调。事实是Python作者自己亲自带领的那个项目也是一塌糊涂。
3. Python程序的问题之一就是“腐烂”得很快，程序刚写好的时候看起来很简洁，一旦开始维护就快速地变成一堆乱七八糟的东西，动态语言代码腐烂速度远远超过强类型语言。
4. 如果用一个语言开发出可维护的代码需要的能力超过了Google能招聘到程序员的平均水平，我认为这个语言就不是一个可以用来开发可维护代码的语言。
5. 现在随着某Python之父的离开，公司里面粉Python的人也越来越少了。

[dorentus]

这八万行的 python，假如这次是用 python 来重写，估计也可以变得更好，所以……

[ovear]

@dorentus
发信人: daluobu (阿土仔), 信区: Python
标 题: Re: 终于把一个8万行的Python程序用Java重写了
发信站: 水木社区 (Sat Dec 7 00:48:05 2013), 转信

这个项目里面，重构是一直在进行的，在过去的八年里面，用Python大规模地重构也发生过好几次。

为什么不仔细看内容就下结论。。

[wdlth]

既然是Google自家的，为何不用Golang呢？Python 8W行换成Java 4W行，看来原来Python的版本就有很多冗余的东西。

[mikale]

python版竟然比java版多4W行，这代码确实有问题。

我所知道的情况，认识一哥们把C++的3W行代码改成python变成了6千行

就我个人和周围的朋友，用python写超过100行代码十倍以上的，多的是情况

这里唯一的问题，公司是google，按照此文的楼主的描述，我看google的水平差别很大啊，竟然会出楼主这种水平的员工。

[Ricepig]

@wdlth 你稍微看一下你楼上的回帖。另外“如果用一个语言开发出可维护的代码需要的能力超过了Google能招聘到程序员的平均水平，我认为这个语言就不是一个可以用来开发可维护代码的语言。”

[mikale]

发信人: 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）

[Nver]

没有错，不好讲是语言的区别。更多在于重构。

[mikale]

没有方法可以解决人的水平问题，方法只是给出了指导原则。任何软件规模慢慢庞大起来，又要可维护性高，一定会面临重写，不管是用什么语言重写。java语言的优势还是无可比拟的JVM的性能优势和几乎人人都知其语法。

繁琐的软件工程流程，适合于所有语言，团队越大越繁琐，动态语言不解决这问题。软件工程一旦发生问题，再牛的人也要趴下，合作是软件开发的难题。一堆牛人做出一个破项目，在软件开发的历史上不算少见的事情。

牛人在技术的所有领域都很牛，那是上古传说。

[mikale]

其实动态语言追求的是更少的人来做事，就个人工程实践经验而言，更高效的开发有助于让人数增加的速度减缓，从而控制软件工程的复杂度，这个道理跟算法的时间复杂度的想法类似，想必都能体会。

软件工程的大规模合作的难题难以解决，没有好方法可以处理此问题。坦白说，OO也不是解决方法。当前解决这个问题的主流思路是，避免大规模合作，降低代码行数，即避免庞大化，这是动态语言之所以流行的原因。

开源软件开发名著《大教堂和市集》，首次表达了避免庞大化的是如何可以做到的。github.com之类都是这条思路的当前最佳实践。在牛人总数整体不变的前提下，这几乎是唯一的方式。也是最自然的方式，社会也是这么运作的。

这个故事的槽点：python版改java版竟然没增加团队的人数，看来项目压力还是比较小。

[clino]

gerrit 我们现在一直在用,还是很不错的,不过性能部分有问题,例如有些大的git提交会失败,怎么也提交不上去,已经给了几十G的内存给gerrit了还是不行,而同样的提交用 ssh push 就没问题,原因大概是用java实现的 jgit 不如用c实现的性能好的原因

不过我在想如果用纯python实现git在性能上应该会糟糕很多,当然一般来说会用c+python的方式来实现这种库的使用了

以前我就知道gerrit的前身是用python来实现的,也会想python是不是不合适去实现这样的一个项目,但这种问题应该是木有答案的

不过有一种场合我觉得python不合适去做应该是比较确定的,就是像android这样的一个系统,用python来做主打语言应该是不合适的,至少性能上会很渣

[standin000]

@aku 哈哈，一句宏！
@mikale 人月神话，增加人手不见得减少时间。

[mikale]

@standin000 那是项目正在开发中不能增加人手，都推倒重来了，可以增加人手。不然软件公司根本不需要招人了。

[est]

@clino 大文件上传，很多系统不会考虑很周到。。。比如给 git 上传个8G的 iso 文件很多系统也要跪。现在如果做git 也没有人会sb到用纯python实现，都是直接用这个了 https://github.com/libgit2/pygit2

python在桌面，移动端都没有任何优势。

[clino]

@est 基本同意在桌面和移动终端上无优势的看法.另外gerrit这样的系统不是跑在桌面也不是移动终端,但这种系统的python实现被java实现替代了,可能说明确实python也不适合做这样的项目,或者即使可以,在沟通成本和人员要求上可能比用 java 的代价还要高.

[Livid]

Same story at Twitter. From Ruby to Java.

[standin000]

@mikale 项目的需求不变，算是同一个项目了。估计增加人手，未必都同意改JAVA。

[WhyLiam]

"Python实现原型创造80%的价值，Java重写维护创造20%的价值。" 赞这句话
@efi