為什么糟糕的科學(xué)代碼戰(zhàn)勝了遵循“最佳實(shí)踐”的代碼
我剛剛讀了“科學(xué)代碼的低品質(zhì)”,它聲稱科學(xué)家寫的代碼比有“軟件工程師”參與的代碼要更糟糕些。
我所處的工作環(huán)境有十多年了,那里由具有數(shù)學(xué)或物理學(xué)背景的人統(tǒng)治,他們經(jīng)常缺少“軟件工程師”的認(rèn)識(shí)。
最大的麻煩總是由大多數(shù)把自己定位成程序員的人造成的。我愿意承認(rèn)我至少造成了一堆麻煩,至今沒有清理完。也有一些其它的大麻煩,代碼幸運(yùn)地被浪費(fèi)了,這意味著對(duì)我老板的傷害被限制到了浪費(fèi)在我自己工資上,沒有給其他人的生產(chǎn)效率帶來負(fù)面影響。
多數(shù)情況,我承認(rèn)有些懺悔。我寧可盡力保持事情足夠簡單,我不認(rèn)為我已經(jīng)做到了,在過去的5-6年里,有些事情讓很多人很好笑地看著我,他們已經(jīng)把一天最美好的時(shí)光花在了我的帶有小聰明的產(chǎn)品處理上。
我認(rèn)識(shí)一些沒有明確懺悔過的程序員。人們覺得他們滑稽,他們卻認(rèn)為自己是對(duì)的,其他每個(gè)人都是瘋子。
同時(shí),那些“不是”程序員、但更多是個(gè)數(shù)學(xué)家、物理學(xué)家、算法設(shè)計(jì)者,科學(xué)家的那些人,你給他們列舉了如下種類的罪狀:
- 很長的函數(shù)
- 糟糕的命名(m, k, longWindedNameThatYouCantReallyReadBTWProgrammersDoThatALotToo)
- 訪問所有的地方——全局/singleton,“神器(God Objects)”等
- 崩潰(空指針,邊界錯(cuò)誤),由工具集/大規(guī)模測(cè)試來大量減少
- 在類似bug上完全缺乏興趣(差不多依賴工具減少)
- 不合適地勉強(qiáng)使用聰明程序員寫的類庫,包含了過多的操作符、模板和東東
你看,我可以處理這種事情了。我很少碰到問題,如果有人想讓我?guī)兔φ{(diào)試代碼,以找出這些家伙正在試圖做什么。我是指在軟件意義上。算法上或許我?guī)筒簧厦?。但是我通常知?他們想讓什么變量傳遞給什么函數(shù)。
軟件工程師不全是這樣,他們的罪行可以完整歸類如下:
- Multiple/virtual/high-on-crack繼承
- 主要由一些瘦封裝器以及一些函數(shù)指針/虛函數(shù)組成的、可能在中斷處理(interrupt handlers)內(nèi)部或不在內(nèi)部的7到14個(gè)堆棧塊(stack frames)
- 文件在多個(gè)文件夾傳播
- 使用來自地獄的動(dòng)態(tài)結(jié)構(gòu)查找文件夾名字,這些名字由運(yùn)行時(shí)的各種片段拼湊而成,等等。
- 動(dòng)態(tài)加載和其它grep-defeating技術(shù)
- 一大群不易辨認(rèn)的名字,比如DriverController, ControllerManager, DriverManager, ManagerController, controlDriver ad infinitum—彼此互相調(diào)用
- Templates調(diào)用帶有聲明的、期望可見的重載函數(shù),在那個(gè)地方template被定義了,也可能沒有定義。
- Decorators、metaclasses、代碼生成等等
后果是你不知道誰調(diào)用了什么或?yàn)槭裁凑{(diào)用,調(diào)試器充其量能用,IDE和grep正慢慢、可怕地死去等。在眼淚不由自主地從你的眼睛流出來之前,你確實(shí)得放棄搞清楚的打算。
當(dāng)然這是一個(gè)顯而易見的夸張,不是每個(gè)人一直是一個(gè)罪犯,比如,我原則上是一名“程序員”而不是“科學(xué)家”,我強(qiáng)烈認(rèn)為畢竟我有一個(gè)積極的生產(chǎn)力,只是你產(chǎn)生了那個(gè)想法。
科學(xué)代碼能夠從更好的“軟件工程師”那里受益嗎?或許是,但是我不會(huì)相信軟件工程師會(huì)帶來那些好處!
思想簡單,無憂無慮,幾近不稱職可能比向地獄鋪一條高速公路的強(qiáng)勁的、好的計(jì)劃要好些。計(jì)算機(jī)之外的“真正世界”充滿了這樣的例子。
哦,恐怕一個(gè)真正殘忍的觀察太過真實(shí)而無法忽略:懶惰是很多麻煩的根源。一個(gè)科學(xué)家要操心他自己的學(xué)科,因此他沒有時(shí)間去不必要地復(fù)雜化代碼。很多程序員在工作上沒有真正的實(shí)質(zhì)—他們的工作是瑣碎的—因此他們手頭有太多的時(shí)間,他們習(xí)慣了思索“API 設(shè)計(jì)”,因此龐然大物就出現(xiàn)了。
(事實(shí)上,當(dāng)工作從技術(shù)上遠(yuǎn)離瑣碎/或在社會(huì)上,程序員可怕的訓(xùn)練把他們的關(guān)注從當(dāng)前責(zé)任移走的時(shí)候——該死的事情實(shí)際上是工作,易用、有效/便宜,等?——取而代之的是,他們宣稱除了著手于超出信任的復(fù)雜化可怕的API,什么也不用負(fù)責(zé)任。同時(shí),從功能上講,事情很少起作用。)
英文:http://www.yosefk.com/blog/why-bad-scientific-code-beats-code-following-best-practices.html
譯文:http://www.labazhou.net/2014/05/why-bad-scientific-code-beats-code-following-best-practices/