Clean Code 這本書，正好適合寫作風格還沒定型的菜鳥一邊工作一邊慢慢看。原本不知要累積多少年經驗才能做出明確決斷的事情，從書本上系統性地吸收前人的思考以後，摸索的時間明顯縮短了許多。
這個月結束，人生中第一份 web front-end engineer 工作就做滿一年了。這段期間，每隔一陣子隨著任務變化，會跟公司要求一週不受打擾的技術研究時間，研究完馬上實做，實做完馬上寫心得筆記、跟高手求教、制訂下一階段的戰術，然後再度進入研究階段。幾個循環下來，深深覺得對技術進步幫助很大 😃
繼 React patterns 跟 JavaScript testing 之後，還有一項沒有特別安排時程、僅僅耗費每天在馬桶上的零碎時間，但卻讓我覺得非常有感的技術研究：讀 Clean Code。
過去曾讀過一本跟 Clean Code 有點像的書，叫做「病歷寫作」，都是在講述「特定領域的從業人員如何透過專業文件做有效溝通」，不是講技術，而是講前人曾經使用哪些工作方法來發揮這項技術、各自遇過什麼狀況、以及根據這些經驗得出的 best practice 是什麼。
當人類的認知系統遇上程式碼
讀 Clean Code 過程中，很有趣的是，許多程式寫作的原則，在非程式的寫作情境下也適用。比方說，第二章 naming 講到「聰明工程師跟專業工程師的主要差別在於，後者瞭解 clarity is king。」這原理，跟一般的文字寫作一樣，除了專業領域內部溝通的場合外，在文句中堆砌對讀者來說罕見的詞彙，也許可以裝神秘、裝聰明、或者避免被看懂，但真正專業的作者，會讓文字發揮它們原本的目的：傳遞資訊。
又比方說，第三章講到一個 function 只做一件事、只往下拆一層實做細節，然後使用它們的時候，程式碼讀起來應該像一串「現在為了要 OO 所以我做了 XX 跟 YY 跟 ZZ」這樣的句子。這聽起來，其實跟寫法律考試申論題的原則相同：分點分項分層次。或者說，任何給人類看的文件，都適用相同的認知法則，而程式碼也不例外。
此外，同樣是第三章提到的：function 盡量小、寬度跟高度盡量不超過一個螢幕、縮排盡量不超過兩層、抽象概念跟實做細節不混在同一頁... 等，跟做簡報「一個畫面一個概念、一頁不超過五點、一點不超過八個字、講稿不要打在上面」的原則也相同。其基本精神，就是配合人類的認知系統的特性，去設計最佳化的傳遞資訊的方式。
寫好讀的 code、寫好讀的文章、做好用的介面、設計有效的文宣，都是在「把資訊編碼成文字或圖像，以利其他人的認知系統解碼」。因此跟畫手術步驟圖一樣，過程中要不斷換穿上解碼者的鞋子、走個幾步、再換回來。至於實做技巧，則隨著人類的認知系統處理不同媒材的方式而異。
Developer Experience 該叫做 DX 嗎 XD
其實，目前為止才看到第三章，但也已經可以看出 Clean Code 這本書的敘事基調。總之，一開始會先講一般常見的、最直覺的寫法是什麼，接著是其他人在讀 code 的當下心裡想什麼、有哪些目的、需要哪些資訊；然後在這樣的情境下，原本的寫法會給他帶來什麼困擾；最後是怎樣做可以滿足他的需求、讓事情進行得更順利。
同樣的循環讀過幾次以後，不禁覺得：這根本是 UX 的書吧（欸
相較於產品設計的 user centered design，程式設計可能可以稱做 developer centered design 吧？developer except for me ... XD 現在如果有人要我用一句話總結 Clean Code 這本書，我大概會說：它是一本關於如何改善 developer experience 的書。
結語
寫程式到現在，嘗試了許多不同的 coding 風格，一直想找出其中的 best practice；而 Clean Code 這本書，正好適合寫作風格還沒定型的菜鳥一邊工作一邊慢慢看。原本不知要累積多少年經驗才能做出明確決斷的事情，從書本上系統性地吸收前人的思考以後，摸索的時間明顯縮短了許多。
對了，Clean Code 不能跳著看 XD 之前為了重構，搶先看了第二章，邊看邊記、努力想每個原則要怎麼套用到我的專案，搞得有點手忙腳亂。後來看完第一章的大概念以後，順著下來又看了一次第二章，發現每個觀點都是從第一章的概念推導出來，不用特別記憶，理所當然地就消化了。
沒有留言:
張貼留言