根本難題：品質與截止期限

程式設計的領域中，總是會遇到工期的壓縮，許多時候我們並沒有時間來一場工程師的浪漫，反覆斟酌程式的品質。
可是若真屈服於時程而放棄品質，那便是我的不專業了。

......想想如果你是一位醫生，然後有一位病患要求你不要像傻子般在手術前洗淨雙手，因為洗手會花太多時間？......但是醫生完全應該拒絕遵守這種需求，為什麼呢？因為醫生比病患知道更多關於疾病與感染的風險，如果醫生屈服於病患的要求，那就顯得太不專業了。

這說的可真好，如果我們相信自己的價值與專業，就應該確實展現專業的風範。

然而這段文字其實並沒有真的說服我，現實是如此骨感。當整個專案截止期限壓力來時，我終究不是大師，大概無法鐵骨錚錚的堅守。
如此一來，撰寫一些爛程式碼似乎是無法避免的

嗎？

你製造了爛的程式並不會因此趕上截止日期，事實上，爛程式只會馬上讓你的開發速度變得更慢，並導致你錯過截止日期。在截止日期前完成工作的唯一方法 ── 讓開發速度變快的唯一方法 ── 就是隨時隨地，都確保程式碼盡可能的整齊潔淨。

對我這個才是答案，如此有感。
回想過去，只要開發時間超過一個月或不是自己撰寫的程式碼，有太多的時間都耗費在閱讀散亂的依賴，或是尋找及避免忽隱忽現的臭蟲。
開發的進度，往往沒有因為隨便而加速，反倒拖累了進度。

更重要的是，寫到想罵髒話。
讓我們再複習一次這段話：

唯一有效的程式品質度量單位：每分鐘罵髒話的次數(WTFs/minute)

什麼是 Clean Code

書中蒐羅了七位程式界的先驅(含作者本身)對於 clean code 的論述，我很概略的彙整為下面的三項要點：

• 意圖明確：
  意圖明確隱含了程式碼容易被閱讀及理解、變數命名及功能有被明確定義、單一的意圖、能充分表達系統設計的構思、具有最少數量的實體(entities)、看到的程式被執行後與自己所預想的差不多。

• 通過測試：
  令我意外的是，他們非常在乎程式是否有通過測試，換句話說，
  沒有經過測試的程式碼，就稱不上是 clean code。
  對於我這種不太會寫測試的人，這實在是一種巨大的挑戰。當然，我本也沒奢望自己能在撰寫 clean code 的路上一蹴而就。
  或許該是找一本關於測試驅動開發 (TDD) 的書來好好啃一啃的時候了。

• 其他：
  優化效能、被悉心照料、優雅......諸如此類我個人覺得不需特別說明的特點。
  然而值得一說的是，作者描述 clean code 時，非常強調細節，這是我先前完全沒料到的。

在開始之前

沒有任何一個學派是絕對正確的。然而，身在某個門派時，這些傳授技法就是正確的。

程式界擁有駭客思維的眾多程式設計師們，永遠不會停止探討更好的做法，永遠不會停止向更美好的世界前進。
這使我們不停進步，同時也使我們不停批判。
該書裡必定存在具有爭議性的建議，但在閱讀本書的同時，我將以此書的想法為最高準則去思考及嘗試，是以不管認同與否我都不會與之爭辯(其實以我目前的水準也沒有爭辯的能力......)。

我期待作者的原則與風格能帶來極大的成長與啟發，而這也正是我閱讀的原因。那麼，如果我們對程式品質有了一些基礎的共識，明天就來開始學習具體且細節的原則吧！