B05: introspect
預期目標
作業要求
開發紀錄(phonebook) / github ::: Reviewed by <jserv
>
中間的空白不要漏掉了,在 )
, /
, :::
之間都有。並且你的 GitHub 帳號名稱前後要標註 "`"
- 每份開發成果至多只能被 3 個人批評,"Reviewed by" 後面的 GitHub 帳號用逗號
,
分隔
- 選定開發紀錄後,編輯內文,加上
Reviewed by 你的GitHub帳號名稱
的段落,示範的 Review,你的意見要寫在共筆的最上方,僅次於 "contributed by"。要從以下方面探討:
- 程式碼的 coding style, git commit messages
- 實驗設計的不足處、涵蓋程度是否全面,以及後續的改進空間
- 建議引入新的方法,如 memory pool,來縮減
append()
的時間成本,當然,你自己要先嘗試成功過
- 回覆原本在共筆中的疑惑
- 斟酌在選定的 GitHub repository 留下 code review 意見
- 截止日期:
Git commit messages
- 詳閱 How to Write a Git Commit Message
- 好的 commit messages 的 7 個規則:
- Separate subject from body with a blank line
標題與內文以一個空白行分隔,這樣可在使用 $ git log
閱讀時較易區分標題
- Limit the subject line to 50 characters
標題字數最多 50。因為標題字數超過 50 在 github 上會被隱藏到 …
裡面,需要額外點開才能完整知道這個 commit 在做什麼。並且超過 50 字可能就不是一個精簡的標題
- Capitalize the subject line
標題首字大寫
- Do not end the subject line with a period
標題結尾不要句點
- Use the imperative mood in the subject line
標題用命令口吻
- Wrap the body at 72 characters
內文一行字數不超過 72
這樣在 $ git log
裡面看會比較清楚,排版比較好看
- Use the body to explain what and why vs. how
內文說明是什麼、為什麼而不是如何做。因為看 commit 的人是想知道你為什麼要做這件事,而不是要知道你如何做這件事的 (動機比細節更重要)
- 檢視同學們的程式碼,提出他們撰寫的訊息是否符合前述原則。如果不符合,就直接寫在 Review 內容中
- 沒有嘗試不同的 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 的 Git commit 訊息不需要特別指出檔名,而且不容易理解具體行為和影響,為何要作這樣的修改?
phonebook_opt.[ch]: move out dict