規則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：冗餘版本控制：不要僅依賴於Git，可以使用多個同步異地的遠端遙控，增加冗餘。
俗話說，雞蛋不能放在同一個籃子裡。如果你的程式碼只託管在Github上，那麼一旦Github出現故障等，你的工作流程就會受影響。
給你個參考，我的程式碼是這麼儲存的：
- 所有程式碼都放在Dropbox的“Codebase”資料夾中。自動同步變化。
- 在Github也放上幾乎所有的程式碼。
- 最重要的程式碼，則同時放在兩處比較祕密的地方。
6.提交
規則6：提交：做一點小小的改變，然後頻繁提交，不要出現問題程式碼。
很多程式設計師將版本控制系統當作是備份方式，而非維護歷史的一種手段。要知道，像這些歷史資訊是沒用的，除非你想要做的只是檢索檔案。
在你提交改動資訊一個星期後，因為發現引入了一個新的bug，所以你需要恢復原先的內容。但是現在，因為你提交的資訊已經覆蓋了原先的資訊，那麼你就只能慢慢摸索原來是怎麼寫的了。
版本控制系統，正是為了防止出現這樣的情況。
如果你覺得寫出好的提交很難，那麼可以按照下面這個模板走：
- 每次提交都應該有一個目的。確定是修復bug，新增新的功能，還是刪除現有的功能？
- 改動一次提交一次。
- 提交資訊包括髮布排序號碼。
- 提交描述中應說明改動情況。這取決於專案的指導方針，通常包括是什麼造成了bug，如何修復，以及如何對改動進行測試。
- 提交資訊應寫得明白易懂。
規則7：有計劃：為最壞的情況作準備。如果確實出現了錯誤應怎麼做？在檔案中詳細說明這些步驟。
即使照著上面的6條規則一絲不苟地執行，寫出來軟體也不可能盡善盡美。如果你曾這樣想過，那就未免過於天真了。
不怕一萬，就怕萬一。
可以制定一個計劃，為最壞的情況作準備。如果網站流量一下子太多了怎麼辦？出現未知bug，導致系統癱瘓，可以到哪裡去扒拉出備份？半夜三更伺服器當機，可以找誰？
好好考慮這些情況。但也不必過於杞人憂天。然後儘可能自動化可以自動化的步驟。
詳細地記錄到文件中。
結束
記住，你的軟體是你的遺產。它能活得多久完全取決於你。So，軟體是朝生暮死還是永垂不朽，就看你怎麼做了。
評論(1)