我剛剛讀了“科學代碼的低品質”，它聲稱科學家寫的代碼比有“軟件工程師”參與的代碼要更糟糕些。

我所處的工作環境有十多年了，那里由具有數學或物理學背景的人統治，他們經常缺少“軟件工程師”的認識。

最大的麻煩總是由大多數把自己定位成程序員的人造成的。我愿意承認我至少造成了一堆麻煩，至今沒有清理完。也有一些其它的大麻煩，代碼幸運地被浪費了，這意味著對我老板的傷害被限制到了浪費在我自己工資上，沒有給其他人的生產效率帶來負面影響。

多數情況，我承認有些懺悔。我寧可盡力保持事情足夠簡單，我不認為我已經做到了，在過去的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

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