【CSDN 編者按】懶惰是許多問題的根源，許多程式員有太多的時間，他們用這些時間沉迷于“API 設計”，于是就産生了怪物。
本文經授權轉載自寶玉老師的個人部落格(微網誌@寶玉xp )，連結https://baoyu.io/translations/software-engineering/why-bad-scientific-code-beats-code-following-best-practices
原文連結：https://medium.com/@mbostock/what-makes-software-good-943557f8a488
作者 | Proper Fixation
出品 | baoyu.io我剛讀了一篇名為“科學代碼的低品質”的文章，作者認為科學家編寫的代碼品質不如“軟體工程師”的情況。在過去的十多年裡，我一直在一個以數學或實體背景人士為主的環境中工作，這裡的人對“軟體工程”的了解相對有限。一直以來，最大的混亂往往是那些自認為是程式員的少數人造成的。我必須承認，自己也曾制造過幾次大混亂，而這些混亂至今還未得到解決。還有幾次其他的大混亂，幸好代碼被廢棄了，這意味着給我的雇主造成的損害僅限于我薪水的浪費，沒有對他人的工作效率産生負面影響。我聲稱自己基本上已經改過自新了。我努力保持事情的簡單無聊，并且我認為在過去 5-6 年裡，我沒有做過什麼讓許多人因為處理我錯誤的聰明創意而奇怪地看着我。我也知道一些程式員明确地沒有改過自新。人們怪異地看着他們，而他們則認為自己是對的，是其他人瘋了。同時，那些不是程式員，但更像是數學家、實體學家、算法開發者、科學家等人，通常會犯以下幾種錯誤：
- 函數過長
- 取名不佳（如 m、k、longWindedNameThatYouCantReallyReadBTWProgrammersDoThatALotToo）
- 随處通路 – 全局變量/單例、“全能對象”等
- 崩潰（空指針、邊界錯誤），主要依靠 valgrind 和大量測試來減輕
- 對并行程式設計錯誤的漠不關心（幾乎完全依靠工具解決）
- 過于輕易地使用那些由聰明的程式員編寫的庫，這些庫中充滿了重載操作符和模闆等複雜内容
我覺得這些還算可以處理。如果有人需要我的幫助來調試某些東西，我通常能夠了解這些人在軟體方面想要做什麼。在算法層面，我可能不完全了解他們。但是他們想把哪個變量傳遞給哪個函數，我通常都能明白。而軟體工程師的錯誤則完全不同：
- 複雜的多重/虛拟繼承
- 主要由輕量包裝構成的 7 到 14 層棧幀，其中包括函數指針/虛函數，可能還在中斷處理程式中
- 檔案散布在無數目錄中
- 使用來自地獄的動态結構進行查詢 - 如運作時拼接各種部分形成的名稱的字典等
- 動态加載和其他難以追蹤的技術
- 一系列近乎相同的名稱，如 DriverController、ControllerManager、DriverManager、ManagerController、controlDriver 等，它們互相調用
- 模闆調用重載函數，希望在模闆定義的地方可見聲明，或許不可見
- 使用裝飾器、元類、代碼生成等技術
其結果是，你不知道誰調用了什麼或為什麼，調試器的作用有限，內建開發環境和搜尋工具幾乎無法使用。你幾乎不得不放棄了解這一切，直到淚水不自覺地流出。當然，這是一個誇張的描述，不是每個人在任何時候都是罪人，而且我主要是一名“程式員”而不是“科學家”，我真誠地認為我的工作總體上是有積極成效的 - 但你應該明白我的意思。科學代碼能從更好的“軟體工程”中受益嗎？也許可以，但我不相信軟體工程師能帶來這些益處！簡單的思維、無憂無慮的近乎無能有時可能比滿懷好意卻鋪設了通往地獄的高速公路的工業級專業更為有益。計算機外的“真實世界”充滿了這樣的例子。哦，還有一個非常尖銳的觀察，我害怕這太過真實而不能忽略：懶惰是許多問題的根源。科學家忙于科學研究，是以他們沒有時間無謂地增加代碼的複雜度。許多程式員的工作實際上并不複雜 - 任務很簡單 - 是以他們有太多的時間，他們用這些時間沉迷于“API 設計”，于是就産生了怪物。（實際上，當工作在技術或社會層面上遠非瑣碎時，程式員糟糕的訓練使他們的注意力偏離了直接的職責 - 這個東西是否真的運作良好、易于使用、高效/經濟等 - 而是宣稱自己隻負責神聖的 API，并開始使其變得異常複雜。與此同時，從功能上來說，這個東西幾乎無法運作。）
