這本書非常適合在寫程式寫到腦袋有點鈍掉，又不想停下來好好休息的人拿去咖啡廳坐著看一看。
我不知道大家 coding 到有點 co 不下去的時候會做些什麼事情，如果是我，就是在臺北東區亂走路，但又不至於走9遍忠孝東路，或是焦慮的喝著有咖啡因的液體...，沒有要幹嘛，但就是也不想睡覺休息 XD。常常我是邊走路邊想事情。
這本書，整體來說，並沒有什麼總結，只是很多人對於工程師的一些想法，不論思考, 做事的方式, coding 跟重構等等。
有些人的想法，看了會很有共鳴，你會覺得，好像我也是這樣做, 好像...我也是這樣想。有些人的想法，可能跟你互斥，不過都是別人的經驗，你可以汲取你認為好的，或是思考一下，不想做 plan A，那如果是你，你會有什麼樣的 Plan B，因為方法沒有一定，端看你的工作環境, coding 方式, 同事, 客戶等等。
蠻意外的共同點
- 有幾位專家認為增進 coding 的能力之一是共同參與別人的 open project，或是去看那些開源的專案的程式碼。
- 這點我自己承認我沒做好，因為我沒什麼耐心看別人的 code，除非是我很有興趣的專案，像是一些用 JavaScript 寫出來的效果等等... :P (還需要多培養....)
註解不是邪惡
- P.32 那篇是個很好的故事，簡單來說就是，作者在念大學的時候，老師出了一題算出平均值的程式，題目不難，作者得到了一個勉強的分數，但是老師在評分卷上寫著: 『沒有註解 ?』 。老師會這樣問的原因是，老師跟作者都知道這段程式碼目的是要做什麼 (因為已經知道題目了)，但是這樣還不夠，『程式碼必須可以對下一個的程式設計師解釋他自己』。
- 但是也不該過度註解，註解最好可以用來解釋程式無法解釋地清楚的地方 (可以跟『在程式碼無法表達之處註解』, P.34 做比較)
- 總是有機會會寫到很複雜的功能
- 『如果這東西很難寫，那麼也應該很難讀』，這句的意思為反意，要注意程式碼的可讀性 (update 2015-01-15，謝謝 洪象成)。
學習程式以外的語言
- 是的，這篇我很有體悟，尤其剛參加完英文講者蠻多的 JSDC 之後，要好好學英文...
程式碼的審查. P.28
- 這篇建議可以給會被 code review 的新人看看，我曾經有犯過這種錯，就是被別人 code review，但是我覺得那是對方的偏見，改了我的 code 有時候心情蠻差的。但我後來是蠻喜歡被 code review 的...，有時候就是這樣，當你很討厭被 code review 時，就一直有人會來 code review 你，當你想要有人幫你 review 時，卻很難有這樣的人 XDD 這機會很棒啊，如果有人要 code review，要心存感激啊 !
程式碼的審查不是用來指正新人的錯誤，而是分享知識，這個很重要。不要讓 code review 變得很嚴肅，如果公司能把 code review 變成一個快樂的點心跟下午茶時間，那會很不錯。
別在你的測試資料裝可愛. P.50
- 這篇非常有趣，因為真的很容易發生這樣的事情，簡單來說就是，多為你的客人著想 XDD，情境有點類似假如客戶提出了很奇怪的要求，然後你在 log 或是 alert 寫下一些情趣化的 log (ex: 別再按這個鈕了，沒有功能，你這白癡) 之類的話，或許工程師覺得好玩或是無心寫下，當做 debug 用的訊息而已，但是如果忘記拿掉，在客戶面前 demo 時，會給客戶留下很不好的印象，也會很尷尬 XDD
- 要這樣寫測試的 log 也要記得拿掉呀 XDDD
學會評估時程
- 這個是我覺得很難學的部分，因為一個需求，怎樣算完整，我又該怎麼估時間呢 ><，建議以後做一個功能自己記錄一下所花費的時間跟工作內容的細節。
- 不過這篇的重點不是要工程師給上級一個明確的時程，重要的是釐清需求是什麼, 評估目標跟如何達到自己的承諾。
有幾篇是在講重構跟 pattern，這個可能給有寫過比較大型或是 C++/Java 專案的人看的，我就比較難融入在其中。
P.45。最後，做大量審慎的練習，『達成專門技術最重要的元素，就是你花在進行審慎練習的時間，先天的資質不是主要的原因』。審慎地練習是一種學習，這學習會改變你，也會改變你的行為。這篇是很好的分享啊~ 我很喜歡 :)
我只有記錄幾篇我認為很印象深刻的，
再多說就破太多梗了，要給書商賺點 $$，
有興趣的捧油可以去書店翻翻這本書 :)
沒有留言:
張貼留言
若你看的文章，時間太久遠的問題就別問了，因為我應該也忘了... XD