中文版初出的時候就在書店翻完了, 不過當下是很粗略的看完
當下的心得是, 這些我都知道啊, 真是屁話…
(網路上的英文版看的很辛苦…)

不過工作了幾年了…
再用不一樣的心情, 好好翻完之後
一樣的內容和書裡教導 “方法” 其實用度又大大不同了

無瑕的程式碼 這本書是網路上很多人推薦工程師、程式設計師必看的一本書
就簡單分享一些心得吧…

對象

雖然名為無瑕的程式碼, 不過只要和軟體開發、網路業有關的 “工作者” 都很適合看
你可以用不一樣的工作者角度去暸解裡面的故事, 裡面的做事方法(工程師, PM, 業務, 老闆… 都可以看看).

環境

書中作者 Bob 大叔常常會賣老, 舉出一些很老舊的開發故事, 書中常常會講到讀卡機, 磁機這樣的電腦設備, 執行 Hello World (註1)可能就需要 1分鐘 (我的天啊…)
不過我想他沒有惡意, 因為作者早在 1970 年就開始寫程式了, 約 17 歲
書中大量這樣的例子, 我認為他想表達的是, 早期的軟體開發環境非常辛苦.
速度慢, 不方便

(圖中的磁帶機儲存容易甚至不到1GB, 而且處理速度非常慢)

工作態度

態度狂妄, 自大的工程師.
工程師常常自以為是, 自以為聰明! (我也是一名工程師)
這樣的人, 不會有好的發展, 在書中作者曾多次被開除, 丟了工作
所有職業都一樣, 良好的工作態度、處事方式都一樣重要

現今的職場上常常有自大的工程師, 對著人說

 
這真的是非常糟糕…
麵包師父不會對著你罵你不懂麵包吧?
正確的態度應該是說明和講解…

好的工程師, 應該要用簡單的方式讓不懂人明白他的問題!
對方聽不懂, 是工程師的問題 (當然不是用程式碼說明給對方聽)
請(工程師)好好想想! 😀

這攸關，所謂的 “專業”

在書中常常提起, 正常的態度, 能讓人判斷你是否專業

說 “是” 與說 “不”

書中章節  – 承諾用語
在說明, 如何答應一個功能的完成
這章節在說明, 工程師最大的挑戰, 估時

不論, 是不是工程師應該都有經驗, 每當需要製作、開發 平台、軟體或是服務
很容易被問到, 什麼時候能做完? 要多久時間…
本來我認為, 估時隨便、 客戶需求天馬行空, 是台灣、亞洲人的通病
不過在書中看來, 應該是世界通病了(笑)

看起來, 無理取閙是客戶的常態, 當三週的工時, 突然被要求加入一個需要額外花費一周的新功能….
這樣的要求, 很耳熟吧?

(這類改規格的故事, 應該不少見吧)

當出現這樣的要求時, 你會怎麼回答?

“無可奈合的, 答應這樣無理的時程?”

或是回答一個不一定的答案

“有點困難, 但是我可以試試看”

或是充滿熱誠的說

“時間有點少, 但是我會努力試試”

或許你會想, 不夠的時間, 就利用自已的時間拼一下, 擠擠看
或是利用工程師時間(註2)試試看

書中提到, 或許你趕的出 “成果”
但他未必是好的東西, 在未來的日子你一定會遇上你製造的問題(bug)

Clean Code 無瑕的程式碼, 所指的就是一個正確、完整的開發流程
不用偷雞摸狗的方式完成事情
今天的偷懶, 幾乎都會成為明天的bug, issue

書中一直提到, 踏實完成, 遵守開發原則(書裡提倡 測試驅動開發TDD(註3), 萬事萬物由 Test 開始), 簡單來說例如 堅持模組化程式(copy, paste 重覆功能, 製作 Helper 或是 建立 Repository).

在估時，沒有 

這樣模陵兩可的答案
當然在台灣的情況就是, 老闆要有什麼就有什麼了 XD

但是展現專業的方向就是, 清楚告知, 硬將東西趕出來後的 壞處和風險 為何?
要在時程不延長的情況下, 加下突如其來的新功能, 可能會產生什麼樣的問題

例如說：
最初的客戶需求是…
一台交通工具
有四個出入口
四個輪子
在地上移動

在這樣的需求下, 我們可能就會製作一個引擎, 可以讓這個交通工具在地面上跑的引擎

假設總計耗時需4 週時間

第3週時, 客戶希望這個交通工具, 他同時也能飛天(…)
雖然為交通工具加上翅膀, 只需要花兩天時間
但是我們會向客戶要求延長至6週的時間(比原來4週多了2週)

當然…
客戶肯定不能接受本來只需要兩天的翅膀安裝時間, 為什麼工程師會說需要延長至2週呢?

在製作端, 考量到的除了翅膀的安裝,
我們還需要考量引擎馬力問題
目前交通工具的外型是否適合飛上天
飛上天之後是不是可以正常降落
種種可用性與安全性的問題

然而…
客戶永遠不在乎這些問題
他們只在乎付了錢(可能還沒付錢), 的成品, 能不能跑、能不能飛上天

最重要的是…
發生問題時, 是不是能隨時找到你!

這樣的心態, 你可以在很多電商網站上看見…
不安全的交易過程, 可以被修改的線上金額
都是 “不在乎” 心態下的產物

在書中, Clean Coder 所指的人, 就是指一個開發者能不能守住最後一條線!
夠不夠專業!
畢竟軟體或是產品, 最後出現了問題, 被追究責任的還是開發者.
書中多次寫到, 尊守原則, 強烈說 “不”

做為一個好的、專業的程式設計師(或是 PM)
都不應該輕易說 “是”

待續…

購書

書本身非常好買
博客萊
http://www.books.com.tw/products/0010598217

讀冊生活
http://www.taaze.tw/sing.html?pid=11100671260

天瓏書店還有同時兩本書合購優惠
http://www.tenlong.com.tw/items/9862017880?item_id=839920
http://www.tenlong.com.tw/items/PG-001?item_id=884070

註

Hello World

在程式語言裡常常被拿來說明、最基本, 最容易完成的一段程式
很簡單在畫面上輸出

PHP 裡的寫法:
echo "hello world";

Ruby:
puts "hello world"

Hello World 也被拿來指, 一個語言的範本或是基礎

但是不知曾幾何時變成, hello world 已經變成學會一種程式語言的代名詞
不少人, 只要曾寫過一段 hello world 就宣稱自己已經學會這個語言…

所以我都笑稱, 我也會 "Hello Word"

工程師時間

工程師說的的明天交給你
他的明天指的是, 從現在開始到明天你上班前的這段時間
也是他會拼了命利用晚上睡覺時間, 明天上班前把事情處理完

測試驅動開發 TDD

先寫測試, 再完成程式本體的 軟體開發方式
內容大概為, 我們需要一個頁面上顯示文字
平常的做法是, 做好了頁面, 打開測試看看是否有文字

而 TDD 則是, 先寫一段程式可以 檢查 是否有頁面, 頁面上是否有文字
再接著製作 頁面本身…

整體感覺就像, 先寫一段檢查程式, 檢查之後的程式本體正不正確

書中一直提倡並建議使用 TDD, 並花了一個章節說明他的好處
以現在的我, 完整的 TDD 還是有點困難…