軟件長壽法則，記住這7條

簡體傳統

【編者按】軟件設計構造師Karan Goel在看到“joe”瘋狂的成功之后，為我們總結了7個可以使軟件壽命更長的規則，這其中包括：模塊化、測試、持續集成、自動化等等。他表示遵循的規則越多，你軟件的壽命就越長。下面一起來看看這些規則背后的細節。

以下為譯文：

在“joe”瘋狂的成功之后，我列出了一個我認為評判好壞軟件的清單。盡管這使我對事物看得很清楚，然而對于任何給定的項目，很少有可以遵循這些規則的，包括我自己在內。但是你遵循的規則越多，你軟件的壽命就越長。

什么讓你遠離編寫好的代碼？“快速打破事物”不是一件好事嗎？

不！學習創建軟件是一種技巧，任何人都能做到。而學習創建好的軟件則是一種藝術，它需要時間、努力和奉獻精神。

你希望世界上有更多的SEGFAULTs（段錯誤）嗎？你希望系統管理員因為你的糟糕代碼而不斷的被電話騷擾嗎？你希望你的PM是因為你的軟件惹毛了用戶而記住你嗎？……

我并不反對任何形式的快速發展，因為我相信MVP和第一時間推出的力量。但是在某些時候，當時間充裕的時，你必須要意識到低質量代碼是走不遠的。

當你走進醫生辦公室時，醫生會詢問你一系列問題來確定你的病因，他們不會在沒診斷的情況下給你開藥。

同樣，知道在什么時間“寫壞了”軟件對你很重要。這里有些問題可以很好的幫助診斷我們是否正在編寫糟糕的軟件：

更新軟件花費很多時間和精力嗎？
當你做一個很小的改變時，整個系統還會運行OK嗎？
你的產品中是否存在碎片代碼，并直到用戶抱怨的時候才意識到它們的存在？
當你的系統崩潰時你知道要如何做嗎——如何深入備份并部署它們？
你在某些事情上花費很多時間嗎？比如在不同環境之間轉移，或者重復運行著相同的命令……

因此，讓我們來看看本文所說的規則有哪些？

1. 模塊化

處理有Bug模塊的工作要比處理整個代碼輕松的多

雖然相比較有史以來最復雜的CPU來說，人類要更加的復雜，但是你不得不承認人類有時也會有無法解決的復雜問題，簡單的來說，如果不使用任何計算器，你能告訴我13x35等于多少嗎？我打賭你做不到，至少在一個合理的時間內你做不到。

但是我們擅長將復雜的問題逐步的分解為較小的我們能夠解決的問題。

13x10是多少？130，13x5呢？即為130/2=65。那么130x3是多少？是390，390+65呢？455。搞定！（PS：或許你會有更簡單的方法。當問題越復雜的時候，分解的優勢就越顯而易見。）

將同樣的邏輯運用到軟件當中，通過多個文件、文件夾甚至是項目來劃分你的軟件，將所有相關性的事物遵循MVC或其他變化規律置于一個位置。

這不僅會提高代碼的可閱讀性，也會讓你的調試變得更加容易。在大多數情況下，堆棧跟蹤會領你前往非常小的代碼集，而不是成千上萬行的代碼文件。當更新個別模塊時，你就不需要考慮整個系統。

2. 測試

我因不經常為我的代碼編寫測試而愧疚，所有的產品代碼都需要測試

我們習慣性的去把測試當作是一種不同于做軟件的活動，即便是在學校，你被傳授的是C++模塊如何工作的，卻沒人教你它們是如何被測試的。在線教程會教你如何使用Brainfuck制作一個Web服務，然而它們不會告訴你如何去測試它，這就是問題所在。

有些人會告訴你，在開始寫實際的應用邏輯之前，首先要做的是編寫測試。

何時編寫測試各有喜好，只要寫了就OK。當你第一次開始的時候，不要試圖成為一個測試高手，從簡單粗暴開始，如print(add(1, 1) == 2)，然后在逐步到測試整個框架。

當你開始測試你的代碼時，你將會明白你軟件的復雜性。你將開始學習如何將你的軟件模塊化，以便可能獨立測試。所以當你遵循了這一規則的時候，你同時也在遵循第一個規則——模塊化。

3. 持續集成

持續集成是偉大的，它們會在你添加broken code（碎片代碼）的時候通知你

當你編寫測試之后，你需要確保它們是合格的，同時也要確保它們在多種環境下是合格的（例如多版本的Python）。在代碼作出任何改變時，你也需要測試。

當你能夠手動的做這些時，你可以選擇更方便、更快以及更便宜的持續集成平臺。

Thoughtworks在CI上有顯著的貢獻，關于CI，你需要知道：

Continuous Integration（CI，持續集成）是一個開發實踐，需要開發者每天數次的頻率將代碼集成到一個共享的庫中，每一次入駐都會被自動構建歸檔，以便團隊提早發現問題。這里推薦兩個：TravisCI和Drone.io

4. 自動化

有多個腳步需要運行測試和部署？將它們添加在單一的bash腳步中，減少步驟，節約時間

大的項目通常會有一些像引導代碼或以不同的方式測試代碼等任務，又或者部署到不同的服務器，備份部分的代碼等等。

有些人會使用txt文本來存儲這些命令，并在需要的時候復制粘貼。如果你是這樣的，或許你應該抽個時間來學習一下bash腳本（或Python）。這里有些常見的任務，你應該用到簡單的bash腳本來自動化處理它們：

將README.md轉換為其他格式（取決于不同的分配路徑需求）
自動化測試（包括創建模擬服務器或數據、刪除臨時文件等等）
開發服務器的階段代碼
部署到產品
自動從屬更新（注意，這一點不是總能使用，尤其是當更新會打破現有API時）

5. 信息冗余

冗余版本控制，不要僅依賴于Github，使用多個同步的站外遠程，增加信息冗余

當你訪問git-scm.com時你會看到這么一段話：

Git是一個免費和開源的分布式版本控制系統，用于敏捷高效地處理任何或小或大的項目。

在這段話里，分布式是關鍵。

如果你把代碼僅僅托管于Github的話，或許你應該需要反思了。試想一下，但凡Github有一點故障，你的工作流程將會停止。你無法預料到意外何時會出現，所以保持代碼的離線備份永遠都不會是一個壞注意。這種情況下信息冗余對你而言是一件好的事情。

這里提供一些代碼存儲的參考：

將代碼存儲與Dropbox的Codebase文件夾中，自動同步變化；
同時將代碼存儲于Github；
將最重要的代碼存于另外兩個地方。

6. 提交

對于經常做出改變、提交和推動的人來說使用合理的提交信息是很有必要的。

看看你提交的歷史，你會發現類似這樣的信息：

“fixed issue with module”

“fixed”指什么？“issue”又是什么問題？模塊化有時哪個？

很多程序員多會把版本控制系統當作是一種備份，而不是維護歷史的一種手段，充滿這種信息的歷史版本是沒有用處的，除非你想去做檢索文件。

如果你覺得很難去寫好一個提交信息，或許可以參考以下幾點：

每個提交都應該有一個目的：修復一個缺陷、添加一個新特性或刪除一個現有的特性等等；
每次僅提交一個改變；
在提交的信息中應包含問題編號；
提交說明中應對改變作出描述；
編寫合理的提交信息，如：“fixed cache being reset on every insert caused by missed access after write. fixes #341”或“added a new form in header to make it easier to collect leads. close #3”。但是千萬不要是這樣：“remove stuff because why not.xoxo”

7. 計劃

制定一個計劃為最壞的情況做準備，一旦真的出現問題，你該怎么做？所以在文檔中詳細的寫下步驟。

即便遵循以上六個規則，也并不是意味著你的軟件是不可戰勝的。說不定由于什么或者是誰的過失，災難就會降臨。所以有一個計劃是明智的，一個計劃會讓你看上去“很聰明”，事實也是如此。

最后