# B05: introspect
###### tags: `sysprog2017`
:::info
主講人: [jserv](http://wiki.csie.ncku.edu.tw/User/jserv) / 課程討論區: [2017 年系統軟體課程](https://www.facebook.com/groups/system.software2017/)
:mega: 返回「[嵌入式作業系統設計與實作](http://wiki.csie.ncku.edu.tw/sysprog/schedule)」課程進度表
:::

## 預期目標
* 為 [code review](https://en.wikipedia.org/wiki/Code_review) 做好必要的準備工作，練習 [Software peer review](https://en.wikipedia.org/wiki/Software_peer_review)
* 歌德說：「要欣賞自己的價值，就得給世界增添價值」，從反省和觀摩中重新檢視自己作品的具體突破，來日提出增添價值的途徑
* [軟體工程師要學會說故事](https://ruddyblog.wordpress.com/2016/06/18/)，從良性詳盡的批評開始

## 作業要求
* 在 [2017q1 Homework1 作業區](https://hackmd.io/s/Hy2rieDYe) 挑出自己以外的 4 項學生開發成果，在開發紀錄後方標注 "::: Reviewed by 你的GitHub帳號名稱"，像是
> 開發紀錄(phonebook) / github ::: Reviewed by <`jserv`>
:::warning
中間的空白不要漏掉了，在 `)`, `/`, `:::` 之間都有。並且你的 GitHub 帳號名稱前後要標註 "`"
:::
* 每份開發成果至多只能被 3 個人批評，"Reviewed by" 後面的 GitHub 帳號用逗號 `,` 分隔
* 可參照 [2016 年秋季 Homework1 作業區](https://hackmd.io/s/H1B7-hGp)
* 選定開發紀錄後，編輯內文，加上 `Reviewed by 你的GitHub帳號名稱` 的段落，[示範的 Review](/s/BJjL6cQ6)，你的意見要寫在共筆的最上方，僅次於 "contributed by"。要從以下方面探討:
* 程式碼的 coding style, git commit messages
* 實驗設計的不足處、涵蓋程度是否全面，以及後續的改進空間
* 建議引入新的方法，如 memory pool，來縮減 `append()` 的時間成本，當然，你自己要先嘗試成功過
* 回覆原本在共筆中的疑惑
* 斟酌在選定的 GitHub repository 留下 code review 意見
* 截止日期：
* ==Mar 11, 2017 (含) 之前==

## Git commit messages
* 詳閱 [How to Write a Git Commit Message](http://chris.beams.io/posts/git-commit/)
* 好的 commit messages 的 7 個規則:
1. Separate subject from body with a blank line
標題與內文以一個空白行分隔，這樣可在使用 `$ git log` 閱讀時較易區分標題
2. Limit the subject line to 50 characters
標題字數最多 50。因為標題字數超過 50 在 github 上會被隱藏到 `…` 裡面，需要額外點開才能完整知道這個 commit 在做什麼。並且超過 50 字可能就不是一個精簡的標題
3. Capitalize the subject line
標題首字大寫
4. Do not end the subject line with a period
標題結尾不要句點
5. Use the imperative mood in the subject line
標題用命令口吻
6. Wrap the body at 72 characters
內文一行字數不超過 72
這樣在 `$ git log` 裡面看會比較清楚，排版比較好看
7. Use the body to explain what and why vs. how
內文說明是什麼、為什麼而不是如何做。因為看 commit 的人是想知道你為什麼要做這件事，而不是要知道你如何做這件事的 (動機比細節更重要)
* 檢視同學們的程式碼，提出他們撰寫的訊息是否符合前述原則。如果不符合，就直接寫在 Review 內容中

## 示範: [Reviewed by `jserv`](/s/BJjL6cQ6)
* 沒有嘗試不同的 data set，原本的程式輸入是已排序、非典型英文姓氏，這與現實不匹配
* 實做提到透過引入 hash 加速 `fineName()` 的操作，但缺乏不同 hash function 的效能比較和設計取捨
* 在 `append()` 中，`malloc()` 是個顯著的時間開銷，缺乏減緩效能衝擊的方案
* 卻乏搜尋演算法的評估和效能分析
* 考慮到電話簿需要作到動態資料新增和刪除，若引入 hash，面對大量資料時，會有什麼影響？
* 儘管已經整理頗多 perf 和效能測量的資料，但並未反映到此程式效能分析，除了 cache miss，還請一併探討 branch prediction accuracy 等議題
* `main.c` 無法透過 function pointer 來切換和比較不同實做的效能落差，應該先設計一份可通用的軟體界面，然後將 binary tree, hash table, trie 等不同實做機制加入
* 將 `append()` 和 `findName()` 時間加入統計的意義不大，真實應用往往是個別操作，特別在圖表的呈現
* [commit f561e](https://github.com/grapherd/phonebook-1/commit/f561efa41ca9546e87a8e883096bcf3e78c5b64f) 的 Git commit 訊息不需要特別指出檔名，而且不容易理解具體行為和影響，為何要作這樣的修改？
> phonebook_opt.[ch]: move out dict