軟體長壽法則 記住這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. 計劃

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

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

　　最後

　　如果您並不相信這幾個規則，回答以下兩個問題：

• 你希望一個新人加入你的團隊，並能夠很輕易的理解現有的程式碼嗎？
• 重構程式碼是簡單快速的嗎？

　　如果你的回答是“No”，或許你應該再重新看一遍本文，與你的團隊分享一下。

　　最後Happy programming！！！

　　原文來自：Medium