我認為理解工業軟件工程師研究代碼的關鍵是要接受您通常不生產產品。您沒有這樣的客戶。您正在構建軟件來證明這一點。

因此，您作為研究人員編寫的大多數代碼都與您（行業）通常在程序設計中編寫的一次性原型和模型相似。項目的早期階段。如您所知，即使在行業中，這些模型也具有與最終軟件完全不同的屬性。他們主要需要：

• 完全具有要向客戶展示的功能。不多不少。通常，會忽略該域所有無聊的標準功能。
• 需要迅速完成。您和客戶都知道原型還是會被扔掉，因此代碼是否可維護無關緊要。
• 需要易於擴展和適應，並在演示過程中保持最佳狀態。
li>

基本上相同的屬性對於大多數一次性研究代碼也很有用。您不想不想構建不需要的功能。您不想不想浪費時間編寫例如可維護的代碼，如果您知道它不會得到維護。您想要使用一種減少樣板代碼和設置數量的環境，並且該環境可能會自動為您生成大量對演示者來說足夠好的代碼（Ruby on Rails及其腳手架的功能浮現在腦海）。

我的職業發展取決於我寫“不好的”代碼！

不，這取決於您編寫適合目的的代碼。就像工業界一樣。在行業和學術界，沒有人為不需要的軟件質量而鼓掌。嘗試重新考慮您所編寫的代碼的要點。如果您打算將代碼作為開放源代碼軟件發布，並且希望被世界各地的其他人所採用，那麼請發瘋-使用您在行業中也使用過的所有工程技術來構建最佳產品。如果您的目標是評估會議的一種算法或原理，然後扔掉代碼，那麼您也可以快樂地生活，而無需編寫單個單元測試，而完全不會感到欺詐。

編輯：當然，這並不意味著可以在不確定自己是否正確實施了上述算法的情況下編寫代碼。確保您確實聲明自己聲稱的內容是強制性，尤其是在研究代碼中。

我是一名研究人員和自學成才的開發人員。我已經完成了大量的項目，這些項目主要是基於軟件的。儘管就複雜性和規模而言，我的工作遠不是最“硬核”的東西，但是這些項目足夠大，以至於天真的錯誤（例如，不使用版本控製或文檔編寫得不好）是非常痛苦的。我最終通過反複試驗學習了很多“最佳實踐”。

我也一直在接受“傳遞給研究人員的不可維護的代碼”：

我的行業經驗一直是我研究的障礙

不，您基本上來自一個文明的環境，幾十年來解決了這些問題，就軟件開發衛生而言，這是一個陷入僵局的時代。科學家仍然像60年代那樣編碼。當然，您會感到衝突，但是故障不會出在您身上。

在行業中，代碼（理想情況下）需要：可維護，無錯誤，重構，文檔完善，經過嚴格測試

讓我們說一個科學會議上的演講者，在描述他的研究的計算部分時，說了以下話之一：

“ 我寫的代碼“

• ...不可維持（並且在我的研究中加油！）
• ...充滿了錯誤（而且我不知道輸出是否正確！）
• ...無法理解的意大利麵條（我什至不知道它是如何工作的，更不用說它是否正確！）
• ...未記錄（所有錯誤都被審稿人掩蓋了！）
• ...未測試（所以上帝知道它是否按照我的想法做/想做！）
li>

您是否希望觀眾對自己表現出蔑視和憤怒？如果我聽到這樣的話，我將不相信這個人再發表任何文章。

在學術界，目標是在盡可能短的時間內完成（...）。

是，但是“ 不短”。您不會跳過重要的控制實驗，因為“控制需要時間”。出於非常相似的原因，您不能無視代碼質量。

似乎沒有動力編寫[優質代碼]

，因為這是一個學術界的地方性問題。儘管計算機已在科學中使用了數十年，但似乎在最近十年左右的時間裡，算法僅成為研究的重要組成部分（也許是因為“大數據”）。當您基於代碼進行研究時，該代碼必須具有良好的質量。僅僅簡單地找出一些有問題的只寫腳本並將其命名為一天是不夠的。軟件開發社區很早就已經弄清了這一切，但學術界尚未流行-我認為原因是大多數科學家沒有軟件開發的正式背景，並且在研究中沒有引起足夠多的大醜聞通過不良的編程習慣（例如，引人注目的論文的主要結果是由錯誤引起的工件）。

請考慮一下，在許多學科中，審閱者甚至不會問您的源代碼計算量大的論文。他們如何評估結果的有效性？他們不能，這是當前同行評審模型的失敗。

很抱歉，我的回答是這樣，但是基本上，這是這樣的：正如您所知道的，編寫的理由很充分即使沒有人在你的肩膀上看著，也能獲得高質量的代碼。在科學中，目前確實發生這種情況，沒人在乎您的代碼是否好。但這不應該成為您仍然不編寫良好代碼的原因-在行業中編寫良好代碼的原因仍然在很大程度上適用於科學。

很遺憾，您的額外工作可能不會得到回報。您甚至可能會受到懲罰，因為正如您所說，好的代碼需要更長的時間，而其他人可能看不到更多。您的PI或同事可能不明白為什麼您要慢得多。您能做的最好的就是向他們解釋對良好實踐的需求。

顯然，有一些例外。例如，對於要在專用實驗室計算機上運行的代碼，您可能不必擔心可移植性或與舊版本OS的向後兼容性（儘管不希望編寫代碼以使其僅在非常特殊的環境中運行）其他科學家無法輕易重建的環境）。但總的來說，我發現行業慣例仍然適用，並且可以通過應用少量批判性思想輕鬆地檢測到例外情況。也就是說，還有一個有用的出版物“ 科學計算最佳實踐 ”，它詳細研究了此問題。

最終，這是一本您必須做出的道德決定。您是否在乎做好科學？遵循最佳做法。您是否想偷工減料（從道德角度而言），以節省時間或避免與同事發生摩擦？原則上，我不建議您這樣做。但是顯然，很多人都這樣做了，也許實際上，有些科學家被迫這樣做-儘管再一次，難道不是因為情況不好而做不好的科學嗎？

也像我說的那樣，我認為問題的部分原因是沒有任何大的醜聞。如果您對代碼質量有所了解，那麼它就有可能趕上您。您甚至可能成為那些大醜聞之一。誠然，風險可能很小...但是，我認為您可以理解我的觀點。

我要么花了太長時間（不必要地）使我的“研究”代碼達到了行業質量

不要。在建議的時間範圍內使其盡可能好。追求100％的完美而又需要兩倍的時間是不值得的。從這個意義上講，研究就像行業。

因此，我編寫的“學術”代碼質量很差

學術代碼質量低下。如果您查看算法會議或併行處理系統上的論文，您會發現開發人員甚至想到了令人費解的細節，例如對數據進行重新排序以減少高速緩存未命中次數，SIMD，GPU編程，SSD存儲等。通常，高級CS算法研究已有數年之久。在採用新方法之前，先要採用硬件技術，然後再採用任何實際技術。另一方面，在理論上更強的CS會議中，代碼主要是一種工具，因此，它不一定是最先進的。因此，質量與產品代碼的受眾（就像行業）有關。

有人知道“研究”代碼的正式方法嗎？

因此，堅持使用那些行業方法，這些已知技術可以從長遠來看為您節省時間，並且可以在不花所有時間的情況下改善軟件。找到中間立場永遠是最好的解決方案。

tl; dr 行業的某些“最佳實踐”非常合適，而其他部分在研究環境中效率低下。保持在 this 環境中運行良好的結果。

我是一名實驗粒子物理學家，我們編寫了很多代碼，其中許多是許多人編寫的大型項目，分散的程序員。

我們熱情使用的常用行業工具包的某些部分

• 版本控制
• 錯誤跟踪
• 自動化的構建和測試系統

其他部分要么較慢，要么不那麼受重視，其中包括

• 一個正式流程（帶有一個大寫字母“ P”），並定期召開計劃會議並發布檢查清單等。隨著項目變大（通常是由於對質量控制的全面破壞或長時間的發布滯後），這些項目就會出現。也就是說，當我們需要它們時，我們會使用它們。被迫解碼某些位通常會貢獻更多文檔。

• 單元測試稀疏且通常集中在系統的較低層，但是回歸測試更為常見。 / p>

• 大多數項目都具有編碼標準，但是它們通常是鬆散指定的，執行起來較弱。

其他簡單的東西則沒有

• 當您不知道研究生將在下週中解決什麼聰明的主意時，就很難進行功能計劃您甚至還沒有註意到。

• 過去，確實存在嚴格的檢入控制阻礙了分佈實驗代碼段的方式，而我們只是偶爾凍結了新的開發檢入，以得到有福的發行版（這種情況呈現HEAD / trunk /“任何使用風險自負”的主張）。隨著分佈式版本控制的興起，人們開始對官方乾線的檢入控制有更強的承諾。

• 重構通常只會發生當兩個人都開始使用某些舊代碼時，他們都覺得他們需要更改或擴展。沒破損的東西留得足夠好。

從您的問題中我懷疑您是單手編寫還是小組編寫代碼。在該設置中，細節會發生變化，但基調保持不變。只需保持您的行業實踐中有效的部分，並放棄或延遲那些在時間/結果方面成本/收益比最差的部分。

放棄繁重的重構，直到您從證據中知道，您的代碼的特定部分將被重用。同樣，除非代碼顯示持續有效，否則對粗糙的文檔要滿意。依此類推。

研究代碼的主要特徵（比典型程序要多）是難以計劃的。根據定義，研究進入未知領域，這也轉化為程序結構。作為研究人員，當您的研究朝著不同的方向發展時通常沒有時間重構，應該轉變為不同的軟件結構。

在典型的軟件工程中，您（應該）有一個相當不錯的主意編寫一行代碼之前的最終功能。在研究中，通常並非如此。用於研究目的的編程主要是關於快速原型製作，通​​常與長期使用編程不同（例如，很少或沒有單元測試，使用不同的語言...）。主要的口頭禪是快速獲得結果，而不是從軟件工程的角度來看不是最佳的。

最後，適當的軟件工程是很難掌握的一門藝術。即使在行業環境中，醜陋的軟件也很豐富（由專業人員編寫！）。一般的研究人員都沒有接受過軟件編寫方面的正式培訓。

我的職業發展取決於我編寫“不良”代碼！？

作為研究人員，您沒有支付開發軟件的報酬（不幸的是）。作為理想主義者，我喜歡相信這會隨著時間的推移而改變，但是目前，資金來源只關心論文。

軟件開發的“手藝”是一個巨大的課題，但是軟件開發的方向在哪裡？學術研究的最佳實踐？沒人為會議論文代碼編寫單元測試！

單元測試有兩個主要目的：（i）斷言代碼正確運行，並且（ii）快速發現和調試問題，尤其是在結構更改和重構之後（大型基礎架構的長期利益）。由於研究軟件通常很小，因此第一個優勢就是唯一真正相關的軟件。似乎這種優勢太小或被低估了（再次，記得大多數研究人員不是軟件工程師）。

情況？有人知道“研究”代碼的正式方法嗎？

如果您想改變世界，那就從自己做起。我個人認為在合理的時候會提供軟件以及手稿。我也一直要求提供代碼作為審閱者，儘管這似乎並不常見。

我認為您的問題在於將 質量 視為二進製文件。

無論是工業界還是學術界，我們都需要針對特定的質量目標做出選擇。 “工業”軟件可能對安全至關重要，並且要求達到最高的質量水平，或者它可能是內部使用的開發工具。

質量目標可能是：

• 正常運行時間
  
  • 可能對您而言無關緊要
• 穩健性
  • 您是否需要使用許多不同的數據集，還是一個數據集？
• 可重用性
  • 處理程序是否會合併到您要處理的下一個問題中？
• 能夠驗證
  • 是否能夠按照預期的方式工作？至？
• 能夠驗證
  • 的能力是否會產生正確的答案？ [希望這很重要。 ]
  • 檢查答案正確性的另一種方法可能意味著到達那裡的邏輯是否不重要。
• 需要保持可維護性由
  • 自我
  • 其他專家
  • 一些隨機的本科生
  • 或者肯定是被扔掉了。
• 適合公開供他人使用，以檢查或重複使用您的作品
• 等等。

闡明了質量目標，發展目標並且構建系統應該足以滿足這些目標，而且僅此而已。請注意，這可能因項目而異。

我不想談論與行業軟件開發之間的差異（我沒有經驗），而是想談論您在學術界應該做的事情。我將假設您的代碼不是出於其自身的原因而存在，而是附加到諸如“大腸桿菌與人類共享foo-基因組”或“算法A在方案Z中的性能優於算法B”之類的科學聲明上。

• 盡力而為

  儘管您的目標無法有效地使用並附帶收益，但是您應該對代碼有合理的把握您主張的內容，並且有興趣的各方可以理解（同行評審！）。即，編寫清晰的代碼，註釋和文檔。和（單元測試）。

  如果沒有其他問題，請記住，您可能需要稍後再訪問自己的代碼。您構建了一個原型，但是您的下一個原型可能會重用其中的一部分。或者，您希望學生對此進行擴展。

• 可訪問性

  為了支持對您的工作進行科學評估（可證偽性，重現性）其他研究人員必須必須能夠編譯和執行程序。

  因此，您應該提供源代碼，構建文件/指令以及您使用的任何輸入數據工作。請記住，某人可能要在初次發布後多年就構建您的程序，因此請確保源仍在那時，並且構建過程/指令相對於時間（提及庫的版本）具有相當強的魯棒性。 UI並不是太重要，但是“盡力而為”在這裡也適用。

  考慮將代碼放在Github或類似平台上（例如，您自己的 ）。這樣，您可以發布更新並輕鬆收集錯誤。另請參見此處和此處。

• 許可

  您應該對他人（特別是研究員）對您的代碼可能有或沒有做的事情說某事。您可以使用任何許可證（我認為它至少應允許GPL的自由）。 CRAPL可能值得一看。

• 公平評估

  如果您的算法/代碼是您建議的工件（作為高級工件），您必須將其與現有解決方案進行比較。確保使用可比的輸入，重新運行替代實驗，並遵循基本的實驗最佳實踐（例如，查看McGeoch的工作）。確保您的比較包括您所在領域的公認標準（如有）；如果您的方法得出不同的結果，則必須解釋原因（沒問題/正確/更好）。

可訪問性可能是最關鍵的項目。研究代碼需要共享。我認為這不能過分強調，這是所有計算科學中的主要問題之一。除了說物理以外，我們還必須有機會輕鬆地共享和復制（大多數）實驗設置-我們必須利用它。

我個人不知道為什麼有任何一篇文章能找到其對審稿人（及其他各方）無法複製的計算的主張具有任何出版權利。

所有理論類型的一個提醒：

請注意上面代碼中的錯誤；我只是證明它是正確的，沒有嘗試過。
_{Donald E. Knuth sub>}

如果我可以添加上述更準確答案的簡短版本，我會說：

• 學術界->原型。
• 行業->產品。 > li>

不得將產品和原型視為具有相同標準。

原型的文檔可能較短，可能需要花一些精力進行部署。它們也可以在具有特定要求的單個操作系統上使用，例如最初開發代碼的操作系統。

儘管如此，應該測試高質量的原型，進行版本控制，並擁有穩定的分支，並且必須沒有過時的文檔。否則，它們只是質量低劣的原型。 blockquote>

離開學術界的經歷提醒我，除了紙質工作方法之外，還有其他方法需要對博士生進行培訓（並且其成果的讀者人數通常少於合著作者的人數）。

儘管在我的經驗中，在私營部門中進行了具有科學標準的研究，但並非在每種學術環境中都是如此。

此外，這不僅是與編碼有關的問題！ / p>

一些在濕實驗室工作的研究人員告訴我，他們有完全相同的問題。進行濕實驗室實驗以記錄整個過程，將工具校準到最高標準，評估第三方購買的材料的化學成分，隨著時間的推移是一致的，從而使每個步驟都可以由另一位研究人員完全重現...這些基本做法導致了學術論文生產太慢。

我回答了我的澄清要求“為什麼他們將浮點類型用作散列鍵”，這是我直接針對的。現在對我來說，這似乎不是一個好主意。經過一番來回的詢問後，提問者將我帶到這裡作為他們這樣做的理由。

這很有趣，問題本身也很有趣。

您是否說服編寫了錯誤的代碼以實現某些學術目標？是的，即使在CS課程中，我也可能會添加。至少在可理解性方面不好。但是，由於我們太恐怖了，所以我們被“說服”在商業環境中編寫同樣糟糕的代碼，或者說服我們的主人和主人為他們編寫了糟糕的代碼...。

撇開算法的瑣碎實現。例如，您應該在氣泡排序算法中使用i和j作為循環變量，還是應該完全使用氣泡排序。我對您的問題的答復是另一種。好的軟件工程原理如何幫助您實現目標？

好的命名，SOLID原理，連貫性和耦合性等可以使您更有效地實現目標嗎？我的回答幾乎可以肯定。它們旨在在任何不平凡的軟件中做到這一點。這就是它們的用途，它們是為了獲得可以以更低的成本進行更改的軟件而創建的。您不是（或至少不能預見到）第二個版本也沒關係，實現不會從您的腦中浮現出來，因此它會發生變化。

如果您不是'確保您需要編寫什麼代碼，然後如果您有現成的單元測試環境，則類似TDD的方法也將有所幫助。即使沒有那種“奢侈”的東西，編寫可測試的代碼也要去做。

與沒有軟件工程背景的同事相比，您擁有巨大的優勢，您應該能夠更快地擺脫煩人的二進制工作，以更少的努力實現目標然後可以在實際目標上投入更多的精力。

我曾經與一位學術合格的類型進行過討論，他告訴我重構只是搞亂軟件的美感，我應該首先正確地編寫軟件。不用說我對這個人的尊敬下降了一個或兩個等級，這對他來說是不幸的，因為他一開始沒有那麼賺錢。

總而言之，我想說的明智的選擇是在所有努力中都使用良好的軟件工程實踐。只是要清楚，儘管編寫不需要的良好代碼並不是一種好的軟件工程實踐。

用一句話來解釋甘道夫：“保持簡單，保持安全”

至於您是否應該使用浮點數作為散列的鍵來節省時間。如果在選擇設計折衷方案時毫無疑問地知道這樣做的問題不會給您帶來麻煩，那麼也許吧。但是，規避折衷方案所需的工作量是微不足道的，您只是花時間問如何使用浮點數作為鍵來解決問題。我放心了

在任何商業或學術環境中，選擇較低的質量既是收益又是成本，請同時檢查...。

我對問題的前提有疑問。

在學術界，目標是在盡可能短的時間內撰寫盡可能多的高質量研究論文。

似乎沒有動力去編寫經過測試的，可維護的，有文檔證明的代碼-我只需要運行它並在我的論文中或任何正在盡快處理的結果中獲取結果

顯然也這麼認為的人編寫的代碼庫。在此之前，我習慣了一種不同的學術編碼標準，即多年來簡單，優雅，現代，經過測試和維護良好的編碼。

我相信會有一個在這個信息時代所產生的影響並不一定是那些擁有最科學信譽的人，而是那些實際上可以從他們的美好科學思想中有所作為的人。完全不依賴於您編寫的代碼（例如，僅是一些無聊的數據過濾），那麼您實際上就不必擔心它的質量。