看不懂程式碼，不是你的問題

老碼農-是資深同事，開發過公司重要專案。

菜碼農-是新進員工，對程式碼品質要求很高。

狀況劇1

老碼農: 我給你的程式碼，你看了嗎？
菜碼農: 我看了，但是看不懂耶！可以幫我解釋一下這一段嗎？？
老碼農: (心想: 功力真差！看這麼久還看不懂？！)

狀況劇2

菜碼農: 我寫了一段程式，你幫我看看，我這樣寫對不對
老碼農: 你這樣寫，不能說你不對啦！和過去公司碼農的寫法差太多了。
菜碼農: (就是之前的寫法有很多問題，才改寫的呀？！)

像這樣的對話，看得出誰出了問題嗎？

程式功力好與壞？

看不懂程式碼並不代表你寫程式的功力不好，寫程式的功力除了取決於對開發工具、除錯工具、版本控制工具的掌握度、debug的速度，還有取決於程式設計師的詮釋能力，也就是寫的程式碼是不是「好用」。

好用的程式碼是本書想討論的重點。除了《code complete》書中前半段提及的，利用技術增加程式碼的種種方法，也希望加上《The Design of Everyday Things》中歸納的原則來看待程式碼品質。

利用工業設計的評價原則，來評價程式設計師每天都要面對的設計作品: 程式碼，希望讓好的程式碼寫作，不會淪為「個人風格」而已，而是有一種客觀的依據，可以用專業的角度說服別人要使用這種好的寫法。

影響範圍

也許這種「個人風格」的寫作方式，無關程式碼運行，軟體開發公司往往不會太重視，「程式碼怎麼寫都會跑哇！為什麼一定要這樣寫呢？」，那「房子隨便蓋都可以住呀為什麼一定要住好房子呢？」，除了感受上的問題，當然還有其它的影響。

程式碼品質影響可讀性，影響程式設計師的熟悉程式碼的速度，更影開發速度，也影響交貨時程，也影響debug的速度，對客訴回饋的反應速度。

提高程式碼品質，雖然會提高開發成本，也會提高程式碼品質與降低潛藏bug的數量。

還是看不懂程式碼，那會是哪裡出了問題？

除了上述的狀況，當然看不懂程式碼除了是程式設計師的問題，還有要問問自己的英文是不是不好。XDDD