因不能出去浪,程序员开始怼科学家写的代码了…(图)

果壳 0

今年3月以后,世界上很多国家都因为新冠疫情的肆虐封锁了边境。英国政府曾提出“群体免疫”策略,不过在参考了一些学术机构的报告后,最终采取的还是封锁隔离政策。而这些学术报告中最值得一提的,就是英国帝国理工学院(IC)的研究报告,该报告建议务必实施严格的封锁。

人们的生活随封锁发生了天翻地覆的变化。当大家不能再随意握手、拥抱,当很多礼节与风俗都需要改变甚至避免时,人们肯定想问,疫情真的有那么严重吗?

疫情就像是怀疑论的温床。英国就有一个叫做“质疑封城”(lockdownsceptics.org)的网站,怀疑论者们会在上面发布一些有关封锁的新闻,并刊载一些反对封锁的观点与分析。



“质疑封城”网站最近的文章——肥胖的人们:你们不用担心死于冠状病毒丨截图

既然不愿相信疫情的严重性,也不断否定封锁政策的价值,怀疑论者当然就要从政策所依赖的研究下手。如果帝国理工学院的研究不再可信了,据此施行封锁还有什么道理呢?

尼尔·弗格森(Neil Ferguson)是一位数学生物学教授,在帝国理工全球传染病分析中心担任疫情建模负责人,他也是整个封锁政策的核心人物。今年5月,因封城期间被爆出破坏自己立的规矩,私会情人,弗格森教授被迫辞职。在他陷入风波的时候,不少怀疑论者更是利用弗格森教授信用危机的机会,对他主导的研究进行批评。

  这是一场“带风向”的争论  

今年5月初,一名自称是谷歌前员工的人在“质疑封城”网站上发表了一篇文章,内容是对弗格森教授疫情研究所用的代码进行评审。



一名自称是谷歌前员工的人在“质疑封城”网站上发表了一篇文章,内容是对弗格森教授疫情研究所用的代码进行评审丨截图

帝国理工学院会把他们的研究代码上传到github。github 是一个开放源代码、让全世界程序员协作编写软件的网站。既然大家都能看到研究的代码了,那么就可以针对代码进行评审。所谓的代码评审(code review),通常是程序员们你看我写的代码,我看你写的代码,互相挑错,弄完之后项目质量就会变棒棒的一种活动。

而这篇文章并没有对项目的核心部分提出什么有价值的分析与质疑,结论却是“只要用到这项研究代码的论文,都应该立刻被撤回”。这篇文章为“质疑封城”吸引了大量流量,网站月均浏览量从不到10万增长到超过40万。目前文章已经有快700条留言,其中一个用户留言说,要去源代码所在的地方发布一个 issue ,目的呢,也是要求撤回论文。

github issue 就像社区中的帖子一样,是供大家讨论事情的,不过得讨论项目有关的问题,尽量别跑题。让我们先来看下这个项目之前的 issue 是什么样的:

1)某个文件第几行的代码,关于每年有多少天的变量应该是365而不是364,还有会不会其实应该是365.25?下面的回复解释了为什么要用364而不是365,大家都了解以后此 issue 被关闭。

2)某个部分的运行需要测试。回复里有人说,是的呢,但你提到的测试类型不一定合适,你有具体的测试策略吗?之后又有人提出这里有我写的测试代码,若是合适的话请合并到项目里。

也就是说,提出一个 issue ,主要目的在于对这个项目能有所贡献,无论是指出它的问题,还是提出应改进的地方,之后大家围绕项目代码你给点意见我提交下代码,最后这个项目就变得更好了。

可怀疑论者发布的这个 issue 说了些啥呢?“这些代码的测试太烂了,无法用于科学目的,不符合科学方法”,“因为这项研究,几十亿人的生活被打乱”,“作为公共政策,是以此研究非常准确为前提的,这真是个灾难”,“程序员们,请签名以表赞同吧”。



issue:呼吁立即撤回所有以该代码库为基础的论文,请程序员们签名表示赞同。丨截图

帝国理工学院从3年前就在 github 上发布其各项研究所使用的代码,但并没有什么人看。可这样的一个 issue 一经发表,却吸引了很多不明真相的人前来围观。点击收藏此项目的人数从不到300快速增加到了接近900。

弗格森教授其实是重用了13年前用于流感大流行建模的代码,而在发布前它已经在 github 与微软的帮助下大大改进了,参与改进的人还包括传奇程序员、自由软件倡导者约翰·卡马克(John Carmack)。13年在软件工程领域算是不短的时间,并且经过了这么多人的努力,目前的代码已经比较符合现代规范。而事实也证明,英国政府采取帝国理工学院建议的封锁策略后,死亡人数下降为预期的1/28。

故事到此就很清晰了,这个issue明显是要带风向,去否定研究得出的结论。怀疑论者是在利用程序员的身份与专业背景去挑战弗格森的研究,进而表达自己的政治诉求。他们之前就一直在指控是帝国理工学院与弗格森教授让大家倒了霉,整个西方经济都因此停滞。“代码发布在 github 上了?太好了,公开了就好办了,集中炮火打击”,这就是他们的想法。

  “代码风格”很重要,却不一定影响结果  

可为什么很多程序员这么容易就被人利用了呢?因为上面提到的issue还提到了项目的代码风格很烂,大家一寻思,这种情况下的软件一般都问题不断。据此推测,这项研究也肯定漏洞百出了。

代码风格究竟重不重要其实在软件行业里也是一直受争论的话题。良好的代码风格,特点是使代码易读,比如一个人的名字被用作变量,那么起名叫 name 就比 x 强很多,这不仅利于项目进行中的协作,对之后的维护工作也至关重要。对代码风格的追求主要是因为在现代软件行业中,协作是无法避免的事儿,你写完的代码还得给其他人看,也无可避免地需要修改其他人遗留下的代码。一个项目以后再想加点什么、减点什么、改点这里、修点那里,要是看不懂可就没招儿了,这也就是对软件行业的重构有所帮助。



良好的代码风格,有利于项目进行中的协作,对之后的维护工作也至关重要,但不见得就跟最后的结果有直接关系。丨图虫创意

不过话说回来,很多时候,代码写得漂不漂亮也不见得就跟最后的结果有直接关系。比如之前大火的游戏《太吾绘卷》,它的作者就不咋懂写代码,整得一团乱,但也没碍着作品创意。科研工作怎么写代码,写什么样的代码,是科研人员为了得出结论所用到的手段罢了。这种情况下,可能过程就真没有结果那么重要。

事实上,不少重要的数学代码库都是由科研人员编写,若有意愿的话,他们有能力写出优美健壮的代码。但现实中,不少科研人员都需要迅速发表论文,这时候他们的代码在专业程序员眼中就没那么专业或者严谨了。人人都希望看到质量良好的代码,把代码公开可能是帮助其改进质量的第一步。

  公开代码,需要善意的环境  

在专业人员的指导下,通过专业方法,科研领域的代码风格应该会越变越好。

当然,一切的前提是善意。都是程序员,有些呢,对缓解新冠疫情作出了自己的贡献,他们根据公开的源代码,提出问题和建议,改进项目。可另一些呢,比如那些怀疑论者们,基本就是在添乱了。立场和偏好会先入为主地影响对事情的判断,即使很多程序员明白代码风格不等同于软件质量或科研成果,还是会因为以上原因去攻击对方。

这些举动是很危险的,它可能会减少科学家们公开代码的动力,甚至还会使得正当的同行评审更加困难。



通过专业方法,科研领域的代码风格应该会越变越好,当然一切的前提是善意。丨图虫创意

每项公共政策乃至每项科学研究都可能有争议,很难让所有人满意,也很难令所有人信服。今年的疫情或许让社会气氛变得更加紧张,什么政策都会被用放大镜检视。

其实之前英国 “气候门”(Climategate)事件就与这次反对封锁的情况有些相像。当时英国东安格里亚大学气候研究小组的邮件往来被黑客入侵,随后该小组被指控操纵数据、伪造科学流程。最终英国独立调查人员在彻底调查后指出:科研人员诚信完好,方法健全,但缺乏透明度,建议公开所有相关的数据与代码。

在此之后,公开研究使用的代码在气候学领域已被普遍实践,那么在其他领域的科学研究中,这种举措是否值得参考?在今年疫情中,把相关研究的代码公开,程序员们或许也能更好地理解科研是如何进行的。与此同时,因为参与开源,所有人都可以为科研代码质量的提高贡献自己的一份力量,建议与批评也都会更加有理有据。 阅读原文

文章来源: 留园 查看原文
https://www.6parknews.com/newspark/view.php?app=news&act=view&nid=430183
分享文章:
还没有评论
登录后发表评论
返回 到顶部