Sept. 05 17:25~18:45
離上次感冒痊癒才不過一個禮拜,前幾天又再度感冒。腦袋空空的只好在家裡讀一些不花腦筋的書。把出版社贈送的《The Clean Coder》中文版拿出來看,剛剛把書看完,順便寫一篇blog介紹一下。
這本書只有200頁多一點點,比起400多頁的《Clean Code》足足少了一半。本書一言以蔽之,就是作者Bob大叔提醒後輩們要如何做一位「專業人士」的經驗之談。書中很多建議做法都跟目前主流的敏捷開發方法互相呼應,也有少數幾項建議讀了可能會讓人吃驚,因為跟大家普遍的認知有所出入。
***
挑幾項Teddy覺得比較有意思的內容跟鄉民們分享。首先介紹作者認為專案軟體開發人員至少必須精通的事項:
- Design patterns:可以描述GoF的23個設計模式,必且對於POSA書中所介紹的許多模式都有實務上的使用經驗。在這裡置入性行銷一下,要學design pattern有課程可以教你,請參考「第五梯次Design Patterns這樣學就會了」。
- Design principles:SOLID原則,也就是Single responsibility principle、Open-closed principle、Liskov substitution principle、Interface segregation principle、Dependency inversion principle。
- Methods:XP、Scrum、Lean、Kanban、Waterfall、Structured Analysis、Structured Design。 要學Scrum一樣有課程可以教你,請參考「第七梯次Scrum敏捷方法實作班」。
- Disciplines:TDD、Object-Oriented Design、Structured Programming、Continuous Integration、Pair Programming。
- Artifacts:UML、DFD、Structure Chart、Petri Net、State Transition Diagram and Table、Flow Chart、Decision Table。
鄉民們可以自行盤點一下,看看自己離Bob大叔心目中的「專業軟體開發人員」還差多少東西要學。
另外Bob大叔還建議:
- 行就是行,不行就是不行,不要說「試看看」。
- 要幫助他人,遇到問題時也要主動請別人幫忙,這樣才是專業人士的態度。
- 心中覺得焦慮的時候不要寫程式。
- 不開沒有意義的會議。
- 要採用pair programming、TDD、CI、collective ownership些這敏捷實務做法。
- 要利用機會多作練習,養成練習的習慣。
***
接下來談兩點Teddy覺得很有趣且可能跟一般人認知有差距的建議。
每周工作40 + 20小時
疑,敏捷開發不是說每周工作40小時嗎,怎麼Bob大叔要我們加班20小時?根據書中的說法,每周還是「替老闆工作」40小時,但後面的20小時是為自己工作。也就是每周要安排20小時作為提升職業能力,例如看書、練習、學新技術或程式語言、參C. C. Agile聚會、看搞笑談軟工部落格等。
Teddy覺得這個建議非常的棒,因為以前Teddy建議鄉民們每周工作40小時,但是並沒有提到自我學習的時間。很多鄉民還真的是非常聽話,每周「只」工作40小時,如果公司沒有安排任何的教育訓練,則員工們的工作技能就成長得很慢,甚至停滯不前。Bob大叔認為雇主並沒有義務要讓你(員工)的履歷表變得更好看,如果遇到好的老闆那真的很幸運,但是專業人員應該要投資時間在自己的職業發展上面,不能光是靠別人來「餵食」。
不要進入Flow Zone
中文版的書把「flow zone」翻譯成「流態區」,也有些人用「神馳」來稱呼這種狀態。之前有朋友跟Teddy討論過這個問題,因為有些書上建議開發人員應該不要被中斷,以便於進入「神馳狀態」。在這種狀態之下,生產效率極高,但只要工作環境無法讓人保持專心,就無法進入神馳狀態。所以有些人反對敏捷開發的工作環境,認為應該為開發人員配置專屬的私人辦公室以防被打擾。
相信所有的程式設計師都經歷過「神馳狀態」,享受著雙手不斷敲擊鍵盤的那種快感。但是Bob大叔卻建議大家:「不要進入flow zone」。因為在此狀態下只是處於一種「淺層冥想」,開發人員並沒有顧及全域,很可能會作出一些日後不得不打掉重練的程式。
Bob大叔極力提倡pair programming,因為在此情況下雙方都不會進入flow zone(除非有人睡著了)。
***
這本書很容易閱讀,對於有志成為專業開發人員的鄉民們,可以一窺大師的做事態度。
***
友藏內心獨白:有看有保佑。
以下兩點在台灣職場未必適用!
回覆刪除1. 行就是行,不行就是不行,不要說「試看看」。
專案執行過程,常會有一些需求來的突然且有技術難度,客戶或主管總要技術人員試看看,且在討論時即會問是否可行? 這時候真的只能回答試看看! 因為回答行,結果卻不行時,會很釘的很慘! 一開始就回答不行,也會被認為工作態度或服務態度不佳。
2. 要幫助他人,遇到問題時也要主動請別人幫忙,這樣才是專業人士的態度。
曾遇過一個主管,只要看到有同事請教別人問題,就覺得這個同事的能力肯定有問題! 所以,整個資訊團隊養成一個習慣,寧可讓專案延遲,也不願請教別人!
Hi 史帝芬,
刪除我完全能夠理解您所敘述的狀況,在書中作者也有討論到類似的情況。以第一點來說,「專業人士」可以回答「我需要N天來評估才能告訴你答案」,這樣子會比「我試試看」要來的好。因為如果你回答了「我試試看」,你心中預設的結果可能是「試了之後可行或不可行」,但是對方(你的老闆或客戶)對於「我試試看」這句話的解讀通常就是「好,你會想辦法試出一個可行的方案出來」。這樣子雙方認知不同,很多誤會與不愉快就會產生。
至於第二點,算是一種不好的風氣。因為專案要順利,絕對不是「一個人很強」或是「自己的進度很好」,而是整個團隊都要跟上腳步。我知道現實狀況可能無法做到,但這就是作者想要傳達的理念:「專業人士」vs. 「不那麼專業的人士」的差別。
讚~這見解不錯。
刪除每週20小時的自我提升~
回覆刪除若扣掉六、日的話,那平均一天需要兩小時自我提升時間,還真是拚
不然Bob大叔怎麼可以成為「大師」呢 XD。
刪除作者在書中有提到,可以利用通勤或中午的時間來自我提昇。現在行動裝置那麼便利,利用瑣碎的時間積少成多要達到也不是不可能啊。
每週20小時的自我提升
回覆刪除扣掉六、日的話,那平均一天應該是四小時吧?