生命會逝去，但一個好的軟件不會。

要想寫出一個“永垂不朽”的軟件，關鍵是你能否遵循以下規則：

1.模塊化

規則1：模塊化。在一個模塊中找bug總比在整個代碼庫里找簡單得多。

人腦是極其復雜的生物，可以設計出能處理復雜問題的CPU，但自我本身卻處理不來這些問題。想要證明嗎？那么告訴我，在不使用任何計算器，純心算的條件下，你能算出13*35是多少么。我敢打賭，你不能。至少在短時間內你辦不到。

但是，我們擅長將復雜的問題分解為更容易解決的問題。

13*10是多少？ 130。
13*5呢？那就是130/2=65。
130*3？ 390。
390+65是多少？ 455。答案就是它了！

這就是如何分解問題的一個事例：將一個大型的復雜問題分解為一個個獨立的小型的簡單問題，從而快速得出正確的答案。

我們也可以按照同樣的邏輯對待軟件。模塊化的代碼不僅易于閱讀，而且更容易調試。在大多數情況下，堆棧跟蹤只會導致非常小的代碼子集，而不是一下子出來個1000行代碼的文件。甚至在更新某個特定模塊時，也不需要搗騰整個系統——只要正在更新的那部分就可以了。

2.測試

規則2：任何不經過測試的代碼都是耍流氓。

很多人認為測試和寫軟件是兩碼事，即使是在學校中，教師會教你如何使用C ++模板，卻不會告訴你如何測試。在線教程能教你如何在Brainfuck制作web服務器，卻不會說明如何測試。而這就是問題的所在。

有人說，我們應該在編寫實際的應用程序邏輯之前就先寫好測試。

但是在我看來，什么時候寫測試其實并沒有關系，只要寫了就ok。不要試圖一步登天，不要想著剛開始就寫得出***的測試：從簡單的起步。用蠻力方式測試（如print（add（1，1）=2）），然后再測試對應語言的框架。

測試有助于我們了解軟件的復雜性。你可以學到如何將軟件模塊化為可以獨立的測試件。

3.持續集成

規則3：使用持續集成。只要出現問題代碼，就會通知你。

你寫的測試，你必須確保可以應用于多種環境（例如Python的多個版本）。并且如果需要作出任何改動，也得測試。

當然你也可以手動操作命令行，但是使用持續集成的平臺更方便，更快捷，成本更低。

4.自動化

規則4：自動化。自動化可以減少步驟，節約時間。

我看到很多人會存儲命令txt文件，以便需要的時候可以復制粘貼。我建議你不妨學習bash腳本（和/或Python）。

以下是一些你必須自動化的bash腳本任務：

• 將README.md轉換為其他格式（取決于不同的分銷渠道要求）
• 自動化測試（包括創建模擬服務器和/或數據，刪除臨時文件等）。
• 階段化代碼給開發服務器。
• 部署到生產。
• 自動化的更新依賴（特別是當更新有可能會破壞現有的API時，尤其要小心）。

5.冗余

規則5：冗余版本控制：不要僅依賴于Git，可以使用多個同步異地的遠程遙控，增加冗余。

俗話說，雞蛋不能放在同一個籃子里。如果你的代碼只托管在Github上，那么一旦Github出現故障等，你的工作流程就會受影響。

給你個參考，我的代碼是這么存儲的：

• 所有代碼都放在Dropbox的“Codebase”文件夾中。自動同步變化。
• 在Github也放上幾乎所有的代碼。
• 最重要的代碼，則同時放在兩處比較秘密的地方。

你看，除非世界末日，不然我的代碼怎么搞也不會丟失。

6.提交

規則6：提交：做一點小小的改變，然后頻繁提交，不要出現問題代碼。

很多程序員將版本控制系統當作是備份方式，而非維護歷史的一種手段。要知道，像這些歷史信息是沒用的，除非你想要做的只是檢索文件。

在你提交改動信息一個星期后，因為發現引入了一個新的bug，所以你需要恢復原先的內容。但是現在，因為你提交的信息已經覆蓋了原先的信息，那么你就只能慢慢摸索原來是怎么寫的了。

版本控制系統，正是為了防止出現這樣的情況。

如果你覺得寫出好的提交很難，那么可以按照下面這個模板走：

• 每次提交都應該有一個目的。確定是修復bug，添加新的功能，還是刪除現有的功能？
• 改動一次提交一次。
• 提交信息包括發布排序號碼。
• 提交描述中應說明改動情況。這取決于項目的指導方針，通常包括是什么造成了bug，如何修復，以及如何對改動進行測試。
• 提交信息應寫得明白易懂。

7.計劃

規則7：有計劃：為最壞的情況作準備。如果確實出現了錯誤應怎么做？在文件中詳細說明這些步驟。

即使照著上面的6條規則一絲不茍地執行，寫出來軟件也不可能盡善盡美。如果你曾這樣想過，那就未免過于天真了。

不怕一萬，就怕萬一。

可以制定一個計劃，為最壞的情況作準備。如果網站流量一下子太多了怎么辦？出現未知bug，導致系統癱瘓，可以到哪里去扒拉出備份？半夜三更服務器宕機，可以找誰？

好好考慮這些情況。但也不必過于杞人憂天。然后盡可能自動化可以自動化的步驟。

詳細地記錄到文檔中。

結束

記住，你的軟件是你的遺產。它能活得多久完全取決于你。So，軟件是朝生暮死還是永垂不朽，就看你怎么做了。

譯文鏈接：http://www.codeceo.com/article/7-rules-software-not-die.html
英文原文：The 7 Rules for Writing Software That Won’t Die When You Do