为什么糟糕的科学代码战胜了遵循“最佳实践”的代码

2014-05-19 17:02


我刚刚读了“科学代码的低品质”,它声称科学家写的代码比有“软件工程师”参与的代码要更糟糕些。

我所处的工作环境有十多年了,那里由具有数学或物理学背景的人统治,他们经常缺少“软件工程师”的认识。

最大的麻烦总是由大多数把自己定位成程序员的人造成的。我愿意承认我至少造成了一堆麻烦,至今没有清理完。也有一些其它的大麻烦,代码幸运地被浪费了,这意味着对我老板的伤害被限制到了浪费在我自己工资上,没有给其他人的生产效率带来负面影响。

多数情况,我承认有些忏悔。我宁可尽力保持事情足够简单,我不认为我已经做到了,在过去的5-6年里,有些事情让很多人很好笑地看着我,他们已经把一天最美好的时光花在了我的带有小聪明的产品处理上。

我认识一些没有明确忏悔过的程序员。人们觉得他们滑稽,他们却认为自己是对的,其他每个人都是疯子。

同时,那些“不是”程序员、但更多是个数学家、物理学家、算法设计者,科学家的那些人,你给他们列举了如下种类的罪状:

  • 很长的函数
  • 糟糕的命名(m, k, longWindedNameThatYouCantReallyReadBTWProgrammersDoThatALotToo)
  • 访问所有的地方——全局/singleton,“神器(God Objects)”等
  • 崩溃(空指针,边界错误),由工具集/大规模测试来大量减少
  • 在类似bug上完全缺乏兴趣(差不多依赖工具减少)
  • 不合适地勉强使用聪明程序员写的类库,包含了过多的操作符、模板和东东

你看,我可以处理这种事情了。我很少碰到问题,如果有人想让我帮忙调试代码,以找出这些家伙正在试图做什么。我是指在软件意义上。算法上或许我帮不上忙。但是我通常知道 他们想让什么变量传递给什么函数。

软件工程师不全是这样,他们的罪行可以完整归类如下:

  • Multiple/virtual/high-on-crack继承
  • 主要由一些瘦封装器以及一些函数指针/虚函数组成的、可能在中断处理(interrupt handlers)内部或不在内部的7到14个堆栈块(stack frames)
  • 文件在多个文件夹传播
  • 使用来自地狱的动态结构查找文件夹名字,这些名字由运行时的各种片段拼凑而成,等等。
  • 动态加载和其它grep-defeating技术
  • 一大群不易辨认的名字,比如DriverController, ControllerManager, DriverManager, ManagerController, controlDriver ad infinitum—彼此互相调用
  • Templates调用带有声明的、期望可见的重载函数,在那个地方template被定义了,也可能没有定义。
  • Decorators、metaclasses、代码生成等等

后果是你不知道谁调用了什么或为什么调用,调试器充其量能用,IDE和grep正慢慢、可怕地死去等。在眼泪不由自主地从你的眼睛流出来之前,你确实得放弃搞清楚的打算。

当然这是一个显而易见的夸张,不是每个人一直是一个罪犯,比如,我原则上是一名“程序员”而不是“科学家”,我强烈认为毕竟我有一个积极的生产力,只是你产生了那个想法。

科学代码能够从更好的“软件工程师”那里受益吗?或许是,但是我不会相信软件工程师会带来那些好处!

思想简单,无忧无虑,几近不称职可能比向地狱铺一条高速公路的强劲的、好的计划要好些。计算机之外的“真正世界”充满了这样的例子。

哦,恐怕一个真正残忍的观察太过真实而无法忽略:懒惰是很多麻烦的根源。一个科学家要操心他自己的学科,因此他没有时间去不必要地复杂化代码。很多程序员在工作上没有真正的实质—他们的工作是琐碎的—因此他们手头有太多的时间,他们习惯了思索“API 设计”,因此庞然大物就出现了。

(事实上,当工作从技术上远离琐碎/或在社会上,程序员可怕的训练把他们的关注从当前责任移走的时候——该死的事情实际上是工作,易用、有效/便宜,等?——取而代之的是,他们宣称除了着手于超出信任的复杂化可怕的API,什么也不用负责任。同时,从功能上讲,事情很少起作用。)

原文地址:http://www.yosefk.com/blog/why-bad-scientific-code-beats-code-following-best-practices.html 

via : http://www.labazhou.net/2014/05/why-bad-scientific-code-beats-code-following-best-practices/