昨天講 Clean Code，雖然昨天只聚焦在命名與註解，僅佔 Clean Code 這本書的冰山一角，不過也算是可以一窺什麼叫做「更好的程式碼」，有興趣的人非常建議買來整本書看完。
今天要從另外一個角度切入，「更好的程式碼」會由誰寫出來呢？
工程師
不不不，不是工程師，而是
更好的工程師
((拖走
今天來講 Clean Code 的番外篇 - The Clean Coder。
這本書在講的，不是優質的程式碼，而是聚焦在 developer 本人，要做些什麼，或者抱持什麼樣的心態，才能產出優質的程式碼。
今天我會根據其中幾個章節，拋出幾個主題跟大家聊聊，並且會結合我個人職場上的實際經驗，也歡迎大家分享囉！
玩過一款很有年代的遊戲叫做「魔塔」，玩法非常單純，就是地圖上會有一些怪物，同時也會有一些增加角色的 buff 及過關用的鑰匙，目的很簡單，就是打敗怪物、拿到鑰匙，不斷往魔塔的更高層前進！
這款遊戲有個特色是「特別需要計算」：因為主角不是龍傲天，不可能一路橫掃千軍，但有趣的是怪物的攻擊力、防守力、血量等資訊都會明確告訴你，完全可以自行衡量，要先從哪一個怪物開始交戰！
所以這款遊戲並不是：
打怪、打怪、打怪、撿寶、通關！
而是
打怪、撿寶、打怪、撿寶、打怪、撿寶、通關！
必須要不斷計算：
同時也代表了需要不斷去「分配」角色的血量，要是沒分配好就只能看著寶藏流口水。
我們一天的工作也是如此，在不加班的前提下，一個人的工作時間、專注力都是有限的，處處在分配，你有發現嗎？
然而，在遊戲中算得很精準，在工作上卻不一定有辦法保持清楚。一天工作 8 小時，多少時間分配給開會？多少時間給寫 code？A 任務跟 B 任務的順序誰先誰後？
工作上曾經看過的狀況們，要嘛分配順序不對，要嘛分配了但沒有認真看待，甚至還有帶著品質很差的 8 小時過來的：
其中特別強調一點是，同時間手上有很多 ticket 待完成，很容易就會基於一種「想要趕快減少 ticket 數量」的心理，挑那種比較簡單的 ticket 優先。
但事實上，無論是在開發或維護，比較難的 ticket 反而才有優先的價值，因為通常「難」，就代表要考慮的東西「多」，所以漏掉一些細節的可能性也「大」，原本估 3 天，可能最後變 5 天。
甚至即便 PM 已經安排好 ticket 順序了，如果沒有照著順序完成，其實就是一種自我麻醉罷了，整體進度彷彿有前進，但事實上是，重要的事情還是容易踩到 deadline。
假如真的都按照 PM 安排的 ticket 順序了，還可以做點什麼呢？
好好安排自己的專注力！你有以下經驗嗎：
面對自己覺得沒有意義的會議，除非真的就是有那種大你好幾階的老大要出來講話，不然其實，你應該自己找到會議的意義。
務必弄清楚會議的主題是什麼，每個主題最多花多長時間，要取得什麼成果。如果上述這些都做了，還是覺得沒意義，那應該在合適的時機，禮貌地離席(沒想過這個答案吧XD)。
而像聽歌這種，每個人工作習慣不同，像我就很常一首歌從早上聽到下班，或者就是很有目標性地搜尋我要的歌，找到之後就回去工作，不會在挑歌、找歌花太多時間。
專注力是稀缺資源，即便有些人認為：「我就花個 10 分鐘看一下 MV 就回來了啊！」，但更多時候，原本一連串高效率的工作心流狀態(flow zone)，就被這 10 分鐘打斷了。
唉小學國中的時候都不喜歡午睡，現在巴不得每天睡爆！
這一點見仁見智，有人喜歡滑手機休息，有人喜歡看 Youtube 休息，沒有一定要午睡。
只是如果明知道自己下午就是會昏沉想睡，卻仍沒有利用各種方式讓自己補充體力，其實就是變相降低自己的工作產出。
對你的薪水負責
「專業」兩個字聽起來很硬，好像就是要學很多開發技巧啦，或者資結演算的效率啦，環境佈署建置之類的，應該就是要累積很多實戰經驗！
但很容易就會產生一個疑惑，要實戰也得先練兵吧！？難道寫程式寫一寫，會突然學會環境佈署嗎？
因此書中提出一個很重要的點，作者認為，一個專業人士每週除了投入 40 小時的正常工時，還會多投入 20 小時在充實自己。
40 小時的正常工時，是把時間賣給公司，用來解決公司的問題。
而 20 小時的額外時間，則是把時間留給自己，用來投資技術實力，或者任何能夠提升專業價值的事情。
算了一下會發現，等於每天要再抽出大約 3 小時來充實自己，其實聽起來是滿不平衡的，對於有家庭、有生活要顧的人來說，其實是有點天方夜譚。
因此書中也有說，不是一定要認真坐在電腦面前才叫充實自己，通勤時間 podcast，回家之後讀書，假日參加研討會等，都是在提升自己的專業價值。
這我自己加的XD
如果真的就是一個很會 coding 的人，真的這樣就能夠稱為專業人士嗎？
起碼我目前的工作經驗，還沒有遇過那種「技術非常硬，硬到軟不下來(?)」的類型，畢竟這種類型的人可能也不太能夠在公司內不被黑掉。
軟實力不是身為一個 developer 的必備條件，卻是身為一個 team player 的必要條件。
只要在公司內，就免不了跟人溝通：
尤其技術實力愈強的人，通常愈會接觸到高級班、極限班的人，因此會有很多額外的技能衍生出來：估時、承諾、驗收等，我們留著之後討論。
不是幫忙訂便當那種忙
在同事卡關的時候，是不是願意主動跳出來協助，即便自己可能也不知道怎麼解決，但起碼，可以 call help 啊XD
技術實力不強的人，反而很需要跟其它同事打好關係，知道每個同事擅長哪個領域、模組，一方面可以知道卡關要找誰救，另一方面別人卡關可以推薦找誰救。
俗稱「帶新人」，如果已經靠自己的專業硬實力闖出一片天，那應該很有機會主導一個專案，也會需要帶領其它 developer 一起前進。
這時，如何與「實力跟自己有落差」的人合作，其實是另外一個困難的課題。
因為通常用硬實力爬到一個位置的人，很容易將事情攬在自己身上，導致新人成長不了，自己又累垮的慘況。
如何切割專案任務，將部分任務交給新人，甚至讓出部分舞台，其實是一件需要學習的事情。
今天主要把焦點放在我們 developer 身上，其實看起來很多都像是在聽道理，知道歸知道，卻只有實際做了才知道，自己究竟是如何在公司「工作」。
對於 ticket、deadline 如何執行，對於溝通、團隊又抱持什麼態度，往往需要實際的職場經驗才看得出來，因此我想，現在看這篇文章的讀者，除了會有共鳴以外，應該也思考了很多之前沒考慮過的細節。
寫著寫著
在黑幕裡的異國文字
學著學著
在黑幕外的真實人生
iThome鐵人賽
看影片追技術