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

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

1.模塊化

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

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

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

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

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

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

2.測試

規(guī)則2：任何不經(jīng)過測試的代碼都是耍流氓。

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

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

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

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

3.持續(xù)集成

規(guī)則3：使用持續(xù)集成。只要出現(xiàn)問題代碼，就會通知你。

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

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

4.自動化

規(guī)則4：自動化。自動化可以減少步驟，節(jié)約時間。

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

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

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

5.冗余

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

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

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

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

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

6.提交

規(guī)則6：提交：做一點小小的改變，然后頻繁提交，不要出現(xiàn)問題代碼。

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

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

版本控制系統(tǒng)，正是為了防止出現(xiàn)這樣的情況。

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

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

7.計劃

規(guī)則7：有計劃：為最壞的情況作準(zhǔn)備。如果確實出現(xiàn)了錯誤應(yīng)怎么做？在文件中詳細說明這些步驟。

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

不怕一萬，就怕萬一。

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

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

詳細地記錄到文檔中。

結(jié)束

記住，你的軟件是你的遺產(chǎn)。它能活得多久完全取決于你。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