程式碼要清的多乾淨?

昨天看到 fcamel 分享的一篇PTT 文章 ，主要是談該不該順手 clean code。 在發表一些看法 之後，fcamel 又在今早發表一篇文章說明他的看法。 大致上，我的個人的意見和 fcamel 的文章是一致的，原本昨晚想要寫一篇說明， 但因故作罷。 但今早看到 fcamel 的文章之後，覺的看法雖然一致，有些點我還有一些更細 部的想法。

我摘錄 fcamel 提到的幾個點

「依個人以及團隊的能力，看看能提昇多少品質」 「在體認到個人能力不同、習慣不同的前提下，對自己的要求是盡量 提高自己的能力，多付出時間提高品質」 這些看法是和我一致的。 而 PTT 上的文章，則是認為不要做太多，其潛藏的前提是， 自己的能力無法撐握的面面具到，因此，必需停止手癢去改有潛在問題， 但目前還沒爆出來的程式碼，以避免造成更多的錯誤。 換句話說，PTT 的文章認為，必需極力避免犯錯，這樣而造成的錯誤是不可接受的。 我則不認同。

適度的試誤是必要的。 以王建民的首局症為例，(我不是那麼懂，我是依據報紙上的說法)為了怕首局分失， 而投的邊邊角角，反而搶不到好球數，更加陷自己於失分的危機。 也就是說，容忍適度的錯誤才是健康的心態。 況且，適度的犯錯，是進步必經的途徑。

如 fcamel 說的「問題在於，何謂 must have、何謂 nice to have，每個人的見解不同。爭議點在於，每個人的能力不同，導致評估 的實作成本不同。」 除了能力不同之外，個人的膽量、積極態度和價值觀也同樣影嚮著評估的差異。 我強調的是，積極態度和個人的能力呈正相關。 若一個人總是消極的避免錯誤，就沒有試誤，能力自然也不會獲得重大的 進步。 更甚者，往後在評估 nice to have 時，會因能力的限制，而比別人更加保守， 並更加限制能力的進步，落入惡性的循環。

對於 fcamel 的文章，我主要想補充的是，要評估自己的能力，並適度的承受犯錯的 風險。 你必需瞭解自己的能力狀況，並適時的冒一些風險，去修改別人的 code。 一開始，先挑一些挑戰較小的部位，以確定自己能力是否能勝任。 在幾次測試之後，確定能掌握某個層級的問題後，再次提昇挑戰層次。 如此漸次的測試和試誤，能力不斷的提昇，產生正向的循環。 但，多大的風險才算可接受的? 有人膽大，有人膽小，每人不同。 最好依照案子的重要性，決定試誤的範圍。

另外，對於風險的評估，往往會被過度的誇大。 首先，沒有人不會犯錯的，就算再精明的人，再好的專案管理，任何一個專案裡 都會有錯誤。 不要相信有不能犯錯的專案，因為這樣的專案根本無法結案，沒人能 保證他的案子沒有錯誤，而順利結案。 任何專案都有可承受的錯誤規模，問題在於這案子能承受何種規模的風險? 更細一點，某個模組能承受的規模有多大。 你必需問自己這些問題，才能做正確的評估。

在 PTT 的文章裡提到， 「你有時間好好的把所有你改到的code 用到的地方都測過一次嗎？」 基本上，這不是一個問題。 首先，如果你是因為遇到某些 bug 進而發現其它問題，並順手進行修改。 那麼，這份 code 本就就要進行重新的測試，特別這份 code 是這麼重要。 不論你改了多少，都是需要測試。 因此，沒時間測試的理由是不存在的。 如果該 bug 是緊急狀況，你當然有足夠的理由先 workaround，先解除狀況。 但事後一定得回頭來 clean。

再者，在非緊急狀況下進行的 refactor，則應該設定有限度範圍，以免發生 改不完的 bug。 但這不是說，不能有 bug，而是如果 bug 量太多，會造成時間上的不允許。 因此，在這種情況下，也不會有測試時間的問題。 因為你並不是在緊急狀況下，可以依據擁有的時間，決定部位和規模。

很多人會以「大型、重要的專案」、「風險很大」、「出問題誰要負責」作為 理由，試圖說服你不要去修改責任外的 code，或作為得過且過的藉口。 但醒醒吧! 世上大部分的專案都沒那麼重要，你總不會把建造太空梭那一套用在你的小專案上吧。 再者，就算建造太空梭，都有所謂的「風險控管」，把風險控制在一定的、可接受的 範圍，而不是沒有任何風險。 (如果 NASA 依靠的是不會犯錯的員工，那肯定永遠昇不了空) 況且，修改也不是隻有一種方式。 你可以依據自己的能力和資源，決定部位和範圍。 因此，問題在於能力、方法、部位和範圍，而不是「可」或「不可」。 別被那些消極的想法給嚇唬了。 開始當個積極而快樂的 programmer 吧!

註: 對於那些自以為無所不能，不按部就班提昇自己，並沒理由的自我感覺良好者， 則不在鼓勵之列。