編寫可維護代碼

Question

編寫可維護代碼（獨立於語言）最重要的唯一因素是什麼？

Answer 1

好評。

Answer 2

文檔。

Answer 3

良好的抽象關注的

Answer 4

分離（每種方法做一件事情） - 這將停止意大利麪條代碼。

編輯:(迴應Ash的評論） 可維護性的關鍵是能夠快速找出代碼正在做什麼以及如何進行更改以完成任務。

將代碼分離出來，以便每個任務都通過專用的方法進行處理，這使得它變得非常簡單。例如，如果我想改變肘部彎曲機器人軟件的方式，使用一種名爲BendElbow的方法使得它可以在需要進行更改的情況下輕鬆完成。

Answer 5

好方法名

Answer 6

持續重構

Answer 7

自動化單元測試。

如果您已經用自動化測試覆蓋了代碼，並告訴您何時破壞現有功能，則可以通過重構來緩慢更改代碼的設計。自動化測試使代碼更改風險降低。

Answer 8

良好的前期設計。沒有什麼能夠挽救糟糕的設計。

Answer 9

良好的評論可以使甚至最糟糕的麪條代碼10x更容易維護。

Answer 10

不要做any of this stuff!感謝Roedy Green的笑聲。

Answer 11

單元測試手。如果你單元測試你的代碼，那麼你將擁有一個測試套件，當你做出改變時，你可以運行它來驗證代碼的有效性。另外，當你使用單元測試編寫代碼時，由於方法更容易測試，所以方法往往更小。同樣，它應該鼓勵你將你的方法變成一個單一的任務 - 同樣因爲測試更容易。

Answer 12

寫給其他人閱讀。這意味着好名字，好評和簡單陳述的結合。

曾幾何時，記憶稀少，循環時間緩慢。鼓勵程序員編寫複雜的單行代碼，完成許多事情。今天的記憶豐富，循環時間快。你應該寫5行簡單的代碼，人們可以遵循而不是一行他們無法理解的。

良好的評論不需要很長，但他們必須有幫助。

也是一致的。不要更改代碼中的樣式。例如，不要將命名樣式從一個部分更改爲下一個部分。

Answer 13

好評。好的評論通過說明代碼的預期目的來幫助抽象，不好的評論只是重申代碼的作用。評論實際上可以以精心設計和命名的單元測試的形式出現。

Answer 14

一致性。

Answer 15

我不覺得有什麼，你可以專注於一個單一的因素。如果有我認爲這將是一個很好的判斷。如果開發人員在設計階段使用了錯誤的判斷，即使有據可查，易於閱讀的代碼也很難維護。無論文檔和單元測試有多好，生產應用程序的糟糕設計幾乎無法解決。

你也可以看看類似的指導作用難於維護代碼的什麼不該做的想法。內容豐富而有趣！

http://mindprod.com/jgloss/unmain.html

我在公司有實際工作，在一些中就有所提及的事情「標準化」。你會認爲大部分東西只是常識，但你可能會感到驚訝。

Answer 16

正在對1號或者你只是寫了，一兩年後發行的軟件2級支持。

相信我，我一直在那裏我自己。我可能需要在幾年內維護或增強我自己的代碼的「恐懼」始終是提高可維護性的強大動力。

Answer 17

依我之見，以書面形式維護代碼的基本規則是，你的代碼應該是很容易理解的。這聽起來並不像聽起來那麼容易，你必須使用這裏提到的所有其他技術來做到這一點。它需要一定的同理心，因爲您必須瞭解其他開發人員如何看待您的代碼，以及它與您看到的方式有何不同。掌握這一點的一個好方法是回顧一下你幾年前寫的一些代碼。

現在，我想，這將是可能的，在理論上，編寫代碼，這是非常容易理解和執行它到底是用於但也很難以任何方式修改任務。儘管如此，我從來沒有見過這樣的代碼。

Answer 18

有很好的文檔。這包括自我記錄（分區，描述性命名和清晰）的代碼，良好的評論，精確到（最近）最終版本代碼的詳細設計文檔，以及源代碼控制中的描述性更改註釋。

如果你問了兩個，第二個肯定是單元測試。這是兩者之間艱難的選擇。

Answer 19

對我來說，寫測試代碼（結帳谷歌測試博客）是更好的維護代碼

Answer 20

沒有「最重要因素」，這是幾個因素的組合，如上文指出。

現在，大部分的這些規則可以濃縮成：「寫後面的代碼讀取它。」
或者套用一個有趣又很好的建議：「你寫的代碼，就好像它必須由一個殺人狂知道你住的地方保持下去。」 ......

Answer 21

一致的編碼風格。像方法和變量命名約定，樣式和註釋格式，甚至模塊/文件命名。

Answer 22

我已經投了馬特的回答「好抽象」但我想補充一下。

文檔化這是所有關於解釋事情。我都贊成Doxygen和其他自動文檔工具，但API中粗略的函數列表總比沒有好。

如果你想擁有你的代碼maintanable，描述您的解決方案，以抽象的適當水平和細化水平提高到代碼，這樣很明顯它做什麼。

Answer 23

我會去一些其他的，抽象。當你瞭解一些軟件模式時，它也會有所幫助，GOF是開始進行這類工作的好地方。

Answer 24

大量的空白。 - 高密度代碼很難理解。如果你有超過6行沒有空白行，那麼這個組可能不是一個有凝聚力的思想/想法/操作。

良好的變量名稱 - 解釋性，但簡潔。巨大的變量名稱與小型變量名稱一樣糟糕。

Answer 25

閱讀代碼完整 - 它涵蓋了從變量命名權到真正大的東西的一切，它是全部必要的。沒有一件事。

我的做法目前歸結到編寫代碼這樣做需要做的（不適用於未來的每一個工作的代碼可能需要可能做）用翔實的變量名和最小的變量範圍，並努力確保該作業我代碼儘可能少需要補充文檔。有時候，這會使我的變量和方法名稱比以前更冗長（當我使用它時，我的調試輸出非常複雜），但它們更易於理解。

可維護性通常也是其他方面堅實實踐的結果 - 如果您以良好的DRY方式編寫代碼，那麼問題更容易找到，如果您有一組強大的測試，那麼您可以看到維護變化將破壞任何東西。

最終還是試圖要考慮周全，並寫了面向未來的代碼問題只能寫一次，之後，這一切都維護...

Answer 26

小，良好定義的函數和類。

這是很容易習慣於別人的各種編碼規範，但如果一切都在一個巨大的類或函數，我的頭爆炸。

Answer 27

我會說最重要的因素是DRY。 glenatron在其他因素中已經提到了他的答案，但我認爲這是最重要的一個。

Answer 28

毫無疑問，編寫代碼設計爲供其他人閱讀。這包括避免高爾夫球，神祕的語法，以及有意思的變量名稱。如果代碼足夠乾淨，IMO可以完全避免寫任何註釋。 \

[採摘語言與OO內置的，而不是上漲了也有幫助]

Answer 29

我猜編寫維護的代碼超越代碼。我相信最好理解需求是什麼（並且以某種方式將其記錄爲功能性和非功能性），然後像新員工那樣介紹如何將其轉化爲代碼。

如果有人知道爲什麼代碼原來是這樣的，那麼它變得更容易，使之更好和/或將其展開。對於更多技術性的東西（例如算法），將其抽象地解釋（目標，原則），然後評論代碼和/或模式實現的關鍵部分。

我還要做的一件事是在我的應用程序中創建迷你實驗室，工具箱和代碼模板，以便人們知道做一件事或擴展另一件事所需的「標準」代碼是什麼（導致一些複製/粘貼但有助於生產更多，更好）。

Answer 30

有一種傾向，認爲計算機就是你的受衆。

嚴格地說，這是事實，因爲代碼必須工作。但是，如果你在腦海中寫下你的觀衆，那麼這種思維方式有助於產生更多可讀的代碼。

如果您擔心這會導致代碼變慢，請記住，絕大多數程序幾乎全部用於非常小的代碼部分。從可讀性開始編寫代碼，然後使用分析器確定要優化的正確部分。

Answer 31

我更喜歡當人們修剪和塑造代碼的時候。很多時候，你會發現一個體面的建築的原始脊柱，懸掛着巨大的混亂。

Answer 32

找到一位好導師。這個人不一定要比你更好的編碼器，但他們應該能夠建議其他適當編寫代碼的策略。一位好的導師將會提出以前給出的許多答案。他們可以成爲第二組眼睛，讓你知道你的短暫出現在哪裏，同時保持樂觀的樂觀情緒。他們也會靈活並不斷磨練自己的技能，就像你應該做的一樣。這樣，當下一個大範例出現時，你將能夠更好地將麥糠與麥子分開。當面向對象編程和源代碼控制被下一件大事所取代時（很難想象我知道），這將是無價的。

Answer 33

編程是性能;你永遠不應該忘記你的觀衆是誰。 「就像最終維護你的代碼的人是一個知道你住在哪裏的暴力精神病患者一樣。」

Answer 34

一貫應用的強大而合理的約定。類似於從何處開始索引的規則，什麼是最終狀態等。

這使得它更容易理解代碼，因爲所有代碼的行爲都會更簡單。

這至少是我的一個重要提示。

Answer 35

• 記錄假設當你讓他們 - 兩天後，你將採取這些假設是理所當然的，但誰維護您的代碼不一定會做出同樣的假設和旁邊的人會問，爲什麼你做了什麼你沒有...

• 代碼爲人 - 計算機將做任何你告訴它;代碼如此人可以理解你的代碼 - 誰知道它可能是你6個月後！

Answer 36

這已經很長時間了，但我有一個答案扔在：不要超過評論。這可能聽起來很愚蠢，但解釋簡單的東西的太多評論可能會使代碼變得混亂，因爲所有的東西都出去了。好的評論可以創造奇蹟，但毫無意義的評論恰恰相反。

Answer 37

純函數使得更容易推理代碼。確保您正確傳達副作用。 （即，當你不返回'結果'時通常會產生副作用，即無效函數）。