前言：寫**的好習慣除了言簡意賅的注釋外，還有完善且必要的日誌。注釋主要是對**內的模組或功能函式、演算法、邏輯框架等進行必要簡明的說明，它關注的是」這個「**裡做了什麼。而日誌需要說明的是這版**和上一版本改了什麼（重點關注**的公升級迭代、用途、風險），和其他**有啥關係（比如關注是否某些功能模組借鑑或移植於其他專案）。所以日誌主要關注的是「這些」**之間的關係（改動、移植），以及怎麼用它，有何風險。所以不要覺得**裡寫了足夠的注釋就不需要寫log了，經驗豐富的軟體開發們會形成自己完整的一套規範風格。
如何寫**日誌？
這是我們要回答的第乙個問題。通過上面的簡介我們大致知道**log需要記錄哪些資訊了，但是這還不夠。做軟體乙個很重要的思維方式就是把問題分類或分塊進行細化。一版**按照開發的程序分，可以分為首次開發和變更開發。按照軟體發布的用途分，可以分為臨時程式（用於新方案實驗、輔助硬體測試、給客戶送樣等）和受控程式（指正式出貨的程式）。按照發布次數可以分為初版發布和變更發布（程式公升級）。另外還可以根據自己特色進行分類，比如按所用晶元型號、平台、開發語言、內部開發或內外合作。你的日誌裡要能清晰分辨出來現在在做的是屬於哪一類程式。
先弄清楚現在要寫的是什麼程式
當專案立項時,我們第一步當然是仔細閱讀相關文件（可能是設計開發要求、方案策略設計說明、設計變更通知單、產品立項報告等等，不同的公司會有較大的差異，當然有些公司沒有任何文件，全靠嘴（我這經歷過什麼。。。））。這些文件裡除了告訴我們需要做出什麼樣功能的程式外，我們還能知道這是乙個新專案還是老專案公升級，這是將來要正式出貨的程式還是只是實驗程式。如果是老專案程式公升級，那它就一定存在歷史版本，且應該清楚的知道改動了什麼。如果是正式出貨的程式，那它一定有適用範圍，比如這版程式用於哪些型號，哪些晶元或平台，甚至應該有對應的硬體版本號（當然，當硬體電路做出改動時軟體需要評估是否能相容，這種問題比較多發生在嵌入式行業，網際網路行業就是所用的架構和平台版本了）。如果是臨時程式，一定要把它區別於正式程式，寫明程式的意圖和提供給了誰，特別是做了某些實驗驗證後會得出一些進展結果，能說明的盡量說明。
開發一版程式往往不可能svn只上傳一次就成功，開發過程中，每天下班前上傳新**並寫上log是乙個好習慣，這種情況需要簡明的寫上**改動點和遺留問題，方便下一次開發能快速銜接。
未發布軟體log模板
--------------------------------**開發----------------------------------------------
工程名：（寫這個並不重複，因為工程名後期可能會改（雖然幾乎不會），每個日誌都寫方便追溯。）
軟體版本：（如：200305 v1.0）
上傳修改：（首次上傳/修改上傳。）
版本迭代：（初版/在某某版本上變更公升級。）
上傳人：（還是建議給自己取個英文名吧。）
上傳原因：（如果是首次上傳就寫明開發目的，如：某某專案生產出貨、用於某實驗、給某客戶送樣等，如果是開發過程中的修改上傳就寫開發上傳。）
遺留問題：（如果是在開發過程中的修改上傳，寫明還未進行和還未完成的功能，以便下次繼續開發。如果是已經發布的程式，寫明軟體的風險點，方便未來軟體公升級時優化或排查bug時更快定位問題。如果暫未發現風險點則寫未知。）
適用範圍：（在這裡寫明用於什麼晶元或平台。用了什麼開發工具（有些大公司比較統一，而且萬年不公升級工具，一般小公司比較亂，不同的人用不同版本的ide，甚至不同的開發語言。適用於哪些專案，寫上專案名。總之限制軟體通用性的條件可以寫在這裡。）
* 使用晶元：
* 硬體版本：
* 適用專案：
* 適用協議：
工具平台：（在這裡寫上所用開發工具或平台的版本。）
* 底層庫版本：
* 編譯器：
* 離線程式設計器上位機：
其他描述：（需要提示或強調的東西，比如和某第三方公司合作開發，分別負責什麼模組之類的。）
像前面的開發日誌主要是寫給軟體開發人員看的，而發布出去的程式供給外部門，他們不需要知道太多軟體修改的細節，主要需描述清楚3點：1、這版軟體實現了哪些功能。2、適用範圍。3、風險點有哪些。發布日誌還有乙個重要的資訊，就是版本的公升級迭代關係。這版軟體是用於替換哪版舊軟體，還是初版軟體，這一點也可以歸類到適用範圍裡。一些大公司有完善的流程管理平台（比如jira等），相關的資訊詳細記錄在平台上。對於一些未搭建平台的小公司建議在工程裡建立乙個文件，隨著開發過程保持文件更新。這份文件在最終出貨時可以做成軟體適用說明文件給出去。
已發布軟體log模板
--------------------------------軟體發布----------------------------------------------
發布軟體名：（要發布的是軟體名稱，名稱裡要帶上軟體版本號。）
軟體版本：（如：200305 v1.0）
專案當前狀態：（完成/進行/暫停/廢止）
發布目的：（用於某專案產品生產出貨/用於某項實驗/）
版本特徵：（正式出貨的為受控版，對其有嚴格的管控，其他為臨時版，比如用於測試或驗證，管控可能不嚴格。）
版本迭代：（初版/在某某版上修改）
發布人：
功能描述：（列舉出該版軟體已經實現的功能，重點描述設計開發要求上提到的功能的實現情況。只寫實現了沒有，不要在這裡囉嗦描述為什麼沒有實現原因等。）
變更原因：（如果是舊版基礎上變更則寫明變更原因。若為初版則寫初版即可。）
變更點：（變更程式簡明寫變更點（這裡不要寫詳細的軟體修改點，從前後兩版的功能角度寫解決了什麼bug或做了什麼優化。若為初版則寫初版即可。）
適用範圍：（在這裡寫明用於什麼晶元或平台。用了什麼開發工具（有些大公司比較統一，而且萬年不公升級工具，一般小公司比較亂，不同的人用不同版本的ide，甚至不同的開發語言。適用於哪些專案，寫上專案名。總之限制軟體通用性的條件可以寫在這裡。）
* 使用晶元：
* 硬體版本：
* 適用專案：
* 適用協議：
測試情況：（通過測試/未通過測試）
遺留問題：（寫明風險點，如果暫未發現風險點則寫未知。）
工具平台：（在這裡寫上所用開發工具或平台的版本。）
* 底層庫版本：
* 編譯器：
* 離線程式設計器上位機：
其他描述：（需要提示或強調的東西，比如和某第三方公司合作開發，分別負責什麼模組之類的。）
上面已經討論過如何給**寫上日誌，在開發過程中乙個軟體開發人員會接收和產出很多文件，這些文件都需要和專案相關聯並並在svn等平台做好記錄並上傳，也會設計到log的編寫。一般來說文件的log相對顯得不那麼重要，只需在日誌裡說明上傳的文件裡包含了哪些資訊，屬於哪個專案，文件修改時簡略說明文件的修改點。當然比較重要的資訊比如除錯測試報告測出bug或發現風險時，也請在log裡簡明描述下。有些公司會按照文件的類別進行分類log，比如除錯測試報告的log規範和軟體其他文件log規範不同，這裡我只介紹通用簡單的模板。
文件log模板
--------------------------------文件上傳----------------------------------------------
上傳修改：（首次上傳/修改上傳。）
上傳人：
上傳原因：（比如：某某專案某版軟體設計開發要求。某某專案某版軟體除錯報告。流程規範化軟體則寫軟體規範化實施說明管理文件。等等。）
修改點：（簡明寫文件做了哪些改動，如果第一次上傳就寫首次上傳。）
其他描述：（需要提示或強調的東西，比如除錯測試報告裡發現的bug或風險點。）
軟體開發目錄規範
為了提高程式的可讀性與可維護性，我們應該為軟體設計良好的目錄結構，這與規範的編碼風格同等重要，簡而言之就是把軟體 分檔案目錄。假設你要寫乙個atm軟體，你可以按照下面的目錄結構管理你的軟體 atm core src.py 業務核心邏輯 api api.py 介面檔案 db db handle.py ...
軟體開發目錄規範
為了提高程式的可讀性與可維護性，我們應該為軟體設計良好的目錄結構，這與規範的編碼風格同等重要。軟體的目錄規範並無硬性標準，只要清晰可讀即可，假設你的軟體名為foo，筆者推薦目錄結構如下 foo core 存放業務邏輯相關 core.py api 存放介面檔案，介面主要用於為業務邏輯提供資料操作。ap...
軟體開發目錄規範
api 存放介面檔案，介面主要用於為業務邏輯提供資料操作 api.py 應用程式程式設計介面 bin 整個專案的啟動檔案放置在這個資料夾中 start.py 啟動軟體入口 conf 整個專案的配置檔案放置在這個資料夾 settings.py 配置檔案 比如存放一些固定的路徑 core 整個專案的核心...