先來提個 PR 來紀錄目前的進度，當成一個里程碑，可以去 github 上看看

最近工作上在整理 PR 互相的 feedback，趁這個機會跟大家分享在看程式碼的思維

需求跟程式碼可讀性的拉扯

有時候趕時間上大家的寫的程式碼很不好，那要請對方修正嗎？或者提交的需求要各種自己驗證嗎？每個人都會提交跟 review，不同的角色看的重點會不太一樣。

就我看到的案例，通常很趕的狀況下程式碼品質也相當不好，寫的倉促、看的也倉促。驗證全部都交由 QA 進行，或者直接上線交給市場驗證。後續發生什麼問題再說，往往這樣看下來，後續要再處理的成本相當的高，而且版本的迭代只會讓身處在專案中的工程師各種心累。

良好的 Code Review 也是需要人力跟時間去進行，並且團隊也能接受這樣的合作模式。工程師之間或是跟其他角色能夠有這樣的共識是更好的，而且彼此學習對方的長處，才能更加進步。所以開發時間就要來的更長一些，要保留需要 Review 來回的時間，才不會壓縮到後續的流程。

就我自己來說，重視可讀性。有些程式碼過一陣子回來看就不知道當初是發生什麼事了，通常提交過後，會再回來檢視的機會也不多，所以盡可能那這一次修改就能一次到位。

• 英文單字不要用可讀性低，或是少見的。例如確認就用 confirm，不要用 affirm
• 正向的判斷邏輯，不要 if (負向) else 正向這種的，負向判斷就是會再停頓一下，轉一下去想。這個斷點在某些時候會自我卡住
• 引用的物件或函式過長。舉例來說要取用的函式可能是物件.subFuction().checkNext().doSomething()，可能需要檢視程式碼，為什麼取用這個方法需要寫這麼多層
• 需求的驗證。就依提交的人所寫敘述，在看看邏輯層這邊有什麼異動會影響其他程式碼，或是是否有衍生的問題。

減少人工

如果團隊已經有一套 Coding Style 不妨加到 CI 的流程當中，若不符合預期就請提交的人自行處理。另外以 App 來說也可以拉下專案自行 build 看看 App 是否能夠執行。

舉例來說，只更新文案或錯字，需要整個程式碼拉下來嗎？如果 CI 已經跑過沒問題了，人眼對過文字就可以直接核准了。現實是大家都了解 CI 的好，但是實作這個流程是需要時間的，而且後續需要有人去做維護去做調整。

評論他人程式碼的原則

理性且針對事情，不要帶有私人情緒。前陣子看到開源程式碼在討論有些提交或是工程師們有些時候在詢問或是評論的心態其實能夠更正面的話，而非一直無謂的批評。在評論他人的程式碼也是，也許對方設計的方向是有這層考量，只是你自己沒想到這個做法。多一點的詢問，互相交流，也許可以替你開擴另一個天地。

另外在他人的程式碼留言，可以多用一些中性的文字去詢問，畢竟只讀文字，很難感受到對方的情緒。像是看到對方有邏輯不通順，或是情境很複雜，用請問這邊的設計有什麼考量嗎？寫一些虛擬碼來表達你的疑惑。會比你寫這種設計誰看得懂啊？更能讓人接受，想想如果換做是你是那個提交者，你比較喜歡看到哪種留言呢？

有感而發的一篇，如果大家有什麼好的 code review 方式，也歡迎交流分享 ：)