我可以解決這個問題。這主要是基於我對學術軟件的使用和實施的個人觀點。像已經提到的許多評論一樣，我認為學術界並不認為壞軟件是特定的，甚至不是更常見。就是說，我認為有一些特定於該領域的原因導致出現這種情況。出版物。我認為軟件雖然非常有用，但價值卻很小。通常，軟件實現是最多只能用來增加引用次數（當然存在例外）的旁觀者或概念證明。

作為軟件工程師，我相信您知道生產高質量軟件所需的知識，時間和精力。鑑於學術界的出版或滅亡口頭禪，這一次的投資通常是花在編寫新出版物上。這是風險回報的考慮。

我個人的觀點是，優質軟件非常重要。例如，通常，將新算法與以前的最新技術進行比較的第一步是由於缺乏實現而重新實現了最新技術。顯然，這會引入時間延遲，並可能導致一系列錯誤。就是說，我認為總體而言，直到軟件以某種方式被性能指標所重視之前，幾乎不會有任何改變。場。我認為可以說，大多數研究人員在遇到需要的程序時會自己學習編程。從表面上學習語言通常不是問題，但您需要的不僅僅是知識，而是要生產高質量的軟件（選擇數據結構，設計模式，對該語言的深入了解，等等）。對於沒有計算機科學背景的自學成才的程序員來說，這是一個障礙。

經驗不足的程序員面臨的另一個問題是在需要重構時沒有意識到。您會發現無數結構不良的軟件。在研究中，這是在設計算法時迭代實現的自然結果，該算法演變為充滿駭客的龐大軟件。但是，如果您確切地知道如何很好地問它，那隻怪物可能仍然會按照原意做。對於許多研究人員來說，故事的結局是：獲得結果並永遠將野獸收起。在大聲疾呼出去散步之前，通常需要花費大量時間來清洗怪物。這並不總是值得的。

機器學習的趨勢

我的領域是機器學習，其中軟件的價值越來越高。這種趨勢的例子包括軟件存儲庫的增長和領域中一些知名人士的立場文件。我對這種發展感到非常滿意，因為高質量的軟件可以使整個領域更快地發展並提高可重複性。我知道這在機器學習和統計信息中是可能的。這種軟件通常質量更高。

除了@MarcClaesen的答案外，我還添加化學家的觀點。

• 我是一名編程仿射化學家。根據我的經驗，那是一種稀有物種。在這些網站上可能會少見。雖然也許不比化學實驗室中執行良好實驗室實踐的計算機科學家少見……

• 需要記住的重要一點是學生（至少是化學家）在學習過程中對計算機編程沒有任何介紹。他們可能不得不介紹使用電子表格程序和文獻數據庫搜索的方法，僅此而已。
  我遇到了一個在數據分析繁重的子領域中從事研究實踐和論文工作的學生。遇到一個已經擁有任何編程經驗的學生是非常難得的，即使這個專業“集中”了數學仿射學生。我仍在大學裡尋找好的課程，可以將它們發送給編程的介紹。
  我喜歡軟件木工的概念。但是請注意，甚至沒有介紹編程的思想和思維方式。同樣，我知道的入門材料並沒有真正從學生需要的地方開始。
  （我一直在努力尋找好的入門書，因為在我十幾歲開始編程之前，我很難記住世界的面貌）

• 因此，我認識的大多數非CS科學家都是以自學成才的方式學習編程的。請注意，大多數自然科學家都有思維定勢，他們會探索一種編程語言，就像他們探索未知物質或儀器的行為一樣。由於編程語言是確定性的，因此以這種方式獲得足夠的理解以將一些腳本組合起來以計算出某些東西相對容易。 （我記得一位同事在其Diplom論文期間首次接觸Matlab編程語言。一年後，他“發明”了函數的概念。）但是在您的論文中，您沒有時間學習良好的編程實踐，即使您願意。之後，您將需要工作並產生結果。學習編程語言並不是不可能的，但通常超出了您正在做的事情的預期範圍。預期範圍通常是您知道自己的方法足以進行一些計算。

• 我看到的一個相關的實際問題是沒有專業的程序員在手，所以沒有為學生提供好的編程實踐輔導。我認為這仍然是工作組組織中的盲點。到目前為止，我一直在工作的團隊中沒有一個專業的程序員。有些小組客觀上太小了，負擔不起（至少不是這樣，除非程序員在化學/光譜學實驗室裡也很優秀...-發現這比找到已經學習了良好編程實踐基礎知識的化學家要困難得多） ）。

• 我所知道的大多數“怪獸”程序都是從一個很小的小腳本開始的，這些人剛剛學會了足夠的編程知識，可以將他生命中的第一條有用的線整理在一起。在接下來的2-3年（通常為博士研究）中，這種情況會穩定增長，而且時間總是只會允許改變目前的需求。當人們變得友善時，他們會將怪物交給其他甚至不是程序員的人。 有人會說有足夠的經驗可以退後一步，並根據獲得的經驗進行徹底的重構，博士學位得到了捍衛，學生通常會繼續從事完全不同的工作，並且放棄編程項目。

• 作為科學家，我不得不說，您所指的軟件開發過程不適用於許多科學編程，我這樣做：他們要求您已經對如何解決問題有了一個想法（如果您不知道如何解決問題，如何生產可交付成果[或設計您的體系結構？]。通常，結果甚至是未知的。
  從基礎研究的角度，當您知道其工作原理時，您已經達到了基礎研究的 end 。然後，開始應用開發，然後我看到瞭如何應用軟件開發流程，但是從定義上看，這超出了基礎研究項目的範圍。
  基礎研究部分OTOH可描述為試驗和錯誤的方法來產生可交付成果的第一印象。
  您可能只會看到科學代碼的冰山一角，在此情況下（已經）有理由要努力編寫具有定義的接口等正確記錄的代碼。（其他良好做法例如單元測試，我希望可以在很早的嘗試中就已經看到了……）：可能您看不到為研究創意而產生的大量代碼，這些代碼後來證明效果不佳而被放棄了。 p>

• 我看到的大多數科學編程與傳統軟件項目之間在使用角度上有很大的差異。大多數編程都發生在碩士或博士學位論文中。整個事情的範圍相當有限。通常，這將是一個單人項目，因為根據定義，論文是一個單人項目。因此，對於一個唯一開發人員，該軟件的可能使用範圍最多為幾年或僅此一個項目，並且通常只有該一位開發人員將成為唯一的用戶。這與“常規”軟件開發完全不同。與之形成鮮明對比的基礎研究觀點是，即使該方法應被廣泛使用並且並未證明該想法僅針對所發明的一個問題起作用，接下來發生的事情是有人將改進該算法，可能/通常導致完全不同的實現。或者發現它適合一個更通用的框架，該框架對應於完全不同的接口，等等。在這種情況下，甚至不確定為該方法精心設計一個接口是否會奏效。
  I並不是說這不能或不應該通過可讀的實現來完成。但這不是鼓勵學習學習如何編寫可讀代碼的情況。

• 我做的大部分編程工作是編寫針對特定實驗量身定制的數據分析腳本。實用上，僅當我從一開始就知道我將再次需要它時，或者實際上遇到這種情況時，才將代碼歸納為可重用的程序包。但是，與例如當我作為數據庫應用程序的“普通”開發人員工作時遇到的問題。但是，部分原因可能是因為對於某些我知道代碼將被重用的項目，我從一開始就建立了與現有數據分析並行開發的程序包/庫。但是我對此的看法與學生範圍完全不同，因為我希望多年繼續使用此代碼庫。

• 最令人驚嘆的（完全出乎意料）之一是wrt。我進行的科學編程是：我提交了一篇論文，並同時發布了軟件實現。一位審閱者詢問我如何確保計算正確-這使我可以回答我使用單元測試，並且該軟件包實際上包含的測試代碼大約是計算代碼的兩倍。這是出乎意料的，因為在我的領域中，隨本文件發布代碼已經非常不尋常了-但我之前從未見過任何論文解釋為實現提供哪些自動測試-因此，我並不希望這些信息能使它實現
  我認為這是一個非常有希望的信號！

• 另一個非常有希望的信號是，當我向合作者解釋*版本控制系統的概念時，很多人都喜歡這個想法並將其描述為他們認為應該存在但不應該存在的東西已知實際上存在於Word更改跟踪範圍之外。 （儘管對於研究工作流，我仍然認為我知道的VCS（svn，git）以及純編碼項目都可以使用。）
  幾年後更新：：讓非程序員同事使用版本控制仍然是一個艱鉅的討論（也是因為處理二進製文件的VCS並沒有我期望的那樣快）。我大體上回了一步，現在我們使用nextcloud共享數據，雖然它不提供真正的版本控制，但至少可以使每個人談論數據/文件的相同狀態。

*也不是全部編程的人，他們將測量的數據輸入到系統中，或者例如醫學/生物學解釋。

更新：從我第一次編寫該答案以來獲得的經驗，現在我將組織方面進一步提升：

我大部分時間都離開了學術界，現在正在自由職業，但是仍然有一些研究項目，在這些項目中我擔任（學術）研究機構的分包商。對於某些特定的預處理程序，我不得不提供某些服務，但遭到了我的拒絕，他們拒絕為諸如單元測試之類的“不必要的東西”付款，並將工作代碼封裝在具有自己命名空間的庫/包中。該方法是一個數據分析過程，因此，最重要的錯誤類型是編程邏輯中的錯誤（相對於哪種單元測試可以提供一定級別的防護）。它應在R中使用，即在交互式工作場景中，這意味著如果第三方功能未封裝在其自己的命名空間中，則有很大的混亂用戶工作空間的風險。
這種拒絕來自研究的高層管理人員研究所。

@gerrit評論說，大學的官僚主義可能不允許一群人擁有專業的程序員。我認為這可能是日常的現實。但是，我也認為這與我在這裡談論的這種組織失明有關。如果學術界的高層管理者確實意識到在數據處理和軟件開發中使用最新的工作技術的重要性，那麼大學行政部門也可能對此持有不同的看法。如果贈款提案確實包括專業數據和軟件管理主題，那麼在該級別上情況也會有所改善。我認為這裡的學術界處於一個惡性循環：除了學生之外，每個人都被認為非常昂貴，因此項目建議不敢包括任何“技術”人員。如果提出了數據管理或軟件開發的話題，我們的學術管理人員將不會考慮任何事情，而是“是否可以讓一名CS博士學生”這不適合：項目需要完善的，可靠的工作方法，而不是任何被認為足夠新的東西都可以算作CS研究，從而使學生能夠獲得博士學位。
當然，高層管理人員可能會說服他們的同事或通過這些方面的專業治療有多大幫助的實例，但是只要他們不說服他們，就很難找到錢和許可來嘗試它是否以及有多大幫助。

那裡有一些很好的答案，我想在這個問題上投入我的兩分錢，因為這是我經常考慮或與同事討論的一個非常相關的問題。現有答案的某些部分不可避免地會出現一些重疊，我只希望在這些情況下能給出稍微不同的觀點。

我已經完成了應用數學專業的學習，並完成了碩士課程。生物學&醫學建模（無論這意味著什麼）。我在生物信息學和系統生物學上的博士學位研究已經結束了一半時間。我幾乎專門從事 silico 的工作，並為許多怪異，醜陋和可悲的軟件感到驚訝。

首先，我認為您在提出問題時犯了一個小而重要的錯誤。您說：

“ 為什麼許多才華橫溢的科學家編寫可怕的軟件？”

我反而建議

“ 為什麼由才華橫溢的科學家編寫的軟件最終變得可怕？”

差異很細微，但對於我的其餘回答來說卻至關重要。畢竟，這不像科學家們圍在桌子旁，決定來編寫可怕的軟件。

許多編寫代碼的科學家都沒有受過編寫軟件的教育

那裡知道如何編碼與知道如何編寫軟件之間的嚴重區別。在本科和碩士期間，我在計算機科學係從事的課程幾乎與數學一樣多，因此我對自己的編程技能充滿信心。直到我遇到諸如打包，依賴管理，生命週期，許可等問題為止。在我學習期間，這些都不是遙遙無期的課程。我不知道那些從事CS作為本科生的人是否會學習這些概念，但是我敢肯定，直到我突然不得不了解它們之前，地獄永遠不需要。

許多編寫代碼的科學家的老闆/主管都沒有受過編寫軟件的教育

您不僅需要學習大量新知識，而且想像您無法向老闆解釋為什麼這對您學習這些知識很重要。我經常遇到這個問題，因為編寫代碼的能力通常與在我們部門進行的工作相當。人們認為編寫代碼只是獨立進行的，最好是快速進行。我經常與同事討論，他們開玩笑地提到他們想听我的只是“計算機說是/不是？”。新事物可能要花多長時間常常被低估了，必須連續編寫測試通常被視為浪費時間。這讓我想起了下一個話題。...

學術界對好的軟件沒有重視，至少與行業不一樣。

學術界對能力的衡量是出版物，貨幣形式為引文。您會不斷地以競爭的方式提出新的有用的東西，只有那裡的第一個才有機會獲獎。在學術界，克隆不存在或存活得特別長。相反，在行業中，您可以通過更好的廣告，更涼爽的GUI或更低的價格來贏得市場份額。在學術界，如果已經發布了某種方法，則需要做其他事情。

類似地，如果您已經發布了一種方法，則該原理證明的其他功能，清理，優化等該軟件通常不夠好，不能保證可以發行新出版物，這實際上意味著您白白浪費了數月的工作。悲傷但真實...

期望發生變化，您必須期待意外的情況

可能只是個小問題，但我不能強調得太重，因為它一遍又一遍地咬我。您只是沒有為新項目獲得適當的規範。它們通常過於模糊，或者過於嚴格（實際上是不現實的）。有時，從未提到的某些東西是隱含的期望。然後增加傷害的傷害是，基於新的數據格式，某些其他數據庫，新功能或老闆不在會議上時正在考慮的其他很酷的事情而更改規格...您編寫和重寫解決方案

您通常得不到所需的支持

少數幾個編程博士學位的學生，我們試圖通過保持最新來提高自己與趨勢。例如通過SO學習最佳實踐。但是，當您想嘗試新事物時，常常會遇到阻礙。 IT部門認為您太討厭了，或者老闆認為您很懈怠，或者您正在尋求幫助的人都認為您不了解而浪費了他們。時間。例如，我花了幾個月的時間來回協商和來回郵件，以便能夠在家中訪問我們的版本控制服務器。最終，它可以更快地跳過某些最佳實踐。

對於不是專家的人來說，最新的最酷的CS趨勢並不總是被很好地記錄下來。

我試圖嘗試使用幾種“新”技術來弄髒自己，陡峭的學習曲線。有時確實不值得付出努力。我最好的例子是Maven。當我經常使用Java時，我認為我應該使用現代工具進行打包和依賴管理。但是，在與之抗爭了這麼長時間之後，我的結論是@％& $它！我真的沒有精力或時間去閱讀那些混亂的文檔。

底線

在經歷了這些年來的痛苦之後，我得出以下結論，這給了我一些內心的平靜：

“ 我不是軟件開發人員。也不是寫軟件的付費。寫軟件不是我的工作；學會解決某些問題是是。”

希望這個答案會給您了解為什麼科學家（特別是天才或其他方面）編寫的軟件經常不符合軟件開發人員所建立的標準​​。

只需補充 Marc Claesen 和 cbeleites 的出色答案即可。在學術界，人們編寫代碼時，通常會發生以下問題：

• 問題通常是開放性的-因此，也許人們開始使用的數據結構將在以後用於其他方面，它是次優的。同樣，許多事情設計不當，因為一切都會改變。將其與編寫典型的商業軟件進行比較，該軟件從一開始就指定了東西，並且通常都不是最先進的（即使要求很高，也並非“第一次”）。
• 可維護性不是要求-一小塊軟件，以後不使用，沒有其他人可以接管代碼（與別人的代碼相比，理解自己的代碼更容易-即使混亂，您知道在哪裡）。將其與情況進行比較，在這種情況下，作者離開後，其他人將負責代碼（或者需要不斷考慮僱用更多開發人員以加快進度）。
• 人們單獨工作或使用舊版代碼-情況截然相反，但給出的結果相似。在第一種情況下（如上所述），人們可以理解他們的混沌代碼。在第二個方面（例如，修改舊的Fortran代碼中的部分），人們必須採用對現有代碼庫進行小的（通常是並非意外的）更改。

個人（來自純粹的學術背景），當我與他人合作時，我已經學到了大多數良好的編碼習慣：

• 通過向他人學習-一些編碼實踐不需要太多的能力，但是有很多經驗-智慧告訴我們，給定的“智能解決方案”在長期運行中將變得難以維護（因為大多數 kludges（=醜陋的駭客）），
• 通過合作-我多次意識到，對我來說很清楚的是，對他人而言， cthulhu fhtagn （卻很強大）是完全無法理解的（反之亦然）好-對其他人來說，好的代碼對我來說是一個具有挑戰性的謎語），
• 總而言之，實際上許多好的做法都將成為技能的最小公分母不聰明的人已經關閉了它）；

還有一個甜點-天才的詛咒，對最後一個評論要點：

您是一個出色的實現者，比我更有能力，並且可能（考慮到這一點，我是認真考慮的）是自Ken Thompson以來的Unix傳統中最好的實現者。結果，您遭受了天才程序員的詛咒-您過於依賴自己的能力，以至於您從未學會過珍惜某些類型的編碼自律和設計工藝，而這些人卻是必須開發以解決您早餐吃的那種問題的複雜性。

（來源： http://lwn.net/2000/0824/a/esr-sharing。 php3；或縮寫為： http://www.linuxtoday.com/infrastructure/2000082800620OPCYKN）

Eric S. Raymond到 Linus Torvalds...

並附帶說明（隨著編程越來越普遍），現在科學家們意識到良好的實踐和工作流程很重要，請參見例如 http://software-carpentry.org/。

即使是專業的軟件開發人員，當需求每週以不可預測的方式變化時，您是否可以開發出可以稱為優質軟件的軟件？這是研究人員賴以生存的世界。

進行科學研究意味著要進入未開發的領域。研究人員不知道明天早上怪物可能需要哪些功能。這取決於他們今天午夜獲得的結果。一個科學程序累積了太多的迭代，增加了一些功能，儘管這些功能根本不需要。

任何試圖為新功能留出空間，增加模塊化的嘗試，甚至當這些“通用方法”必須稍後被黑客破解以使進一步的改動遠超出預期（並得到支持）時，甚至會使情況變得更糟。因此，在研究過程中直接演化的程序通常只能用作原型，並且必須在發佈為商業軟件或FOSS軟件之前進行重寫。專業的程序員，如果被聘用，可能會做得更好，但需求的不穩定很可能阻止“到達”真正出色的最終設計。

為什麼羅爾德·阿蒙森（Roald Amundsen）不為通往南極的高速公路鋪路？

為什麼埃德蒙·希拉里（Edmund Hillary）沒在登上珠穆朗瑪峰的路上建造滑雪纜車？

的學者是尋找解決以前認為不可能的問題的方法，並教其他人（儘管他們的資助計劃很簡單，但此目標受眾是其他研究人員）如何解決問題，並做到上述幾點盡可能有效。

學術界僅在代碼“足夠好”地工作以證明其思想觀念的情況下，才關心代碼的質量，並且有可能在以後的項目中重用該代碼。重構代碼，編寫文檔，仔細地進行錯誤檢查，建立自動構建等，這是浪費時間，除非花費時間來改進軟件，至少可以節省它們產生工作結果的時間。對於我列出的四個項目，幾乎從來都不是這樣。

可以肯定的是，當他們的研究變得非常重要時，許多研究人員將回過頭來為他們編寫精心設計的實現較早的算法（通常是與專業軟件開發人員簽訂的諮詢協議的一部分），並且他們有受過培訓的人才和才能較早地這樣做-這是不值得的。

在許多方面，編寫軟件是一門藝術。許多偉大的畫家還不是天生的，他們實際上是在多年的培訓中學習了這門藝術，並且在這兩者之間有很多不好的結果。

拿一張紙來嘗試畫任何您認識的人。即使您面前有照片，也很可能看起來很可笑。現在，一位真正的藝術家會問您，即使您面前有清晰的畫面，為什麼也看不到陰影，無法提供正確的視角或將耳朵置於完全錯誤的位置。但是，不是您的傲慢引起了，而是您缺乏以正確的方式查看模型的經驗。從技術上講，它與您使用錯誤的大腦一半有關，您可以接受訓練來改變它。只是直到明天。

科學家是基於理論的工作。他們有一個理論，他們想證明這一點，他們只著眼於實際的理論編寫代碼。那是您看到的鼻子，但看不到它周圍的陰影。如果您要教他們幾個月甚至幾年的時間，以使用正確的方法和“筆觸”以正確的方式進行操作，它們可能會發生變化。但是，您應該問自己是否值得。有時候是這樣，但是有時候科學家應該堅持科學的東西，就像畫家不應該突然開始放射性化學一樣。

如果您決定教他們，請保持藝術家的想法。剛開始的第一天：這不是他們的傲慢，而是他們缺乏如何使用大腦的正確部位的知識。 “軟件開發”為三年的學徒是有原因的，之後您將被視為“初學者”。

精彩的討論，我也曾想過很多次。還有另一種軟件，上面沒有真正提到過-在學術界開發的程序，它不是研究項目的一部分。有許多軟件開發項目更側重於物流，教學等（點擊器，視頻捕獲，內部網，圖書館軟件等）。有時，這些是由專業人士處理並成為協作項目等，但很多情況下，這是由於有人擁有一些研究生助理，他們對編程有所了解，他們編寫了可能有用的東西，但是當然沒有文檔，測試，版本控制，需求文檔等-當他們畢業並繼續前進時，對於任何想維護它的人來說都是好運...這也是學術界的“虛假經濟”，其中某些種類的勞動力非常廉價/是免費的（對於從中受益的人）。

作為計算機支持學習的博士生，我個人也可能負責一些糟糕的軟件。希望我比其他人對最佳實踐，版本控制等有更多的了解，但是我從未接受過任何專業培訓，更重要的是，我從來沒有參加過實踐社區，在更好的研究人員的指導下在教育中，這在某種程度上更加困難，因為在技術上傾向於學生/教授的人很少。我當然可以廣泛使用SO，郵件列表等，但是如果在走廊上有一位高級同事來審查我的代碼並提供反饋等，我可以肯定我的代碼可以得到很大的改進。

實際上，上面的評論之一讓我想到了這一點-大學擁有某種程度上可供研究人員使用的統計顧問是很常見的。 （我們圖書館有一個可以免費使用一兩個小時的人，然後我們需要付費，但是我知道很多人都在利用它，並且發現與他們坐下來非常有用。進行研究設計，假設，統計設計等）。擁有一個“軟件開發顧問”（不確定標題）將是一個有趣的概念，他基本上將是一名專業的代碼審閱者...但也可以擴展以幫助人們思考他們的需求，找出有用的框架或庫，導航版本控制，開源許可證等。

當然，將激勵系統更改為獎勵發布（或改進！）高質量代碼的獎勵，非常重要，但非常困難。在這方面，我認為Mozilla的學術代碼審查練習是一個非常有趣的實驗。

返回編寫Python腳本來解析MOOC clicklogs：）

因為編程就像騎車：每個人都需要它，但我們大多數人都不是專業人員。如何學習編程？通常購買/借書“ Python或其他任何初學者”。這將與如何保存文件，如何運行程序以及如何調用函數有關。在此之後，我現在或昨天都可以做最緊急的事情。

在哪裡我將學習設計模式，良好的軟件開發實踐，敏捷開發以及如何編寫漂亮的代碼？就像在上完汽車課程之後一樣，我相信我還可以，而且我每天都不會讀5個小時有關如何在潮濕的道路上更快行駛的信息，所以我不會去書店閱讀每本CS書籍，這可能與我有關。即使我上網，也許Software Carpentry是唯一相關的資源！嚴重的是，如果有人知道類似的內容，請在此處發布！

我不會在MIT課件中學習完整的CS來湊齊我今天的“ Hello word”。而且，即使是麻省理工學院的CS專家也能在學校以外，在工作中，而不是在上學4至5年後學習一半的良好編程實踐，我也不會感到驚訝。

摘要：複製或缺少複製。

詳細信息：

我的觀察（不幸的是，n小且單個POV）是主要原因無論是非才華橫溢的科學家，編寫可怕的軟件都只是“複製的反面”。他們認為可重複的研究沒有價值，他們不希望自己的作品能夠被複製，而且他們當然不希望自己的作品能夠被複製。 （他們只是希望自己的工作被引用：-）

我是BSCS，曾在“行業”工作過，其中包括一個知名的不露臉的縮寫。我所知道的所有編碼器至少都使用和看重開源軟件，並且有很多貢獻者（特別是我上次的直截了當的代碼演出）。 OSS僅在使用和擴展的範圍內進行評估。 （AFAICS –我是否缺少某些東西？已經研究但未使用過的外來語言？）當然，僅當給定的OSS健壯，經過測試/可測試，有據可查時才使用（僅在公開使用時才進行擴展）。

現在，我以環境建模師的身份回到學校（主要是大氣）。與我一起工作的人們甚至根本沒有將他們的代碼放在公共存儲庫中（甚至比我還年輕的人-這不是AFAICS的世代問題），更不用說創建文檔，模塊化，註釋（是否在代碼或提交中），以及OSS中期望的其他功能。這似乎是由於（僅基於對話，而不是強大的經驗數據）基於他們的假設（並且通常是希望），即他們的代碼將不僅不會被其他任何人使用（而且實際上可能永遠也不會被編碼器再次使用） ），但甚至都沒見過。

不幸的是，當我“被錄用”為研究生時，我對此並不理解。 （我對研究生學術界幾乎一無所知-我只是用一個不露面的縮寫“跳出一扇窗”，只知道我想從事的工作-而且對於信息學之間的文化差異一無所知（“計算機科學”我以我的工作領域最感興趣的教授為顧問。一旦我開始查看他的代碼，我的嘔吐就是彈射的。我試圖讓他參與進來，而他的態度大約（即不是引述）是“論文很重要，代碼無關。”他從不提交論文代碼或公開代碼，並且幾乎只使用了相當晦澀，{專有，昂貴} {語言，開發環境}（為公平起見，他的許多同事都做過，其中有些人是非常大的名字在我們的小領域）。我有一定的科學哲學背景，並且知道我們所使用的模型具有真正的公共政策含義（例如，大量支出），所以我問一個人如何重現他的結果。他說（這是引用）“他們相信我們-我們是科學家。”他不再是我的顧問...

雖然我懷疑（再次在小n上）上述觀察結果“可以衡量中心趨勢”，但並不是黑暗和虛無:-)在我自己的領域，有像 GEOS-Chem這樣的示例軟件。不幸的是，由於 GEOS-Chem支持團隊的緣故，GEOS-Chem在很大程度上是“真正的東西”（IMHO），該團隊提供了一種在我領域中極為罕見的基礎設施。因此，我懷疑GEOS-Chem是在覆蓋率高的領域（我是否遺漏了某些東西）上衡量軟件質量，可能比平均值好2-4σ。

這個問題的簡短答案是研究科學家（大多）不是軟件程序員（儘管他們確實會不時發佈軟件）。

我在計算領域很繁重，這意味著我過去處理過的許多雜項都可以打包到軟件中。根據我自己的經驗，有一些障礙使我無法根據自己的工作來編寫功能完善的軟件：

1. 我的很多研究涉及開放式調查，因此代碼也是為此目的而編寫的。編寫軟件意味著我對到目前為止所研究的一切都有基本的了解，但事實並非如此（在可預見的將來也不會如此）。

2. 我所做的每件事都太小了，無法作為軟件編寫。擴大事物的範圍需要研究，而不是軟件。

3. 很多研究超出了我的控制範圍。總是會有新的研究機會和方向，這意味著一些研究（以及與之一起編寫的代碼）將被中止，這可以回溯到上面提出的觀點。

4. 大多數時候，我在Windows OS上編寫MATLAB代碼。即使我不切換操作系統（例如Linux），我的選擇還是將MATLAB代碼轉換為某種.NET語言或將其導出為C / C ++對象。我可能是錯的，但是我認為使用兩種語言的軟件開發既困難又耗時。

5. 大多數研究工程師使用MATLAB編寫代碼的原因是研究的周轉時間差異很大。在大多數情況下，每週需要做的事情可能涉及非常新穎的實驗。繁忙時，周轉時間可能在一天之內。這些實驗是使用非常穩定的平台（例如MATLAB或Mathematica ）來最佳完成的，而對於其他一些語言，如果您不小心在某個位置插入了製表符或缺少冒號，則代碼將無法編譯。再次強調，即使您正在編寫代碼，這也會加深我在以上要點中提到的內容，並進一步降低適當的軟件開發技能。

6. 有評論者提到軟件開發在機器學習方面做得很好。在我看來，其原因是因為在諸如優化，機器學習，信號處理等領域中，A。事物是可視化的，B。自1950年代以來就已經研究了事物，C。許多人都試圖進入從這個角度來說，D。很多事情實際上是很容易的，從計算上來說，而且很多時候不精確的解決方案（在非常特殊的情況下適用）就足夠了。不幸的是，我們大多數人都不在這樣方便的領域工作。

7. 坦白說，我們所有人的生活都超出了研究。軟件開發可能需要比研究項目的整個過程更長的個人投入或協作。

ol>

我不認為我是一名才華橫溢的研究人員，但是我已經在軟件中進行了研究，並且實際上產生了一款軟件。對於那篇文章，我還與一家大型科技公司的一群人進行了合作。顯然，我們的軟件方法之間有很多不同。

• 當我編寫軟件時，我選擇了最簡單的方法來證明我的想法是正確的。我沒有花很多時間來設計軟件，因為我沒有時間！我盡力使它工作，並儘力使其可讀性和可破解性（因為我知道最終將由其他人接管），但是我並沒有花很多時間來設計它。我主要是想讓它起作用，以便可以對其進行處理（並表明我的想法是正確的！）。

• 這實際上是很好的部分。在我的研究中，我們使用了另一個國家的另一個研究小組創建的研究軟件庫。他們實際上並不知道人們正在使用他們的軟件！結果，他們檢查了導致軟件無法構建的更改。而且，代碼很難閱讀，我們不能自己修復（它是C ++，所以錯誤消息也沒有幫助）。我們必須親自與他們聯繫以解決此問題。

• 那麼，學者們可以編寫出色的軟件嗎？是的，至少有很多可以（或者他們不能教授編程課程）。實際上，我的一位教授是一位出色的編程講師，但他的個人編寫的代碼閱讀起來並不愉快。學術人員根本沒有時間四處亂竄，使他們的代碼看起來不錯。如果他們有更多時間改進軟件，我相信他們會的。

• OTOH，這家技術公司的人們實際上對生產他們可以使用的軟件很感興趣（因此，也許可以生產一些研究論文）。他們遵循自己的編碼標準。他們對其進行了深層次的設計。他們使用了構建管理，集成測試和覆蓋測試。他們之所以這樣做，是因為（1）他們有時間和金錢，並且有報酬去做，而且（2）他們將實際使用它！

造就一個好的科學家的素質並不總是造就一個好的軟件程序員（正如OP所指出的，當“科學”恰好是計算機科學時除外。

計算機編碼是包括優秀科學家在內的許多人都不夠精確，無法輕鬆編寫好的代碼。對於更“直觀”類型的科學家而言尤其如此。

許多科學家發現計算機編程“很無聊” “並且出於這個原因，請不要做得好。確實，“常規”科學需要詳細的工作，但不需要達到編程的程度，許多人（包括您的人在內）確實發現“頭腦麻木”。

基本上，如果一個好的科學家和一個好的程序員之間的相關性為零（或非常弱），那麼您將獲得一大批科學家的全部編程能力，包括優秀，中等和可怕。

有三個主要原因。

一個原因是科學家不是專業的軟件開發人員。即使對於計算機科學家而言，也是如此，對於數學家，物理學家，化學家，生物學家，社會科學家等而言更是如此。不是說他們做不到，大多數相當聰明的人如果願意的話可以成為專業軟件開發人員，但大多數人不是。

二是科學家對創建“可怕的軟件”相反的東西不感興趣。他們通常只對結果感興趣。這是不好的地方，如果他們的軟件中包含的錯誤產生了錯誤的結果，但與事實相去甚遠，似乎是合理的。幸運的是，許多錯誤將產生明顯錯誤的結果。如果該軟件過於混亂，以至於沒人能確定它是否正確，那也很糟糕，但是據我所知，對此並沒有太多抱怨。

第三點是科學家經常處於時間壓力之下。他們可能會快速編寫自己知道應該改進的軟件，甚至可能知道如何改進軟件，但是他們沒有時間。

我真正希望沒有的一件事不是某些人認為他們所理解的必須是簡單的，而他們所不理解的必須是困難的。有了這些假設，任何撰寫任何人都無法理解的軟件的科學家將被認為是一個天才，而任何撰寫易於理解的軟件的人都不會給人留下深刻的印象。因此，從這些人的角度來看，專業的軟件開發人員所做的使軟件易於理解的工作將損害您的職業生涯。我真的希望這不會發生，但是我不會感到驚訝。