类似Python这种动态语言的一个疑惑
ZoomQuiet 按: 这是一个经典的学院派开发者进入Pythonic 世界的硬科幻级疑问...
初问
Zhang Jiawei <[email protected]> 发件人当地时间 发送时间 11:33 (GMT+08:00)。发送地当前时间：上午9:56。 ✆ 回复 [email protected] 发送至 python-cn <[email protected]> 日期 2010年12月25日 上午11:33 主题 [CPyUG] 类似Python这种动态语言的一个疑惑
codebase 中 merge 了别人的代码以后。即便双方都没有改动同一个文件，也可能出现这种情况：
- A 只改动了 a.py 的一个方法的传参个数。
- B 改动了 b.py, 并且 b.py 中调用了 a.py 中的那个方法改动前的版本。
merge 了两个文件以后, 程序员基本都不会意识到现在出了问题。
原因有两个：
- python 程序员基本不用什么IDE, 如果使用 pydev 之类, 大致还能依靠 IDE 在merge 以后看到这个错。
- python 没有编译的概念，没有机会看到编译器对这个语法问题的报错。
好了，现在只有等上线以后，通过某个事件触发这个bug了。
请问各位是杂么防范这种问题的？
- unit test ?
强答
沈崴 <[email protected]> 日期 2010年12月28日 上午10:58 主题 [CPyUG] Re: 类似Python这种动态语言的一个疑惑
On 12月25日, 上午3时33分, Zhang Jiawei <[email protected]> wrote:
关于这个问题，
- 首先，我并不认为这是一个真正的 bug。真正的 bug 是改动了 b.py 中接口的逻辑和用途，但是接口名和参数个数并没有变化。这种在编译语言中完全正常的，恰恰才是真正最为危险的情况。
而在讨论中，大家都在想办法保证参数个数必须一致的问题，我这里随便举个例子：
adduser(username, passwod) adduser(name, gender)
作为同名接口，都具有两个参数，甚至都是字符串类型的，而且无论在编译还是运行期都不会报错。似乎符合 “没有出错”这个判断 bug 的标准，但是，这会产生极为严重的问题 —— 真正的逻辑错误。
所以我想说的是：
试图使用静态检查，和使用 IDE 进行参数约束的想法，才是真正危险的！
- 需要明白，报错和 core dump 并不是真正的 bug，也不是敌人。
要写出真正安全，减少 bug 的好程序，就要反过来做，不仅要允许参数不一致，而且还要尽量制造这种错误。
- 除了在 python 和编译语言中都有的 assert 方法，python 提供了更多可以避免这种情况发生的机制。比如显式参数名调用：
如果这样调用 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 ?
所以结论是，不仅不防范，而且还要尽量制造和纵容这种所谓的错误。
继续
On 12月28日, 上午4时59分, Wei guangjing <[email protected]> wrote:
> 在 2010年12月28日 上午10:58，沈崴 <[email protected]>写道： > > 而在讨论中，大家都在想办法保证参数个数必须一致的问题，我这里随便举个例子： > > adduser(username, passwod) > > adduser(name, gender) > > 作为同名接口，都具有两个参数，甚至都是字符串类型的，而且无论在编译还是运行期 > > 都不会报错。 > > 静态语言是不会有这个问题的，因为不可能定义2个同名并有同样参数个数的方法。
两个同名并有同样参数个数的方法
c++ 可以 python 不行。
~沈崴 <[email protected]>
我的意思是，B 在项目里负责共享库 libB.so （相对于 b.py），里面实现了
adduser(username, passwd)
明天 B 把 libB.so 中这个接口改成了
adduser(name, gender) 或者 adduser(name, gender, age)
的情况 
矫枉过正
Zhang Jiawei <[email protected]> 发件人当地时间 发送时间 20:38 (GMT+08:00)。发送地当前时间：上午10:03。 ✆ 回复 [email protected] 发送至 [email protected] 日期 2010年12月28日 下午8:38 主题 Re: [CPyUG] Re: 类似Python这种动态语言的一个疑惑
如果得出这样的结论，我感觉有些矫枉过正了。
- 真的是个bug, 因为用户访问到这个语句行的时候，报错了。
- 我们不可能要求无论谁在写参数列表的时候都用map。
- 我的案例实际上用ＩＤＥ或者其他的静态检查机制其实就可以解决问题，而且安全省力，没有附加步骤。
- 您说的参数语义的内涵发生变化而导致的问题其实开辟了第二个案例。其实静态语言里也存在，用 map也解决不了。因为大家merge代码的时候仍旧没有人意识到这里有问题，只有调用的时候才会发现问题。靠 unit test 应该能检查出来。如果unit test没报错，那么错的也是对的。
- IDE 或者 静态检查 的确检查不出您开辟的第二案例，但不等于 IDE 或者静态编译就是危险的，他们在自己力所能及的范围内检测出某些问题即可。比如我的案例。
- 我还是觉得不用把事情扯到静态语言的动态链接上，事情很简单，适用范围没有那么大，就说两个py之间 和 两个 .c 之间都有互相调用，如果 .c 是静态编译，通过编译器的报错会比执行到py才报错安全的多。即便是动态链接，楼上的朋友说了，参数个数的变化至少是可以通过编译发现的，因为.h 变了。您的第二案例，无论是动态语言还是静态语言都没办法不通过Unit Test解决。
- 我的案例同样是上线了，有问题不出错，和您的案例一样可怕。我和您的案例同样在静悄悄的等待出错的机会。
所以我想说的是:
- 试图使用IDE和静态检查机制解决所有问题是危险的，但是进行参数约束还是安全的，起码参数的个数首先没问题，然后再用Unit Test去保证参数语义的准确。
我的结论依旧，动态语言的出错几率会比静态语言大。靠 静态检查 + Unit Test 双保险解决问题。除此以外自己给自己制造问题太折腾。
另：c/python 好说，我想像不出 java 不用 ＩＤＥ还能用什么写？
Exoweb
[email protected] <[email protected]> 发件人当地时间 发送时间 19:16 (GMT+08:00)。发送地当前时间：下午10:29。 ✆ 主题 Re: [CPyUG] 类似Python这种动态语言的一个疑惑
我说说我原来在Exoweb时，我们的项目是怎么处理你这个问题的吧。
- 首先一个任务在被程序员选择，编写并提交后，无论修改或者添加了任何的功能一定要写至少一个的 test 来保证所修改或者添加的功能的正确性，所以绝大部分的类似的问题在这一层次就可以被堵住了。
- 然后如果有问题突破了test 这一层，那么接下来，任何的一个提交都要由项目组里面的全部或者绝大部分的成员做过 code review 并且没有任何问题后才可以被作为候选的更新等待负责项目更新的人来合并到生产环境中去，这里 team leader 要负绝大部分的责任，一但后续发现某一个提交有问题，那么会直接找team leader 来负责的，当然此处不存在打击报复，但是仍然会被列为此team leader本人的绩效考核中去的。这个项目组内部的code review非常细致，可以细致到某个逗号后面是否应该有一个空格的地步。
- 再次，即便有类似的问题真的突破了项目组的范畴，每一个负责向生产环境更新的负责人，对于所有的要更新到生产环境的代码也要重新进行review，以确保不放过任何一个错误，这里我要说的是，每一个做这个事情的人，都是非常熟悉整个系统的，并且非常的认真负责的，并且这样的工作也是包含在绩效考核中的。
- 最后，谁也不能保证生产环境没有任何的bug，如果出现了bug，简单的可以就地，hot patch，然后给代码库增加一个补丁，复杂的bug那就直接回滚到之前的版本，等修复之后再次更新。一般这样的线上处理也都很快就成处理完。
以上这几个步骤应该能够防范你所遇到的问题了吧？
- 这些步骤实际运行了有几年了一直很顺畅，不过这些是我07年离开Exoweb之前的事了，经过了这3年肯定又有所改变了，不过我想大体上应该还差不多吧，如果有路过的现在在Exoweb的人可以就我所说的不足或者错误或者现在又有什么新的流程再做一下补充吧。
- 补充一点，在我离开的时候，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
~ ZoomQuiet :补充背景,Exoweb 就是 python.cn 域名所有者,也是 CPyUG 列表的前身 [email protected] 列表的发起者,是家面向北欧企业的软件服务厂商,最早在中国使用 Django 进行商用系统开发的外资公司; 企业文化很敏捷, 可以参考以前的会课记录: http://wiki.woodpecker.org.cn/moin/BPUG/2006-08-27
反馈
创建 by -- ZoomQuiet [2010-12-29 02:05:43]