為什麼糟糕的科學程式碼戰勝了遵循“最佳實踐”的程式碼
我剛剛讀了“科學程式碼的低品質”,它聲稱科學家寫的程式碼比有“軟體工程師”參與的程式碼要更糟糕些。
我所處的工作環境有十多年了,那裡由具有數學或物理學背景的人統治,他們經常缺少“軟體工程師”的認識。
最大的麻煩總是由大多數把自己定位成程式設計師的人造成的。我願意承認我至少造成了一堆麻煩,至今沒有清理完。也有一些其它的大麻煩,程式碼幸運地被浪費了,這意味著對我老闆的傷害被限制到了浪費在我自己工資上,沒有給其他人的生產效率帶來負面影響。
多數情況,我承認有些懺悔。我寧可盡力保持事情足夠簡單,我不認為我已經做到了,在過去的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
相關文章
- 為什麼程式設計師總是寫糟糕的程式碼?這3個原因程式設計師
- 為什麼糟糕的軟體成功了
- 程式碼審查最佳實踐
- 編寫優雅程式碼的最佳實踐
- 為什麼說一個好的Java程式設計師,是無碼勝有碼?Java程式設計師
- React 程式碼共享最佳實踐方式React
- React 整潔程式碼最佳實踐React
- 我見過的最糟糕的程式程式碼
- 我的最糟糕程式碼列表
- 程式碼不等於電腦科學:為什麼所有人都應該學習程式設計程式設計
- 為什麼說GitOps是基礎架構即程式碼 (IaC) 和 DevOps 最佳實踐?Git架構dev
- 好程式碼的科學定義
- dart系列之:dart程式碼最佳實踐Dart
- [譯] 程式碼審查之最佳實踐
- 【翻譯】編寫程式碼註釋的最佳實踐
- 編寫高效能 Java 程式碼的最佳實踐Java
- Java Web應用的程式碼分層最佳實踐。JavaWeb
- 13 年來,我寫了這些糟糕的遊戲程式碼遊戲
- 程式碼審計是什麼?網路安全實戰學習技能
- 你的JavaScript程式碼都經歷了什麼JavaScript
- 為什麼說php是最糟糕的,也是最好的程式語言PHP
- 為什麼Go是一種設計糟糕的程式語言Go
- 什麼樣的程式碼才算是好程式碼
- 讓程式碼具有可讀性的10種最佳實踐
- 11 個高效的同行程式碼審查最佳實踐行程
- Vert.x 程式碼結構最佳實踐
- 最佳實踐之 Android程式碼規範Android
- 拿什麼拯救你,我的程式碼--c#編碼規範實戰篇C#
- 你構建的程式碼為什麼這麼大
- 碼農深耕 - 什麼樣的程式碼才是好程式碼?
- 為什麼你寫的程式碼糟透了?
- 為什麼我看不懂你的程式碼
- 為什麼你的程式碼如此難以理解
- 為什麼要做程式碼審計?
- 為什麼程式設計師不遵循簡單性?程式設計師
- 什麼樣的程式碼稱得上是好程式碼?
- 程式碼審查或評審的最佳實踐 - FogBugz
- 編寫超級可讀程式碼的15個最佳實踐