类似Python这种动态语言的一个疑惑

[Zhang Jiawei]

codebase 中 merge 了别人的代码以后。即便双方都没有改动同一个文件，也可能出现这种情况：
A 只改动了 a.py 的一个方法的传参个数。
B 改动了 b.py, 并且 b.py 中调用了 a.py 中的那个方法改动前的版本。

merge 了两个文件以后, 程序员基本都不会意识到现在出了问题。

原因有两个：

1. python 程序员基本不用什么IDE, 如果使用 pydev 之类, 大致还能依靠 IDE 在merge 以后看到这个错。
2. python 没有编译的概念，没有机会看到编译器对这个语法问题的报错。

好了，现在只有等上线以后，通过某个事件触发这个bug了。

请问各位是杂么防范这种问题的？

unit test ?

[Leo Jay]

2010/12/25 Zhang Jiawei <gho...@gmail.com>:

我也碰到过这样的问题，产品使用了2年之后才发现有一个异常处理的代码有错误。

现在的做法是pyflakes加unit test

--
Best Regards,
Leo Jay

[BOYPT]

方法是弃用顺序参数，使用keyword参数。

这就是API统一性的问题嘛，不是python才有的。

2010/12/25 Leo Jay <python...@gmail.com>

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
发言: pyth...@googlegroups.com
退订: python-cn+...@googlegroups.com (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp

--
Linuxer using Arch/Ubuntu, Pythoner, Geek
--> Blog: http://apt-blog.net
--> FB: http://www.facebook.com/boypt

[金浩]

这个问题似乎和代码版本管理无关吧。

1、犹豫python语言关键字参数和默认参数的特性，如果改动函数接口增加参数，只要是加在最后的参数并且带默认值，接口依然是兼容的，其他已存在的调用并不会出错。

2、如果函数接口改动会造成不兼容，那么应该由改动接口的人负责找出所有已存在的调用并修改或通知其他人修改。

[Zhang Jiawei]

静态语言可以在编译期看到编译错误。 这个问题 动态语言特有。

[Zhang Jiawei]

这个问题，多人协作时问题尤其突出，所以和代码管理相当有关。
单人开发，程序员对自己任何API的改动负责。出了问题也只能怪自己。
多人协作开发信息在人与人之间的传递是有成本的，有时根本都无法有效传递。

例如这个例子里。A 在改动时即便找出了所有已存在的调用并修改。
还是会有问题，因为 B 新加的调用 在提交前 A 无法获知。所以这个新加的调用
A无法修改。同理，B 在 merge code 前并不知道 A 改动了接口，所以他也没有去
做这个改动。merge 之后，A, B 谁都没有过错，但是问题还是发生了。

你可以说让A做了改动之后通知所有人，但是这个成本太高了。应该是工具来做而不是人。
这个工具就是我说的 IDE　或者是　编译器检查。可惜这两个在　ｐｙｔｈｏｎ　里不成立。

默认参数并不因为这个理由而存在，如果A增加的参数就是不能有默认值你又杂么办。
这个基本不算方案。

剩下我能想到的就是 Unit test 了。但是我工作那么多年，没有看到过把 unit test 真的做到杂么样的团队。

想来想去，动态语言 在多人协作的大项目里使用的问题真的是不少，虽然可以通过提高人的素质来解决。但是这个出错
的几率毕竟是比 静态语言高了。

[Yin Desheng]

让A做了改动之后通知所有人, 用类似Twitter的工具吧。

[朗儿]

参数设定默认值。。。。

########################

la.onger （ 朗儿 ）

 

yuel...@gmail.com

lao...@long-er.name

 http://la-onger.long-er.name/blog/

[li donglin]

前面的分析很正确，管理只能解决部分问题。
没做好归没做好，确实UnitTest看上去唯一的方案。
代码量大了以后，多人和1人的效果差不多，都会产生后续代码修改导致某一天的某个边边角角的功能运行不正常的。

在 2010年12月25日 下午1:40，Zhang Jiawei <gho...@gmail.com>写道：

--
li donglin

[victor lee]

unittest

2010/12/26 li donglin <lidong...@gmail.com>

[Felix Shao]

自动化回归测试

2010/12/26 li donglin <lidong...@gmail.com>:

[nathon py]

我也觉得是自动化回归测试才可以解决，这样才能节省人力且保证质量。

[范三山]

但是100%的覆盖率也是很难做到的

[nathon py]

是啊，代码改了起码要让所有的分支都跑一遍吧，这不算覆盖率高的。

而且这个topic提出的问题是静态语言可以在编译的时候发现函数定义与引用不一致的情况。

[glace]

unit test...

还有，A做一个公共的函数接口更新文档不就可以了。。。（用约定好的格式）

B可以人工检查相关函数接口是否改变

或者直接编一个小工具监视自己需要的接口是否改变，不就好了的说。。

[金浩]

函数参数改变而导致接口不兼容的机会到底有多少呢？

如果一个接口修改加入了新的参数而不能有默认值，是否接口设计上一开始就有问题。

另外如果这个接口不兼容而且无法保证提交后所有调用的地方做出了相应的修改，完全作为一个新接口是否更好一点呢。

[glace]

顶楼上，觉得除了大版本改变的需要。直接改变接口导致后续的调用中因兼容问题出错是很不好的行为。

[Zhang Jiawei]

机会就是1/1000也是机会，杂么可以因为机会小而容忍这样的问题。
要知道在静态语言里，因为语法错误导致问题出现的概率是 0. 因为根本没办法编译有语法问题的源代码。

关于默认值，不是不能有默认值，而是为了解决这个问题加默认值的做法不是很自然。默认值并不因为这个问题而存在，所以我想一定可以举出无法引入默认值的情形。

至于你提到的无法保证所有地方都作了修改而要一个新的接口，那基本上你每次都没法保证，每次都需要一个新接口。

在 2010年12月26日 下午7:54，金浩 <jinha...@gmail.com> 写道：

[Zhang Jiawei]

这个问题的实质不是接口改变导致的兼容问题，所以不用讨论这个行为好不好。

问题的实质来自于非编译类型的动态语言本身。

[glace]

对于“这个问题实质来自于非编译类型的动态语言本身。”

我觉得话不能这么说，这样让人感觉是在推卸责任。

随意的更改api确实是不合理的。

[Shell Xu]

世界上没有银弹。

如果你需要动态性，你就要为了动态性支付代价，包括性能，类别检查等等。

如果你真的在意这个问题，可以用C语言。

无能者无所求，饱食而遨游，泛若不系之舟

[金浩]

即使静态编译语言也不能解决所有你的所有问题，只不过是同一问题的出现在编译期还是运行期的区别。
如果想将问题尽快发现，那么动态语言加入单元测试实际上也相当于将问题的发现提前到编译期。

在 2010年12月26日 下午8:58，glace <glac...@gmail.com>写道：

[Zhang Jiawei]

在开发阶段，没人知道合理的api应该是什么样子。最后定型的才是合理的，在这之前，可以任意修改。

我们也不是提供 win32 api 级别的软件供应商，没必要在有了定型的api之后对第三方的调用负责。

编译类型的语言，问题可以在编译错误的时候解决。动态语言没有编译所以没有办法。

不是我要把问题归咎于动态语言，而是动态语言让你很爽的时候，也存在着潜在风险，没有什么东西是皆大欢喜的。

所以不要说什么 eclipse 是肥痴之类的话，我看 Pydev 就很好，语法检测能一定程度避免这类问题，还有上面说的 pyflakes

ide 本身的检错机制 + 100% 覆盖率的 unit test 我看这是终极答案了。

在 2010年12月26日 下午8:58，glace <glac...@gmail.com> 写道：

[glace]

总之抛开问题的出现。

对这个问题的解决。

偶觉得。

每个人维护一个自己的API的头部定义文件。

就是把自己的API的函数头部放到一个文件中，然后在内部网络的服务器上共享。

然后写一个小的程序，这个程序会记录下当前自己的程序中所调用的API的头部版本，每次会自动到服务器上下载最近的API函数头部，当新的函数头部和已用的函数头部不同时，会进行报警，由用户对自己的程序进行更新然后解除报警并更新记录的API头部版本（更新由这个程序自动完成）。

这样问题应该就可以解决了吧的说？。。。 =。=

而且这个小工具应该用不着写多长的代码的说。

[Zhang Jiawei]

我这个问题本身只谈编译期的问题。

至于另写小程序什么，我就不多做评价。

既然大家达成共识，结贴，不必回复了。

[Shell Xu]

只要语言动态，语法检测就基本没用。

有一类用法，是dict = ....; func(**dict)

dict是其他地方动态生成的。

用起来很爽吧。

死起来也很莫名。

在 2010年12月26日 下午9:10，Zhang Jiawei <gho...@gmail.com>写道：

--
无能者无所求，饱食而遨游，泛若不系之舟

[朗儿]

其实我每次改接口，都会全局搜索一下。不过如果像楼主这种两人同时使用这个接口的话，基本上靠口头和邮件通知。。。。

########################

la.onger （ 朗儿 ）

 

yuel...@gmail.com

lao...@long-er.name

 http://la-onger.long-er.name/blog/

[Luo Jiesi]

cscope可以吗？

2010/12/26 朗儿 <yuel...@gmail.com>

--
luojiesi@zju

http://www.luojs.com

[Eric Miao]

说来说去，他这个问题就是怎么保证动态语言没有语法错误。

跟前面一堆A啊B啊API啊啥的没啥关系。

2010/12/26 glace <glac...@gmail.com>

[pansz]

2010/12/26 Zhang Jiawei <gho...@gmail.com>:
> 要知道在静态语言里，因为语法错误导致问题出现的概率是 0. 因为根本没办法编译有语法问题的源代码。

你错了！静态语言C语言可以声明一个 .h
文件，里面是对外的函数接口。这个接口可以不变，然而在实现的部分，可以实现一个完全不同的函数接口。也就是说 .h 和 .c
实现的相同函数可以具有不同的参数表。

按照 C 语言标准，对应函数的 extern 语句是不允许声明在有实现的那个模块的。因而规范的 .h ，其中的 extern 在对应实现那个模块中将被宏跳过。

请看附件中的例子：a.h 中声明了一个与实际实现完全不同的函数原型，但是编译不会报错。

[pansz]

2010/12/27 Eric Miao <eric....@gmail.com>:
> 说来说去，他这个问题就是怎么保证动态语言没有语法错误。
> 跟前面一堆A啊B啊API啊啥的没啥关系。

其实这本身是伪命题，因为你不可能遇见没有发生的事情。所谓动态语言，
在运行时期，可以动态的增加代码进去，可以动态的给一个对象增加或者替换成员函数。所以编译只能在运行对应代码时动态进行。

正如，即使你完整的编译了一个C语言程序，也不可能防止把某个动态链接库中的一个函数的接口替换掉造成的问题一样，因为一个单独的动态库可以在程序编译完成之后的某个时刻被替换掉。

这说明，即使是针对静态语言，只要程序中有动态连接的模块，就都会存在接口问题。

甚至更进一步，只要一个静态语言存在不止一个模块，都可能存在接口问题（就如同上面我给出的 t.tar.gz 那个例子，程序完全的静态编译，但是还可能存在接口问题。

[老光]

文档,文档啊!

 

修改了一个方法的接口后,也同步修改他的__doc__内容(就是函数定义后面三引号括起来的那段文字),最后在__doc__里也体现历史修改信息.这样当调用他的人一发现出错,就help(mod.fun),结果发现作者的申明,就知道如何改接口了.

当然,好习惯是调用之前都help一下.

不管单人还是多人,静态还是动态,API都要求是一个相对稳定的东西.

[Zhang Jiawei]

杂么又忽悠到伪命题了。。。二楼不就说了这是他们的一个真实案例了。仅仅从人类逻辑上来理一下场景就可以真实再现这种错误。

各位举反例是好的，但是应该缩小一下讨论的范围。动态链接扯的太远了。

[Zhang Jiawei]

我在前面说了，语法检测是一定程度的避免这种问题。要是我自己，根本就不会写那些让我用起来很爽，死起来莫名的代码。

[pansz]

2010/12/27 Zhang Jiawei <gho...@gmail.com>:

> 杂么又忽悠到伪命题了。。。二楼不就说了这是他们的一个真实案例了。仅仅从人类逻辑上来理一下场景就可以真实再现这种错误。
>
> 各位举反例是好的，但是应该缩小一下讨论的范围。动态链接扯的太远了。

我只是想指出：

第一，语法检查并不能解决所有的问题，静态语言也一样。你说的所谓静态语言出现此问题概率为 0
并不正确。如同我的例子。事实上，我的例子来源于现实中真实的案例，也就是说某 C 语言函数被修改了但是 .h
没有被修改，程序可以正常编译，运行时间才出错。

第二，对动态语言做你想要的那种静态检查根本不现实，因为一个函数的接口可以在运行时间被改变，因此静态代码分析时看起来是错误的参数个数在实际运行时间有可能是正确的。反之，静态代码分析是看起来是正确的函数调用，在运行时间有可能是错误的。因而我们只可能在运行时间做这种检查，但是要想把这种检查做完全，只有靠unittest。

[nathon py]

弱弱的问一句，pylint能解决这个问题么？

--

[Samuel Ji]

在 2010年12月25日 上午11:33，Zhang Jiawei <gho...@gmail.com>写道：

codebase 中 merge 了别人的代码以后。即便双方都没有改动同一个文件，也可能出现这种情况：
A 只改动了 a.py 的一个方法的传参个数。
B 改动了 b.py, 并且 b.py 中调用了 a.py 中的那个方法改动前的版本。

merge 了两个文件以后, 程序员基本都不会意识到现在出了问题。

原因有两个：

1. python 程序员基本不用什么IDE, 如果使用 pydev 之类, 大致还能依靠 IDE 在merge 以后看到这个错。
2. python 没有编译的概念，没有机会看到编译器对这个语法问题的报错。

好了，现在只有等上线以后，通过某个事件触发这个bug了。

请问各位是杂么防范这种问题的？

unit test ?

 

对于可以设置默认参数的静态语言也会有这个问题,比如下面的函数(delphi):

function readint(addr: pointer; size: integer = 4): integer;

readint(addr, 2) 和readint(addr) 都能编译通过

哪天函数声明被改成

function readint(addr: pointer; offset: integer; size: integer = 4): integer;

原先的readint(addr, 2)仍然可以编译通过,但是结果呢?

这种需求下,一般对于未公开的api,才允许做一定的变动;至于已经公开的api,我们这样处理:

实现新的function readint_off,

readint改为调用readint_off(addr, 0, size);

但无论哪种情况,unittest都是不可缺少的.

[Shell Xu]

要是你自己写程序，也不用检查了，改接口改到自己都忘记纯属昏头。如果不只你自己写代码，你就必须规范什么是死起来莫名其妙的代码。例如*和**不能用，eval不能用，globals()[key]不能用，sys.modules.append不能用，__import__不能用，装饰器和闭包最好也别用。

python还剩下点什么？好像没了。

语法检查的问题在于，它不能给你一个解答。如果你要“避免”这个问题，依赖语法检查可以么？不可以，因为语法检查不能*保证*没问题。所以，你还是要依赖于文档检测，变更通知，接口定义，cross check。既然一样要依赖于这些方法，语法检查减少了什么不确定性么？没有。从信息学上说，他根本没提供信息。

除非你只是打算借助语法检查，发现多少是多少，剩下的问题就让用户发现吧。

[Shell Xu]

还有一种极端例子：

int check_list(Node * list);

这个函数原本是检测一个list是否合法的。如果list为NULL则认为是空表，根据默认检测结果，合法。有个程序员在程序中使用了这个特性。

后来有个程序员认为，NULL不应当是合法内容，于是修改了实现。

同样，这样会造成程序的问题，而且是最麻烦的逻辑错误，而非运行时错误。

也许很多人能看出上面的问题，这是一个低级的定义不严谨。问题在于，当一个程序员使用一个函数时，他必须按照函数的约定去使用。输入参数，输出结果是约定，函数的行为也是约定。静态语言会帮助检测函数的输入参数和输出参数的类型，但是却不会检测函数的行为。当函数行为修改时，一样必须通过特定方法告知所有使用函数的人。

从软件工程学上说，这类的问题就是没有银弹中所说的，人数越多，效率越差的原因。因为项目中的每个约定修改都必须告知所有人。

如果是大型项目，为了解决这个困扰往往会倒过来做。将系统拆分成多个部分，并且将部分间的接口约定死。当需要修改接口时必须通知所有使用了接口的其他组。如果项目拆分合理，接口设计合理，修改次数少，这样往往能减少项目的沟通成本。

--
来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
发言: pyth...@googlegroups.com
退订: python-cn+...@googlegroups.com (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp

--
无能者无所求，饱食而遨游，泛若不系之舟

[Zhang Jiawei]

我说语法检查从来都是说一定程度的解决问题，没说他包治百病。
unit test 也是一样，理论上可以检测出所有的问题，逻辑的，语法的。
问题是也并非包治百病，取决于cases的质量写的如何。

诸位说的静态语言，动态语言都有这样的问题，我也承认，只是动态语言犯错的机会大了。某些情况下，静态语言里出错几率是0的问题，动态语言里就有可能错。

其实大家谈的都没错，在实际演练中，自己掌控每种方法避免问题的火候即可。

[沈崴]

On 12月25日, 上午3时33分, Zhang Jiawei <ghos...@gmail.com> wrote:
> codebase 中 merge 了别人的代码以后。即便双方都没有改动同一个文件，也可能出现这种情况：
> A 只改动了 a.py 的一个方法的传参个数。
> B 改动了 b.py, 并且 b.py 中调用了 a.py 中的那个方法改动前的版本。
>
> merge 了两个文件以后, 程序员基本都不会意识到现在出了问题。

关于这个问题，首先，我并不认为这是一个真正的 bug。
真正的 bug 是改动了 b.py 中接口的逻辑和用途，但是接口名和参数个数并没有变化。
这种在编译语言中完全正常的，恰恰才是真正最为危险的情况。

而在讨论中，大家都在想办法保证参数个数必须一致的问题，我这里随便举个例子：

adduser(username, passwod)
adduser(name, gender)

作为同名接口，都具有两个参数，甚至都是字符串类型的，而且无论在编译还是运行期
都不会报错。似乎符合 “没有出错”这个判断 bug 的标准，但是，这会产生极为严重
的问题 —— 真正的逻辑错误。

所以我想说的是：

试图使用静态检查，和使用 IDE 进行参数约束的想法，才是真正危险的！

需要明白，报错和 core dump 并不是真正的 bug，也不是敌人。
要写出真正安全，减少 bug 的好程序，就要反过来做，不仅要允许参数不一致，
而且还要尽量制造这种错误。

除了在 python 和编译语言中都有的 assert 方法，python 提供了更多可以避免
这种情况发生的机制。比如显式参数名调用：

def adduser(**args):
u = args['username']
p = args['password']
...

如果这样调用 adduser(name='tom', gender='male') 就会出错，这时调用者
可以立即明白，逻辑上有问题了。你的程序就真正减少了一个 bug。

关于 python 中这些安全机制，我在一些场合已经讲过很多，大家可以补充。

所以，结论完全相反，比起静态语言，像 python 这种动态语言更难产生 bug。
使用 IDE 对于避免 bug 有一定优势也有劣势。至少 python 不会比静态语言更危险。

> 原因有两个：
>
> 1. python 程序员基本不用什么IDE, 如果使用 pydev 之类, 大致还能依靠 IDE 在merge 以后看到这个错。

当然我无论写 python，c\c++ 还是 java 之类都不会用 IDE，其实在你公司之外
许多人都是这样的。

> 2. python 没有编译的概念，没有机会看到编译器对这个语法问题的报错。

关于编译的问题，这里先不谈 .pyc .pyo。其实每个 .py 文件都像一个 .so / .dll 文件。
如果静态语言这么搞，上面提到的这种小问题一样多，之所以静态语言看似没有这种问题，
很大原因是因为它这么搞太麻烦了。

当然很多人对把静态语言搞成一种动态语言的这件牛逼的事情乐此不疲。

静态语言的项目，除去真的全部都是静态链接起来，的这种情况。一样会遇到你提到的困扰。
所以，这本身就不是一个动态语言的问题。

> 好了，现在只有等上线以后，通过某个事件触发这个bug了。

我想说的是：

即便上线了，当有问题时不出错，才是真正可怕的事情。

上线的程序，都需要从静态语言崩溃和动态语言报错中恢复的机制，和错误报告机制。
当然，当程序上线时，traceback 总比 core dump 要可爱得多。
而且动态语言调试又要方便一些，用户很快可以得到更新补丁。

所以结论又是相反的，上线以后，动态语言情绪要稳定得多。

> 请问各位是杂么防范这种问题的？
>
> unit test ?

所以结论是，不仅不防范，而且还要尽量制造和纵容这种所谓的错误。

--
沈崴

[jamiesun]

很有高度啊

[Sparkle]

�� 2010/12/25 11:33, Zhang Jiawei �:
> codebase �� merge �˱��˵Ĵ����Ժ󡣼���˫����û�иĶ�ͬһ���ļ���Ҳ���ܳ������������
> A ֻ�Ķ��� a.py ��һ�������Ĵ��θ���
> B �Ķ��� b.py, ���� b.py �е����� a.py �е��Ǹ������Ķ�ǰ�İ汾��
>
> merge �������ļ��Ժ�, ����Ա��������ʶ�����ڳ������⡣
>
> ԭ����������
>
> 1. python ����Ա����ʲôIDE, ���ʹ�� pydev ֮��, ���»������� IDE ��merge �Ժ󿴵�����?
> 2. python û�б���ĸ��û�л�ῴ�������������������ı��?
>
> ���ˣ�����ֻ�е������Ժ�ͨ��ij���¼��������bug�ˡ�
>
> ���ʸ�λ����ô������������ģ�
>
> unit test ?
>
unittest

������ⲻ��merge�����⣬���Ƕ�̬���Ա��������

���⣬��ʹ���б�������ԣ�Ҳ����������
������������Ա��ͬһ����������ֱ�д�� a+=2; Ȼ��ɹ�merge��

--
blog: http://weavesky.com
twitter: sparkle_zeng

[Wei guangjing]

在 2010年12月28日 上午10:58，沈崴 <wile...@gmail.com>写道：

On 12月25日, 上午3时33分, Zhang Jiawei <ghos...@gmail.com> wrote:
> codebase 中 merge 了别人的代码以后。即便双方都没有改动同一个文件，也可能出现这种情况：
> A 只改动了 a.py 的一个方法的传参个数。
> B 改动了 b.py, 并且 b.py 中调用了 a.py 中的那个方法改动前的版本。
>
> merge 了两个文件以后, 程序员基本都不会意识到现在出了问题。

关于这个问题，首先，我并不认为这是一个真正的 bug。
真正的 bug 是改动了 b.py 中接口的逻辑和用途，但是接口名和参数个数并没有变化。
这种在编译语言中完全正常的，恰恰才是真正最为危险的情况。

而在讨论中，大家都在想办法保证参数个数必须一致的问题，我这里随便举个例子：

   adduser(username, passwod)
   adduser(name, gender)

作为同名接口，都具有两个参数，甚至都是字符串类型的，而且无论在编译还是运行期
都不会报错。

静态语言是不会有这个问题的，因为不可能定义2个同名并有同样参数个数的方法。
 

[沈崴]

On 12月28日, 上午4时59分, Wei guangjing <vcc....@gmail.com> wrote:

> 在 2010年12月28日 上午10:58，沈崴 <wilei...@gmail.com>写道：
> > 而在讨论中，大家都在想办法保证参数个数必须一致的问题，我这里随便举个例子：
>
> > adduser(username, passwod)
> > adduser(name, gender)
>
> > 作为同名接口，都具有两个参数，甚至都是字符串类型的，而且无论在编译还是运行期
> > 都不会报错。
>
> 静态语言是不会有这个问题的，因为不可能定义2个同名并有同样参数个数的方法。

两个同名并有同样参数个数的方法 ---- c++ 可以 python 不行。

[沈崴]

> 两个同名并有同样参数个数的方法 -- c++ 可以 python 不行。

我的意思是，B 在项目里负责共享库 libB.so （相对于 b.py），里面实现了

adduser(username, passwd)

明天 B 把 libB.so 中这个接口改成了

adduser(name, gender) 或者 adduser(name, gender, age)

的情况 ;)

[Wei guangjing]

这个情况确实可能， adduser(name, gender, age) 可以避免，因为函数原型变了，头文件也发生变化了，重编译就能发现问题。
adduser(name, gender) 如果参数类型一样就只能听天由命了，类型不一样编译还是可以查出问题。

[Shell Xu]

重载阿。

--
无能者无所求，饱食而遨游，泛若不系之舟

[Zhang Jiawei]

如果得出这样的结论，我感觉有些矫枉过正了。

0. 真的是个bug, 因为用户访问到这个语句行的时候，报错了。
1. 我们不可能要求无论谁在写参数列表的时候都用map。
2. 我的案例实际上用ＩＤＥ或者其他的静态检查机制其实就可以解决问题，而且安全省力，没有附加步骤。
3. 您说的参数语义的内涵发生变化而导致的问题其实开辟了第二个案例。其实静态语言里也存在，用 map
也解决不了。因为大家merge代码的时候仍旧没有人意识到这里有问题，只有调用的时候才会发现问题。靠 unit test
应该能检查出来。如果unit test没报错，那么错的也是对的。
4. IDE 或者 静态检查 的确检查不出您开辟的第二案例，但不等于 IDE 或者静态编译
就是危险的，他们在自己力所能及的范围内检测出某些问题即可。比如我的案例。
5. 我还是觉得不用把事情扯到静态语言的动态链接上，事情很简单，适用范围没有那么大，就说两个py之间 和 两个 .c 之间都有互相调用，
如果 .c 是静态编译，通过编译器的报错会比执行到py才报错安全的多。即便是动态链接，楼上的朋友说了，参数个数的变化至少是可以通过编译发现的，因为
.h 变了。您的第二案例，无论是动态语言还是静态语言都没办法不通过Unit Test解决。
6. 我的案例同样是上线了，有问题不出错，和您的案例一样可怕。我和您的案例同样在静悄悄的等待出错的机会。

所以我想说的是，试图使用IDE和静态检查机制解决所有问题是危险的，但是进行参数约束还是安全的，起码参数的个数首先没问题，然后再用Unit
Test去保证参数语义的准确。

我的结论依旧，动态语言的出错几率会比静态语言大。靠 静态检查 + Unit Test 双保险解决问题。除此以外自己给自己制造问题太折腾。

另：c/python 好说，我想像不出 java 不用 ＩＤＥ还能用什么写？

谢谢指教。

在 2010年12月28日 上午10:58，沈崴 <wile...@gmail.com> 写道：

> On 12月25日, 上午3时33分, Zhang Jiawei <ghos...@gmail.com> wrote:
>> codebase 中 merge 了别人的代码以后。即便双方都没有改动同一个文件，也可能出现这种情况：
>> A 只改动了 a.py 的一个方法的传参个数。
>> B 改动了 b.py, 并且 b.py 中调用了 a.py 中的那个方法改动前的版本。
>>
>> merge 了两个文件以后, 程序员基本都不会意识到现在出了问题。
>
> 关于这个问题，首先，我并不认为这是一个真正的 bug。
> 真正的 bug 是改动了 b.py 中接口的逻辑和用途，但是接口名和参数个数并没有变化。
> 这种在编译语言中完全正常的，恰恰才是真正最为危险的情况。
>
> 而在讨论中，大家都在想办法保证参数个数必须一致的问题，我这里随便举个例子：
>
> adduser(username, passwod)
> adduser(name, gender)
>
> 作为同名接口，都具有两个参数，甚至都是字符串类型的，而且无论在编译还是运行期
> 都不会报错。似乎符合 "没有出错"这个判断 bug 的标准，但是，这会产生极为严重

> 的问题 ---- 真正的逻辑错误。

[赖勇浩]

2010/12/28 沈崴 <wile...@gmail.com>:

> On 12月25日, 上午3时33分, Zhang Jiawei <ghos...@gmail.com> wrote:
>> codebase 中 merge 了别人的代码以后。即便双方都没有改动同一个文件，也可能出现这种情况：
>> A 只改动了 a.py 的一个方法的传参个数。
>> B 改动了 b.py, 并且 b.py 中调用了 a.py 中的那个方法改动前的版本。
>>
>> merge 了两个文件以后, 程序员基本都不会意识到现在出了问题。
>
> 关于这个问题，首先，我并不认为这是一个真正的 bug。
> 真正的 bug 是改动了 b.py 中接口的逻辑和用途，但是接口名和参数个数并没有变化。
> 这种在编译语言中完全正常的，恰恰才是真正最为危险的情况。
>
> 而在讨论中，大家都在想办法保证参数个数必须一致的问题，我这里随便举个例子：
>
> adduser(username, passwod)
> adduser(name, gender)
>
> 作为同名接口，都具有两个参数，甚至都是字符串类型的，而且无论在编译还是运行期
> 都不会报错。似乎符合 "没有出错"这个判断 bug 的标准，但是，这会产生极为严重

> 的问题 ---- 真正的逻辑错误。

>
> 所以我想说的是：
>
> 试图使用静态检查，和使用 IDE 进行参数约束的想法，才是真正危险的！
>
> 需要明白，报错和 core dump 并不是真正的 bug，也不是敌人。
> 要写出真正安全，减少 bug 的好程序，就要反过来做，不仅要允许参数不一致，
> 而且还要尽量制造这种错误。
>
> 除了在 python 和编译语言中都有的 assert 方法，python 提供了更多可以避免
> 这种情况发生的机制。比如显式参数名调用：
>
> def adduser(**args):
> u = args['username']
> p = args['password']
> ...
>
> 如果这样调用 adduser(name='tom', gender='male') 就会出错，这时调用者
> 可以立即明白，逻辑上有问题了。你的程序就真正减少了一个 bug。
>
> 关于 python 中这些安全机制，我在一些场合已经讲过很多，大家可以补充。
>
> 所以，结论完全相反，比起静态语言，像 python 这种动态语言更难产生 bug。
> 使用 IDE 对于避免 bug 有一定优势也有劣势。至少 python 不会比静态语言更危险。

我是特意过来膜拜沈公的。

>
>> 原因有两个：
>>
>> 1. python 程序员基本不用什么IDE, 如果使用 pydev 之类, 大致还能依靠 IDE 在merge 以后看到这个错。
>
> 当然我无论写 python，c\c++ 还是 java 之类都不会用 IDE，其实在你公司之外
> 许多人都是这样的。
>
>> 2. python 没有编译的概念，没有机会看到编译器对这个语法问题的报错。
>
> 关于编译的问题，这里先不谈 .pyc .pyo。其实每个 .py 文件都像一个 .so / .dll 文件。
> 如果静态语言这么搞，上面提到的这种小问题一样多，之所以静态语言看似没有这种问题，
> 很大原因是因为它这么搞太麻烦了。
>
> 当然很多人对把静态语言搞成一种动态语言的这件牛逼的事情乐此不疲。
>
> 静态语言的项目，除去真的全部都是静态链接起来，的这种情况。一样会遇到你提到的困扰。
> 所以，这本身就不是一个动态语言的问题。
>
>> 好了，现在只有等上线以后，通过某个事件触发这个bug了。
>
> 我想说的是：
>
> 即便上线了，当有问题时不出错，才是真正可怕的事情。
>
> 上线的程序，都需要从静态语言崩溃和动态语言报错中恢复的机制，和错误报告机制。
> 当然，当程序上线时，traceback 总比 core dump 要可爱得多。
> 而且动态语言调试又要方便一些，用户很快可以得到更新补丁。
>
> 所以结论又是相反的，上线以后，动态语言情绪要稳定得多。
>
>> 请问各位是杂么防范这种问题的？
>>
>> unit test ?
>
> 所以结论是，不仅不防范，而且还要尽量制造和纵容这种所谓的错误。
>
> --
> 沈崴
>

> --
> 来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
> 发言: pyth...@googlegroups.com
> 退订: python-cn+...@googlegroups.com (向此发空信即退!)
> 详情: http://code.google.com/p/cpyug/wiki/PythonCn
> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>

--
web site：http://laiyonghao.com
twitter: http://twitter.com/laiyonghao

[赖勇浩]

2010/12/28 Zhang Jiawei <gho...@gmail.com>:

> 如果得出这样的结论，我感觉有些矫枉过正了。
>
> 0. 真的是个bug, 因为用户访问到这个语句行的时候，报错了。
> 1. 我们不可能要求无论谁在写参数列表的时候都用map。
> 2. 我的案例实际上用ＩＤＥ或者其他的静态检查机制其实就可以解决问题，而且安全省力，没有附加步骤。
> 3. 您说的参数语义的内涵发生变化而导致的问题其实开辟了第二个案例。其实静态语言里也存在，用 map
> 也解决不了。因为大家merge代码的时候仍旧没有人意识到这里有问题，只有调用的时候才会发现问题。靠 unit test
> 应该能检查出来。如果unit test没报错，那么错的也是对的。
> 4. IDE 或者 静态检查 的确检查不出您开辟的第二案例，但不等于 IDE 或者静态编译
> 就是危险的，他们在自己力所能及的范围内检测出某些问题即可。比如我的案例。
> 5. 我还是觉得不用把事情扯到静态语言的动态链接上，事情很简单，适用范围没有那么大，就说两个py之间 和 两个 .c 之间都有互相调用，
> 如果 .c 是静态编译，通过编译器的报错会比执行到py才报错安全的多。即便是动态链接，楼上的朋友说了，参数个数的变化至少是可以通过编译发现的，因为
> .h 变了。您的第二案例，无论是动态语言还是静态语言都没办法不通过Unit Test解决。
> 6. 我的案例同样是上线了，有问题不出错，和您的案例一样可怕。我和您的案例同样在静悄悄的等待出错的机会。
>
> 所以我想说的是，试图使用IDE和静态检查机制解决所有问题是危险的，但是进行参数约束还是安全的，起码参数的个数首先没问题，然后再用Unit
> Test去保证参数语义的准确。
>
> 我的结论依旧，动态语言的出错几率会比静态语言大。靠 静态检查 + Unit Test 双保险解决问题。除此以外自己给自己制造问题太折腾。

既然你心意坚决，又不能（或不愿？）去改变 Python，不妨回去用静态语言。
争吵无益，其实这和世上的其它事物一样，要么你改变它，要么你改变自己。

--

[li zJay]

同膜拜。

2010/12/28 赖勇浩 <ma...@laiyonghao.com>

--
祝好

[机械唯物主义 : linjunhalida]

我也是来膜拜沈游侠的. 游侠上面的内容和某次上海Python聚会的内容差不多.
上面出现的参数改变的问题, 我觉得也是流程问题.

对于每个人做自己模块的状况:
当一个人修改代码的时候, 改动到了一个接口, 影响到另外一个人的工作的时候, 需要告诉他.

如果是2个人同时修改同一份代码的状况:
检查的责任应该是后checkin代码的人, 他需要看过自己修改代码这段时间发生的所有log.

下面引用的部分没有看懂, 就不回应了.

2010/12/28 Zhang Jiawei <gho...@gmail.com>:

[Zhang Jiawei]

回帖清先仔细看贴。
我做了分析，也有比较，最后下了结论，给出了方案。
一坨字看起来确实累，只是看个结论也不会说出让我回去用静态语言这种话了。
下次我加粗结论就是。

[大房]

  -- 我的结论依旧，动态语言的出错几率会比静态语言大。
不清楚您得出这个结论对我们的意义在哪里。我相信一个团队，是选择适用静态语言还是动态语言，不单单是看“参数改变而有潜在的bug”这种出错率的，还要考虑开发效率，团队目前的技能等等，而且，后者可能比重更高。团队合作总要找到个平衡点，这个平衡点要技能保障高效的产出，“潜在bug出错率“又在可以接受的范围内。


这个thread管理员该封贴了吧。。。

-- Thanks Wyatt Fang

-------- 原始信件 --------
发件人: Zhang Jiawei <gho...@gmail.com>
Reply-to: "pyth...@googlegroups.com" <pyth...@googlegroups.com>
收件人: pyth...@googlegroups.com <pyth...@googlegroups.com>
主题: Re: [CPyUG] Re: 类似Python这种动态语言的一个疑惑
日期: Tue, 28 Dec 2010 06:38:28 -0600

[Zhang Jiawei]

实在是太能扯了，封帖吧，我都不想回了。

[老光]

我认为这个问题，就是说两个方面：自省和交流．
举个实际例子，去年年末的时候，社区根据派出所要求，把楼层门牌号全部提高了一层，我原来是住７－１，改成了８－１．结果回家的时候，我就掏钥匙去开了半天我楼下的门，愣没开开，甚至连我的楼层要进一个铁门（我们顶楼两户合做了铁门）都没有注意到．后几天一问，上当的人多得很．
现在回头一想，结合这个议题，其实社区换门牌时是可以有以几下几种办法避免大家开错门的（开不来还好，要是开来了，问题就多了．．）
1、只换牌子，不管其他。那么不同钥匙能开同一把锁的概率非常小，大部分人半天开不来门，不会造成乱进别人家门的情况，但会浪费时间去搞清楚原来自己走错地方了。极少部分人，嘿，门开来了，进去不是自己家，那出的事儿可就不好说了。
2、单元楼外面贴个公告：亲爱的业主，楼层编号已经按派出所要求进行了更改，统一调高了一层，请各位开门时注意。这样大部分人也会看到，能够找到自己的家门；可是少数粗心大意的或者赶时间的人，仍然会走错门。
3、社区费点时间，把那个公告贴在新改的楼层编号旁边。这样粗心犯错的人少了很多。
4、再细心点，把公告细化为：亲爱的业主，你原来的楼层号是7－1，已于今天改为了8－1，请注意。并用这个公告把新改的门牌号遮住。这样，犯错误的人可以说是微乎极微了吧？
5、再来，我把公告贴在门上，把锁眼给挡住！这样应该没有人犯错误了吧？
－－嘿，别指望，万一您遇上一文盲＋大老粗呢？

[sj l]

沈仙人的见解非常震撼，同膜拜。

建议仙人下次长三角聚会时给我们讲讲基础。不想讲，给我们翻翻slide也好

2010/12/29 老光 <yaogua...@cq.chinatelecom.com.cn>

[jamiesun]

楼主三句不离静态语言和编译检查，难道你不是很希望python能达到这个程度吗，用过很久动态语言的人都知道这是不靠谱的，扯来pydev也是不靠谱的，如果总是往那个方面想，除了回去用静态语言，真没什么好建议了。

Ide都是扯蛋，难道不用IDE就做不成大工程了，团队没有脱离IDE的能力，用静态语言不是更靠谱吗。

认为Unit test 是解决之道，却又认为国内没有做的彻底的公司，这不是扯码，所以说建议回去使用静态语言是最好选择。

python的特性带来无限可能，可以通过各种扩展来改进开发。如果对此抱怀疑态度，回去使用静态语言。

[jamiesun]

在程序开发中有个“快速失败”的概念，java中的异常处理也有提到这点，和沈仙人的提法差不多。

要“快速失败”，而不是隐藏，容忍，忽略，虽然动态语言没有编译检查，但是通过编码的技巧可以在运行时暴露出来。

编译检查常常会带来一种假象：这段代码OK。但是实际上可能存在严重逻辑错误

靠编译检查来保证代码健壮性完全是伪命题。

依赖工具和语言特性是没有什么好的解决方案的，属于偷懒取巧。持续改进重构，做好Unit test 才是正道。

“国内没有多少把Unit test做好的公司”算是现状吧，但是难道还要随波逐流么？

[Zoom.Quiet]

哗!少有的热论哪! 沈游侠出没,必火! 收录:
http://wiki.woodpecker.org.cn/moin/MiscItems/2010-12-25

在 2010年12月28日 下午8:38，Zhang Jiawei <gho...@gmail.com> 写道：
> 如果得出这样的结论，我感觉有些矫枉过正了。
>

嗯嗯嗯,其实呢,俺是理解 沈论的,只是没有他那么多案例来支撑;
内什么,,,其实呢,大家心里想说的和 Jiawei 在反馈的问题,完全不是一个位面的事儿!

不论是 蟒禅还是蟒之8荣8耻,一直在表达的都不是语言的什么动态性,这些都是浮云!
真正一直在吼的是:
- 只有人才靠谱!工具都TMD 没谱!
- 只有想明白的人才可能写出明白的代码,IDE都TMD的是忽悠!
- 只有工程才是问题,技术从来都是有解决途径的!

不论Python/Erlang/Perl 等等广泛得到程序使用但是从来没在主流商业领域得到青睐的开发语言,
都有独特的开发文化包含在其中,涉及到动态语言的开发,
近年 erl 的兴起,其内置的质量保证方式之一就是"脆崩"或是说"速死"~进程只要有一点儿不对味立即死亡，绝对不允许继续呆在内存中影响其它进程！这样才能确保整个系统是稳定的...

用Python 来进行团队協作时，也一样，妄想通过工具来确保基础的神马参数统一/接口统一/运行期统一,
那是自虐!
Python 赋予了程序员极大的自由度的同时,
其实就是在纵容和放大了这类人为逻辑错误的危害!
从而促使团队开始思考如何才能真正的协同起来,
而不是象JAVA 一样,形成用华丽/复杂/坚固的类树进行安全隔离的一堆码农!

> 0. 真的是个bug, 因为用户访问到这个语句行的时候，报错了。

- 写出这种代码来的人,才是bug

> 1. 我们不可能要求无论谁在写参数列表的时候都用map。

- 为什么呢? 一个团队难道没有任何统一规约的嘛?

> 2. 我的案例实际上用ＩＤＥ或者其他的静态检查机制其实就可以解决问题，而且安全省力，没有附加步骤。

- 也就是说,不期望成员真正明白什么是逻辑错误了? 那么人的创造力是无限的,总是会有人写出NB到IDE也检查不出的隐藏逻辑 bug 的,每年
C++/JAJA/C# 制造了无数神奇的这种bug,在 Python 中,难道还要在 IDE 养护中促进这种 bug 的创造!?

> 3. 您说的参数语义的内涵发生变化而导致的问题其实开辟了第二个案例。其实静态语言里也存在，用 map
> 也解决不了。因为大家merge代码的时候仍旧没有人意识到这里有问题，只有调用的时候才会发现问题。靠 unit test
> 应该能检查出来。如果unit test没报错，那么错的也是对的。

- unit test 也是人写的,也有工作量的,如果良好的团队规约,交叉审阅等等促进团队知识管理的柔性协同可以从根儿上解决问题,为什么要使用同样包含问题的测试代码来解决问题代码?

> 4. IDE 或者 静态检查 的确检查不出您开辟的第二案例，但不等于 IDE 或者静态编译
> 就是危险的，他们在自己力所能及的范围内检测出某些问题即可。比如我的案例。

- 他们是谁? 是IDE 的团队,不是你的团队,想通过这种方式来提升自个儿团队的生产力是种美好的想象...

> 5. 我还是觉得不用把事情扯到静态语言的动态链接上，事情很简单，适用范围没有那么大，就说两个py之间 和 两个 .c 之间都有互相调用，
> 如果 .c 是静态编译，通过编译器的报错会比执行到py才报错安全的多。即便是动态链接，楼上的朋友说了，参数个数的变化至少是可以通过编译发现的，因为
> .h 变了。您的第二案例，无论是动态语言还是静态语言都没办法不通过Unit Test解决。
> 6. 我的案例同样是上线了，有问题不出错，和您的案例一样可怕。我和您的案例同样在静悄悄的等待出错的机会。
>

- 所以,沈游侠强调的是,应该想办法让这种问题在上线前就暴发出来哪,,,

> 所以我想说的是，试图使用IDE和静态检查机制解决所有问题是危险的，但是进行参数约束还是安全的，起码参数的个数首先没问题，然后再用Unit
> Test去保证参数语义的准确。
>

- 呃,,,所以,写JAVA 代码就象打字员,除了忍受越来越长的参数之外没有任何办法(所以IDE很依赖 ;-)
- 所以,Py/Ruby/Lisp ... 都为程序员的生命着想给出很多减少输入的参数声明方法
- 但是,要成功偷懒得整个团队一起来,否则最后全部倒霉 ...

> 我的结论依旧，动态语言的出错几率会比静态语言大。靠 静态检查 + Unit Test 双保险解决问题。除此以外自己给自己制造问题太折腾。
>

- 这个结论和大家没有什么不同哪,只是解决态度有不同
- 容易出错是个福利,而不是 bug
- 每一错误,都导向更加高效/靠谱/简洁的代码书写
- 依赖 静态检查和测试案例,则导向更多的隐藏错误

> 另：c/python 好说，我想像不出 java 不用 ＩＤＥ还能用什么写？

用自个儿写的代码生成器!

--
人生苦短, Pythonic!
俺: http://about.me/zoom.quiet
开: http://code.ijinshan.com/
豆: http://www.douban.com/group/zoomquiet
书: http://code.google.com/p/openbookproject
蟒: http://code.google.com/p/kcpycamp/wiki/PythoniCamp

[Shell Xu]

让我想起 铁血战士vs异形。

java程序员比较喜欢借助工具，一方面是因为java的重构太频繁了，架构上也是叠床架屋。另一方面，不可避免的，大量培训生的存在使得java代码的bug创造力始终走在时代的最前列——尤其是量产代码。工具检查/自动检查的存在使得一些常见bug能被简单的找出来——这对项目经理可是个好事。

——这对产生正确的代码可不是好事。。。

--

来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
发言: pyth...@googlegroups.com
退订: python-cn+...@googlegroups.com (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp

--
无能者无所求，饱食而遨游，泛若不系之舟

[lee Alexander]

#  > 另：c/python 好说，我想像不出 java 不用 ＩＤＥ还能用什么写？
#

# 用自个儿写的代码生成器!

#

人生苦短，远离Java

阿弥陀佛

在 2010年12月29日 上午10:32，Zoom.Quiet <zoom....@gmail.com>写道：

--

来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
发言: pyth...@googlegroups.com
退订: python-cn+...@googlegroups.com (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp

--
Alexander.Li
+86 15308006505
mail: superp...@gmail.com/superp...@hotmail.com
site:http://alexander-lee.cnblogs.com

[horn Pan]

天天实习弄java的人含泪飘过。

这个topic的确很精彩。受益匪浅

best wishes to all of u, my friends

gtalk: scup...@gmail.com

phone: (86) 15110245471

[snpg]

怎么不是好事呢？难道所有的低级错误都要靠人手工 检查才能发现就是好事？

当然，我也同意真正的bug还是要靠人才能避免 。

所以说，check in代码之前检查一下codebase里有哪些自己用到的模块发生了变化才能避免这类问题

在 2010年12月29日 上午10:45，Shell Xu <shell...@gmail.com>写道：

工具检查/自动检查的存在使得一些常见bug能被简单的找出来——这对项目经理可是个好事。

——这对产生正确的代码可不是好事。。。

[Zhang Jiawei]

其实帖子写到这个程度，我总结几个问题：

1. 回到本楼第一贴看一看我们在什么案例下讨论问题。
2. 膜拜大神的，请勿回帖。您的观点已经不客观了。
3. 人有取舍的权利，即便同在华蟒用户组，也不用没有理由的看到以下词语后十分鸡血：JAVA, IDE, 静态语言，工具。
4. 我真的没觉得动态语言静态语言哪个好哪个不好。不过是想用其长，避其短。该用什么用什么。
5. 以下措辞并不能表达您的观点真的正确：扯淡，王道，伪命题，不靠谱，吼，只有句式。

诸位说的都对，我和诸位真的在讲一个意思。您抱着敌视心态，在我的每一句下面加自己的注解，首先是没用心看我到底在说什么，其次也没回第一楼看我们讨论问题的前提，您有这样的态度，我说的全是错的，您注解的全是对的。好吧，这个帖子我真的不想回了。

在 2010年12月29日 上午10:32，Zoom.Quiet <zoom....@gmail.com> 写道：

[victor lee]

我是特意过来膜拜沈公/Zoom.Queit的。

- 这个结论和大家没有什么不同哪,只是解决态度有不同
- 容易出错是个福利,而不是 bug
- 每一错误,都导向更加高效/靠谱/简洁的代码书写
- 依赖 静态检查和测试案例,则导向更多的隐藏错误

pls read the above sentence again and again untill you get the meaning.
when sometime you get it, you may have a great progress :)
without enmity
yours sincerely VIC
100.12.29

2010/12/29 Zhang Jiawei <gho...@gmail.com>

[jamiesun]

种瓜得瓜

[jia...@gmail.com]

2010/12/25 Zhang Jiawei <gho...@gmail.com>:

> codebase 中 merge 了别人的代码以后。即便双方都没有改动同一个文件，也可能出现这种情况：
> A 只改动了 a.py 的一个方法的传参个数。
> B 改动了 b.py, 并且 b.py 中调用了 a.py 中的那个方法改动前的版本。
>
> merge 了两个文件以后, 程序员基本都不会意识到现在出了问题。
>

> 原因有两个：
>
> 1. python 程序员基本不用什么IDE, 如果使用 pydev 之类, 大致还能依靠 IDE 在merge 以后看到这个错。

> 2. python 没有编译的概念，没有机会看到编译器对这个语法问题的报错。
>
> 好了，现在只有等上线以后，通过某个事件触发这个bug了。
>
> 请问各位是杂么防范这种问题的？
>
> unit test ?
>

我说说我原来在Exoweb时，我们的项目是怎么处理你这个问题的吧。

首先一个任务在被程序员选择，编写并提交后，无论修改或者添加了任何的功能一定要写至少一个的 test
来保证所修改或者添加的功能的正确性，所以绝大部分的类似的问题在这一层次就可以被堵住了。

然后如果有问题突破了test 这一层，那么接下来，任何的一个提交都要由项目组里面的全部或者绝大部分的成员做过 code review
并且没有任何问题后才可以被作为候选的更新等待负责项目更新的人来合并到生产环境中去，这里 team leader
要负绝大部分的责任，一但后续发现某一个提交有问题，那么会直接找team leader
来负责的，当然此处不存在打击报复，但是仍然会被列为此team leader本人的绩效考核中去的。这个项目组内部的code
review非常细致，可以细致到某个逗号后面是否应该有一个空格的地步。

再次，即便有类似的问题真的突破了项目组的范畴，每一个负责向生产环境更新的负责人，对于所有的要更新到生产环境的代码也要重新进行review，以确保不放过任何一个错误，这里我要说的是，每一个做这个事情的人，都是非常熟悉整个系统的，并且非常的认真负责的，并且这样的工作也是包含在绩效考核中的。

最后，谁也不能保证生产环境没有任何的bug，如果出现了bug，简单的可以就地，hot
patch，然后给代码库增加一个补丁，复杂的bug那就直接回滚到之前的版本，等修复之后再次更新。一般这样的线上处理也都很快就成处理完。

以上这几个步骤应该能够防范你所遇到的问题了吧？

这些步骤实际运行了有几年了一直很顺畅，不过这些是我07年离开Exoweb之前的事了，经过了这3年肯定又有所改变了，不过我想大体上应该还差不多吧，如果有路过的现在在Exoweb的人可以就我所说的不足或者错误或者现在又有什么新的流程再做一下补充吧。

--
Gary Jia <ke(AT)jia.name>

[jia...@gmail.com]

2010/12/29 jia...@gmail.com <jia...@gmail.com>:

补充一点，在我离开的时候，99%的开发人员都用 vim或者emacs 没有任何的IDE存在，整个公司除了财务大姐其余所有人都用Linux 或者 Mac。

--
Gary Jia <ke(AT)jia.name>
http://www.jiake.org
珍爱生命，远离京东!
http://www.tianya.cn/publicforum/content/free/1/1662804.shtml

[sj l]

诸位说的都对，我和诸位真的在讲一个意思。您抱着敌视心态，

在我的每一句下面加自己的注解，首先是没用心看我到底在说什么，其次也没回第一楼看我们讨论问题的前提，您有这样的态度，我说的全是错的，您注解的全是对的。好吧，这个帖子我真的不想回了。

我再注解一遍，沈仙人已经对为什么你的观点不靠谱做了很详细明确的回答，很明显你也没有细看。还有，指望没个人都能给出靠谱的答案本身就不现实。
细细读下游侠的回复，就了解了。

2010/12/29 jia...@gmail.com <jia...@gmail.com>

[Zhang Jiawei]

做的确实非常好。

我也补充几点：
1. 这样环境并非哪里都有。
2. 你们的流程非常好，但是仅仅从描述我都感受到了巨大的人肉成本，所以我们从来都在说一个意思，但是我更倾向于简单的问题能用工具就用工具去提早发现，复杂的问题才需要人肉介入。

没有IDE存在我个人并不感到敬畏，因为只不过是适用场合的问题。如果你说写Java你不用IDE，我的确会感到敬畏，而且十分想了解你们是杂么做的，我还特此发了个邮件给沈大，结果得到的答复不过是戏謔之词。我本人的Vim技巧大抵不会比你们公司里任何人差，相信还比大多数人好，
我在公司内部的例会上还做过专门的Vim演示去推广，发过邮件给Vim的作者提示他的Vim主页上没有加上他名字的中文版本，并且得到了该作者的答复和更正。我从来不正面刻意的去宣扬非IDE的意义，相反我在某些场合推荐IDE的存在，尤其是在Python的领域，这不代表我不知道Vim/Emacs系的好处，而是我更深知选择他们的场合。我研究过python.vim的源码说实话，真的够烂的。我也研究过pydev的eclipse
plugin, 说实话，真的很用心的在写。如果你们是做Python Web的，我认为不使用IDE大致问题不是那么大，因为在一个稳定的web
framework之下，需要掌握的api就那么几个，从一个request过来到一个response返回就这点破事，比较费劲的是业务逻辑，完全是用基础的Python语法就可以应付。如果你们是写PyQt一类，对不起，用Vim之类是自虐。因为那是C++的原生接口，Python
只是胶水语言，大妈扯到 Python 接口可以减少参数输入，在这里是不适用的。尤其面对成千上百个 GUI API
每个API有诺干个参数，每种参数的输入有各自的界面效果，再加上各个API之间的叠加效果。好吧，还是郑重推荐
PyDev。还是那句话，看场合，分情况来解决问题。

最大的问题就在这里，用 Python 和 用 Vim/Emacs 一样，并不显得你比别人高一等。说话做人都不要那么偏激，不用把其它诸如
Java, IDE, 静态检查都说的一文不值，相反我印象里 Pythoner 更应该低调才是，两个字概括“暗爽”。

你们有一个除了大姐都在用Linux或者Mac的环境，很好没问题。我在一个几百人都用Windows的IT公司里，应该比贵公司的市值要高很多很多倍。一个人一点一点的给自己开发机上的Ubuntu配置了能运行公司代码的工作环境
-- 我的桌面永远都是紫红色的。

[Shell Xu]

用个工具无可厚非，但是指望工具能检查出所有的错误是不可能的。

如果你希望获得一个能够通过用户验收的代码，靠工具没什么问题。如果你打算写出一个你能写出的可靠性最高的程序，越依赖工具，越无法达成。

--

来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
发言: pyth...@googlegroups.com
退订: python-cn+...@googlegroups.com (向此发空信即退!)
详情: http://code.google.com/p/cpyug/wiki/PythonCn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp

--
无能者无所求，饱食而遨游，泛若不系之舟

[沈崴]

On Dec 29, 9:10 pm, Zhang Jiawei <ghos...@gmail.com> wrote:
> 做的确实非常好。
>
> 我也补充几点：
> 1. 这样环境并非哪里都有。
> 2. 你们的流程非常好，但是仅仅从描述我都感受到了巨大的人肉成本，所以我们从来都在说一个意思，但是我更倾向于简单的问题能用工具就用工具去提早发现，复杂的问题才需要人肉介入。
>
> 没有IDE存在我个人并不感到敬畏，因为只不过是适用场合的问题。如果你说写Java你不用IDE，我的确会感到敬畏，而且十分想了解你们是杂么做的，我还特此发了个邮件给沈大，结果得到的答复不过是戏謔之词。我本人的Vim技巧大抵不会比你们公司里任何人差，相信还比大多数人好，

> ...

不好意思，不过我确实是很认真地写了个不经过 IDE，手写 java 和编译的例子。
其实我 java 真的非常烂，但发誓真的没有敷衍啦，请不要上心 :)

[Zhang Jiawei]

好说好说，我也是实在好奇，忍不住问了。

[jia...@gmail.com]

2010/12/29 Zhang Jiawei <gho...@gmail.com>:

> 做的确实非常好。
>
> 我也补充几点：
> 1. 这样环境并非哪里都有。
> 2. 你们的流程非常好，但是仅仅从描述我都感受到了巨大的人肉成本，所以我们从来都在说一个意思，但是我更倾向于简单的问题能用工具就用工具去提早发现，复杂的问题才需要人肉介入。
>
> 没有IDE存在我个人并不感到敬畏，因为只不过是适用场合的问题。如果你说写Java你不用IDE，我的确会感到敬畏，而且十分想了解你们是杂么做的，我还特此发了个邮件给沈大，结果得到的答复不过是戏謔之词。我本人的Vim技巧大抵不会比你们公司里任何人差，相信还比大多数人好，
> 我在公司内部的例会上还做过专门的Vim演示去推广，发过邮件给Vim的作者提示他的Vim主页上没有加上他名字的中文版本，并且得到了该作者的答复和更正。我从来不正面刻意的去宣扬非IDE的意义，相反我在某些场合推荐IDE的存在，尤其是在Python的领域，这不代表我不知道Vim/Emacs系的好处，而是我更深知选择他们的场合。我研究过python.vim的源码说实话，真的够烂的。我也研究过pydev的eclipse
> plugin, 说实话，真的很用心的在写。如果你们是做Python Web的，我认为不使用IDE大致问题不是那么大，因为在一个稳定的web
> framework之下，需要掌握的api就那么几个，从一个request过来到一个response返回就这点破事，比较费劲的是业务逻辑，完全是用基础的Python语法就可以应付。如果你们是写PyQt一类，对不起，用Vim之类是自虐。因为那是C++的原生接口，Python
> 只是胶水语言，大妈扯到 Python 接口可以减少参数输入，在这里是不适用的。尤其面对成千上百个 GUI API
> 每个API有诺干个参数，每种参数的输入有各自的界面效果，再加上各个API之间的叠加效果。好吧，还是郑重推荐
> PyDev。还是那句话，看场合，分情况来解决问题。
>
> 最大的问题就在这里，用 Python 和 用 Vim/Emacs 一样，并不显得你比别人高一等。说话做人都不要那么偏激，不用把其它诸如
> Java, IDE, 静态检查都说的一文不值，相反我印象里 Pythoner 更应该低调才是，两个字概括“暗爽”。
>
> 你们有一个除了大姐都在用Linux或者Mac的环境，很好没问题。我在一个几百人都用Windows的IT公司里，应该比贵公司的市值要高很多很多倍。一个人一点一点的给自己开发机上的Ubuntu配置了能运行公司代码的工作环境
> -- 我的桌面永远都是紫红色的。

环境无非是由人组成的，只要有足够多的靠谱的人什么环境都可以有。
这样简单的问题只要看一眼代码就可以发现吧，如果这么简单的问题都需要依赖工具来帮忙发现，那怎么能相信他可以发现复杂的问题？
用不用IDE全凭个人爱好，不用IDE完全不需要被敬畏，没有写过Java，不过既然提供了命令行的编译工具，应该也有办法不用IDE吧，不过仍然看个人爱好。
Python写了很多年，用过 zope/plone, twisted, django, 没用过PyQT,
但是写了不少wxPython的东西, 一直用vim来写程序, 不会用emacs,
vim对于我来说就是一个用的顺手的编辑器而已，估计你的vim用的比我好，我既没有研究过vim的源码，也没有跟vim的作者通过信。pydev没有用过，但是看过别人用，好像时不时的会弹出一个提示框，估计关来关去的应该挺烦人的吧，不过既然你这么喜欢可能会直接购买那就没有这个问题了。可能没有写过PyQT吧所以没有体会过你所说的用vim写Python如何的自虐。
从来没有觉得用Python或者vim比别人高一等，无非混口饭吃，暗地里也没有觉得有什么爽的。
我离开Exoweb的时候只有50个左右人，现在3年过去了，应该也不超过100人，市值肯定没有你们几百人的公司高，几百人光买
Windows的license 得多少钱啊，别说还得买杀毒的杀什么的了，我们可是小公司，真买不起啊。
你能一点一点的给自己配置Ubuntu比我强多了，我很懒所以用Mac，我的桌面是我闺女的照片。我们原来的财务大姐非常的让我敬畏，她居然连税控机，税控软件都弄的明白，太不可思议了，我真不成。

[机械唯物主义 : linjunhalida]

建议大家到此为止吧, 上面已经有点脱离技术讨论了.
不同人的回复, 已经把该说的都说清楚了, 有很多可以细读的部分.

[ygao]

2010/12/29 Zhang Jiawei <gho...@gmail.com>

做的确实非常好。

我也补充几点：
1. 这样环境并非哪里都有。
2. 你们的流程非常好，但是仅仅从描述我都感受到了巨大的人肉成本，所以我们从来都在说一个意思，但是我更倾向于简单的问题能用工具就用工具去提早发现，复杂的问题才需要人肉介入。

没有IDE存在我个人并不感到敬畏，因为只不过是适用场合的问题。如果你说写Java你不用IDE，我的确会感到敬畏，而且十分想了解你们是杂么做的，我还特此发了个邮件给沈大，结果得到的答复不过是戏謔之词。我本人的Vim技巧大抵不会比你们公司里任何人差，相信还比大多数人好，
我在公司内部的例会上还做过专门的Vim演示去推广，发过邮件给Vim的作者提示他的Vim主页上没有加上他名字的中文版本，并且得到了该作者的答复和更正。我从来不正面刻意的去宣扬非IDE的意义，相反我在某些场合推荐IDE的存在，尤其是在Python的领域，这不代表我不知道Vim/Emacs系的好处，而是我更深知选择他们的场合。我研究过python.vim的源码说实话，真的够烂的。我也研究过pydev的eclipse
plugin, 说实话，真的很用心的在写。如果你们是做Python Web的，我认为不使用IDE大致问题不是那么大，因为在一个稳定的web
framework之下，需要掌握的api就那么几个，从一个request过来到一个response返回就这点破事，比较费劲的是业务逻辑，完全是用基础的Python语法就可以应付。如果你们是写PyQt一类，对不起，用Vim之类是自虐。因为那是C++的原生接口，Python
只是胶水语言，大妈扯到 Python 接口可以减少参数输入，在这里是不适用的。尤其面对成千上百个 GUI API
每个API有诺干个参数，每种参数的输入有各自的界面效果，再加上各个API之间的叠加效果。好吧，还是郑重推荐
PyDev。还是那句话，看场合，分情况来解决问题。

我未见到python写的比较大型的界面较复杂的GUI程序,＂胶水语言＂就是＂胶水语言＂

PyDev这个IDE并不能起到静态型IDE那样的作用，

最重要的是请不要用静态编译型语言的思路来看动态语言，这个鸿沟到现在也无法融合．

--
※※※※※※
by  ygao

[Zoom.Quiet]

在 2010年12月29日 下午5:07，Zhang Jiawei <gho...@gmail.com> 写道：
> 其实帖子写到这个程度，我总结几个问题：
>
跳到这儿来回复,不过,的确方方面面都说到了,可以打住了,因为結論不必有,大家共同追求自个儿的爽出来分享就好 ;-)

> 1. 回到本楼第一贴看一看我们在什么案例下讨论问题。
俺是特意看了一下原始邮件的(这是列表不是BBS,用贴来代表邮件很别扭;-)
也斟酌在三，还是使用了比较搞的语气来回复，得聲明，绝对不是冲 Jiawei 个人，
而是冲中国这个神奇的IT环境，只要是能赚钱就是好技术好方案好产品的神奇市場!

俺已经强调了，大家其实谈的是同一问题的不同位面:
- 怎么确保团队的代码品质？！
Jiawei 习惯从中国现实出发,为廉价的团队着想,通过实效的工具来确保最基础的质量;
俺们几个吐槽的,习惯性的期望团队自身每个人"向靠谱,反脑残",不期望有神马工具来拯救已经被学校弄诱斗的码农,强调只有自个儿努力,团队配合,通过湿件的不断进化来确保代码的质量;
...

> 4. 我真的没觉得动态语言静态语言哪个好哪个不好。不过是想用其长，避其短。该用什么用什么。

这个看出来了,俺也非常认同,只是真的难以忍受作打字员而已 ...

> 5. 以下措辞并不能表达您的观点真的正确：扯淡，王道，伪命题，不靠谱，吼，只有句式。
>

嗯嗯嗯,忘记给出俺公开的句式解释了...
http://wiki.woodpecker.org.cn/moin/KaoPulity

> 诸位说的都对，我和诸位真的在讲一个意思。您抱着敌视心态，在我的每一句下面加自己的注解，首先是没用心看我到底在说什么，其次也没回第一楼看我们讨论问题的前提，您有这样的态度，我说的全是错的，您注解的全是对的。好吧，这个帖子我真的不想回了。
>

介个,邮件列表的礼节哪: http://zoomquiet.org/res/s5/050730-usMaillist/
很早以前,大家就讨论过,多数认可古老的 底回复 方式哪,这可绝对不是敌视心态的表现,
而是认真回复的表现哪... FT! 这误解忒天涯了...

好的,感谢 Jiawei 引发这么精彩的讨论,为俺粗暴的口号式回复道歉,
CPyUG 的分享氛围不会因为我个人的语气而变化的,
欢迎分享你在高市值团队中的 Pythonic 体验,
这的确是绝大多数长时间在低市值小公司的码农们无法体验到的.

[Shell Xu]

deluge & comix

其实不算太复杂，再复杂就是后台直接玩手工渲染了往设备上贴了。

无能者无所求，饱食而遨游，泛若不系之舟

[sj l]

结贴吧！

>原因有两个：

>1. python 程序员基本不用什么IDE, 如果使用 pydev 之类, 大致还能依靠 IDE 在merge 以后看到这个错。

>2. python 没有编译的概念，没有机会看到编译器对这个语法问题的报错。

这个问题为什么会那么多人不以为然，是因为该提问的老兄一开始就认为就是pyer不用ide的原因和py没有编译的原因。当然会有很多人不满了；正如智拙大师所言，这确实是测试不严谨的原因，两个人都更新了代码，却没有再做测试，已经是团队的问题了。

这个的背后则是思维的鸿沟，提问的老兄坚持用java的角度看py；学一门新语言来说，就应该有从新思维考虑问题的准备。对待bug上，java喜欢用try catch隐藏所有异常，而py则鼓励主动raise异常。两者的方式是有很多区别的。无论用java的观点看py还是用py的观点看java都不太适应的。

提问的老兄似乎并不喜欢别人用注贴的方式回复，但并不代表别人不尊重你的帖子，只是注贴的回复方式确实是简单方便的。

2010/12/29 Shell Xu <shell...@gmail.com>

[Zhang Jiawei]

这个帖子引发的情绪在最后几贴里都可以得到平复了。我们都有让别人赞同自己的诉求，更有被误解后的愤怒，其实都不重要，我们可以只活在自己的哲学里，只要那一套对你适用。所有华蟒用户组的成员聚集在这里，我们的远景和目标并没有太大差异。锱铢必较不过是程序员的思维定势，偶有口角纷争无伤大雅。

高市值公司需要推动任何一个变化都要付出十分的代价，更不用说改旗易帜的使用Python，
所以我没有什么Pythonic的经验可以分享。不过是想做一个睁眼开世界的人。这里才是创新的源泉，未来的希望。向华蟒致敬。

结贴吧。

Regards,
Jiawei Zhang

[hammer]

个人认为，小项目应该通过单元测试发现。
大项目A的行为不应该出现。真的需要A应该自己另外弄一个新的函数，再调用老函数也可以。

[Zhang Jiawei]

如此这般，那就是再也改不得老函数了。俄罗斯套娃，一层层的。

[pansz]

2011/2/21 Zhang Jiawei <gho...@gmail.com>:
> 如此这般，那就是再也改不得老函数了。俄罗斯套娃，一层层的。
>

修改当然可以，不过新的行为应与旧行为兼容。

例如原先的函数是一个参数，现在变成两个参数，但是你可以搞个缺省值，当第二参数为缺省值时，函数参数的含义同原来的版本。

例如原先的函数是两个参数，现在变成一个参数，你也同样可以给第二个参数搞缺省值，为缺省值的时候，使用新版本的含义。

[Zhang Jiawei]

如此这般，所有的老函数都有一个缺省值了。即使原本是可以不需要的。

[pansz]

2011/2/22 Zhang Jiawei <gho...@gmail.com>:
> 如此这般，所有的老函数都有一个缺省值了。即使原本是可以不需要的。

你需要经常的大量的变更已经被深入部署的程序中的老函数么？

如果你需要经常的大量的做这种行为，那么架构设计师的职位是否应该重新考虑一下了？如果不是，何来“所有的老函数都要缺省值”一说。需要修改接口的往往仅仅只是个别函数。

当然如果并没有非常深入的部署，那么全代码搜索一下关键字直接找到调用对应函数的相关程序员全面修改一下可能是更简单的方案。

[Zhang Jiawei]

我只是不想因为解决这个问题，改变程序员写代码的方式。

套函数也好，加默认值也好，这些都不应该为了解决版本问题而存在。

的确，不是所有的老函数都会有一个缺省值，但是我更厌恶哪怕只有一个老函数因为这个问题而加了缺省值。

[ubunoon]

说到这儿，我也添上两句，相比较Eclipse的IDE工具（或其衍生品）一统Java IDE市场的情况，Python的IDE每个人使用的统一性并没有那么多，不说IDE的好坏，大部分人的技术水平，没有使用vim那样的技术水平。多快好省是每个人都追求的，一个是手头上直接看得到的多快好省，一个是通过长时间学习后才可以得到的多快好省，通常的人会因为时间，精力等原因，选择直接看得到的东西，也就是IDE工具。

对于Jiawei提供的问题，其实并不算特别的问题，既然是python语言，动态语言有动态语言的特性，在Jiawei提出的问题中，我不知道是否存在**kwargs类似的参数，不管存在也好，不存在也好。如果a.py中新增一个参数，为什么一定要在函数列表中体现出来呢？用静态语言的想法来控制函数原型，本身就有些问题。如果你非要在a.py的函数中增加一个参数，那么可以引入**kwargs，然后在a.py中进行相关的参数判断与查询，增加注释，提供新版本的功能。

本来不同的人开发不同的接口，接口之间的信息是规定好的，A修改了函数接口，必定会对函数之间的调用产生影响。说到静态语言，在源代码情况下，在有IDE存在的情况下，是可以修改的。但是如果是多个复杂的调用，那么静态语言因为接口之间的修改导致影响更多的文件，修改这些文件也是一件非常巨大的问题，这也是静态语言（如C++）引入最后的默认参数的原因之一，从而避免修改更多文件，导致引入新的bug问题。

目前的编程，尤其是OOP的说法，更是极力提到接口的编程，如此，接口更加不能做过多的修改，这个是这个思想的问题，不是语言的问题。

--
To be pythoner
My blog: http://www.cnblogs.com/ubunoon/
珍珠饰品：http://zjyuezz.cn.alibaba.com/

English blog：http://qtrstudio.com/blog

粮食机械：http://qtrstudio.com/grainmachine/