1. 代碼規範（讀教材）
讀了《建構之法》中關于代碼規範的章節，筆記加個人了解如下。
為什麼要規範代碼？ 有利于代碼維護，有利于代碼評審，有利于團隊合作。
1.1 代碼風格規範
代碼風格規範——個人了解就是代碼的排版。
1 注釋：解釋程式做什麼。
—— 不要寫不必要的注釋。
—— 注釋與代碼同步。（代碼變動需要注意注釋是否需要修改）
—— 注釋與團隊合作。 很多人在實際的開發中往往不重視注釋，沒有好的注釋，團隊成員合作是會受到影響的。假如你釋出了幾個類似功能的接口，如果你在注釋中很好的解釋了接口的功能，輸入參數限制等，其他人通過你的注釋就會明了使用你釋出的哪個接口。反之，需要去研究你的代碼實作——若你的實作很複雜，調用很多其它接口，了解起來困難耗時，影響團隊合作。
2. 換行：每行隻寫一條語句；每行隻定義一個變量；用空行分割小功能塊。
3. 縮進：建議使用4個空格或是把tab設定為4個空格。
分支結構，循環結構中使用縮進。
4. 大括号：分支結構，循環結構中使用大括号，即使僅包含一條語句。
5. 命名：第一個單詞全部小寫，其他單詞首字母大寫。
函數名采用動詞，動名詞；其他采用名詞。
6. 行寬：80字元或100字元。
1.2 代碼設計規範
對于代碼風格規範，相信大家都有所了解，遵守了很容易做到。（有些開發工具可以幫助自動設定好風格規範，除了代碼注釋， 開發的時候可以不用過多關注。） 但對于代碼設計規範，很多人就不是很了解了。教材對代碼設計規範的一些通用原則做了很詳細的介紹，仔細的讀了兩遍，發現這方面如果要做好，需要慢慢訓練。
1. 函數功能唯一：一個函數隻做一件事，并且要做好。（函數代碼行數建議80行，最多200行）。
2. 函數參數校驗：Debug版所有參數進行校驗；正式版本對外部傳參進行校驗。
3. 一個函數最好有單一出口，有利于邏輯控制。
4. 錯誤處理：當對某件事不确定時，需要寫代碼處理可能發生的與預期不符的錯誤情況。
5. 斷言的使用：當對某件事很肯定，就這一種預期結果，不允許出現其他結果，此時可使用斷言。
6. 代碼重用性——（TODO）注意利用語言、類庫、架構裡提供的方法。
7. 日志 ——記錄關鍵重要資訊（例：購票系統中，記錄誰在什麼時間買了什麼火車票）
便于查找bug。
（建議調用标準庫或者系統API）
2. 列出一個checklist
| 階段 | 檢查項 | 結果 |
| 需求分析 | 檢查是否有需求遺漏 | |
| 檢查是否進行了需求設計書評審 | ||
| 檢查是否進行了測試用例設計評審 | ||
| 設計 | 檢查是否進行了Demo或界面原型評審 | |
| 檢查是否進行了概要設計評審 | ||
| 檢查是否進行了詳細設計評審 | ||
| 開發 | 檢查代碼的功能是否實作所有需求 | |
| 檢查代碼的效能 | ||
| 檢查是否進行單元測試 | ||
| 檢查代碼的可移植性 | ||
| 檢查是否遵從代碼風格規範和設計規範 | ||
| 檢查代碼是否有寫死 | ||
| 檢查是否有無用代碼未删除 | ||
| 檢查是否有可優化代碼 |
3. 效能分析和測試
關于效能分析：看了教材中關于效能分析的介紹，正如書中所說，不要随便猜測，要進行實際驗證，資料才更具有說服力。
尤其作為新手和這方面經驗不足的人，隻有你實際驗證過了，逐漸掌握的多了，才能像别人那樣直接指出效能差的地方。
關于測試：
4. 使用者需求
5.1 功能需求
5.2 非功能需求
5. 過程控制：燃盡圖、魚刺圖、甘特圖
6.1 燃盡圖
燃盡圖：用圖形展現故事點随時間的變化情況（對故事點了解的不好）。
試着自己畫了一個燃盡圖（在這裡假定有5項任務：1. 編寫概要設計 2. 編寫詳細設計 3. 開發代碼 4. 測試 5. 釋出）
其中： Y軸代表任務數（燃盡圖的Y軸一般描述故事點）； X軸代表時間 （時間以天為機關）。
在執行整個過程開始，根據計劃，畫出了如上圖中紅色線的一條參照線。（紅色參照線是計劃的理想情況，随着時間的推移，剩餘任務數逐漸較少）
圖中黑色線條代表了整個過程中剩餘任務數随時間變化的實際曲線。
從整個黑線可以看出3.17，3.21日新添加了2個任務，但在3.18——3.23黑色線條一直在紅色參照線的下方，說明最初的計劃高估了完成任務所需時間。
燃盡圖——友善管理者可視化的觀測工作随時間的變化，根據實際燃盡曲線和參照線的差異做合理調整。
通過燃盡圖如何評價過程控制的好壞呢？若燃盡曲線在參照線上下小浮浮動，說明該過程控制計劃很合理，無需調整；若燃盡曲線在某一天後一直在參照線上方，則說明該計劃有風險，可能要延期，需要及時調整；若燃盡曲線在某一天後一直處于參照線下方，說明高估了任務完成所需時間，也需要調整。
注：燃盡圖中不展現具體任務。
6.2 甘特圖
在6.1中用燃盡圖，我們看到的是剩餘任務數随時間的燃盡情況，無法通過該圖來觀察到具體有哪些任務，也無法觀測到還剩下哪些任務，各個任務進行到了什麼階段。
甘特圖描述了整個計劃中具體任務與時間的關系。
6.3 魚刺圖
6. 互評部落格
進行了互評，隻評論了一人。
7. PSP
| job | type | date | start | end | total(min) |
| 編寫随筆大綱 | 随筆 | 2016.03.14 | 12:30 | 12:46 | 16 |
| 代碼規範 | 讀書 | 13:00 | 13:30 | 30 | |
| 更新随筆：代碼風格規範讀書筆記 | 13:31 | 14:13 | 42 | ||
| 更新随筆：PSP | 14:26 | 13 | |||
| 更新随筆：代碼設計規範讀書筆記 | 2016.03.15 | 08:10 | 08:33 | 23 | |
| 更新随筆：checklist | 随筆 | 9:30 | 10:11 | 41 | |
| 了解燃盡圖，甘特圖，魚刺圖 | 2016.3.16 | 09:35 | 10:21 | 46 | |
| 更新随筆：燃盡圖 | 随筆 | 12:00 | 13:20 | 80 |
8. 選做：從範圍的角度，對比一類軟體（3個軟體）