B05 Review的重要

心裡的想法如果不記下來，會有遺忘的風險；但是記下來的想法，保證是對的嗎？同時也保證其他人知道你的想法嗎？

維護沒有設計文件與註解的系統時，曾經遇到幾個看來不難的問題，那時依自己的判斷加以修改，測試後也都沒有問題。但是過了一段時間，以前參與設計的人看到就說，那些問題不應該修改在那裡而是在別的地方。設計的想法沒有同步就會有作法不一致的問題產生。

在我帶幾個人開發系統時，工作分派下去之後每天上下午各抽出半個小時討論，內容是簡單說明自己如何做出功能的想法。說明的同時，所有人會針對不明白的地方提問並要求再解釋；如果作法不順暢的時候，也經由問答間找出更好的想法與作法。經由這個方式，所有成員都清楚知道別人想做的事項與要使用的方法，往後工作產生問題時所有人都可以快速地互相支援。在固定定期review的期間主管還抱怨我們怎麼開會這麼頻繁呢。

review的確需要所有人額外花時間投入，但是可以得到想法正確性的驗證、所有成員瞭解全部工作事項、確認記錄文件的正確性與完整性。在規畫與設計時及早發現問題予以修正，會比實際做到一半才發現不對勁要去修改來得快速且影響較小。如果你曾遇過開發到中途才發現嚴重的問題，必須修改大半原來想法之類的經驗，那麼你應該會接受多花一些review的時間來減低未來的錯誤發生機率。

revieｗ的內容，以需求階段、架構設計、細部設計的文字文件與UML文件為主，最好是全部的設計文件都進行。