生命會(huì)逝去，但一個(gè)好的軟件不會(huì)。

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

1.模塊化

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

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

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

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

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

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

2.測試

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

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

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

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

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

3.持續(xù)集成

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

你寫的測試，你必須確?？梢詰?yīng)用于多種環(huán)境（例如Python的多個(gè)版本）。并且如果需要作出任何改動(dòng)，也得測試。

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

4.自動(dòng)化

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

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

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

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

5.冗余

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

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

給你個(gè)參考，我的代碼是這么存儲(chǔ)的：

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

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

6.提交

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

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

在你提交改動(dòng)信息一個(gè)星期后，因?yàn)榘l(fā)現(xiàn)引入了一個(gè)新的bug，所以你需要恢復(fù)原先的內(nèi)容。但是現(xiàn)在，因?yàn)槟闾峤坏男畔⒁呀?jīng)覆蓋了原先的信息，那么你就只能慢慢摸索原來是怎么寫的了。

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

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

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

7.計(jì)劃

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

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

不怕一萬，就怕萬一。

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

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

詳細(xì)地記錄到文檔中。

結(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