dw's 小站

面試被問到的題目，雖然是很基本的題目，但相關延伸也有不少，寫篇文章記錄一下。

遞迴：最基本又直觀的解法

以前在 KK 實習時，跟 RD 們聊過自架 blog 的事情，並聽說了這個很潮的 .dev 網域，就把購買個人網域列為將來想嘗試的事之一。
找工作的事情告一段落了（其實也只是在原本實習的公司轉正職 XD），有了固定收入就可以來養個人品牌了 XD。

在今天之前，這個 blog 是用 Wercker 做自動化部署，當時對於 CI/CD 工具沒有太多比較，就直接使用了。

在 2018 年底，GitHub 公開了他們的自有 CI/CD 工具 GitHub Action，並於 2019 年底正式推出。這個工具經過了兩年多的發展，如今也有一定成熟度，社群有很多相關的工具發展起來，當然也不乏 Hugo 的自動化部署。如果 repo 使用 GitHub，那整合 GitHub 自家 CI/CD 當然是最方便的。

使用情境

在 Leetcode 寫到一題：

• 1319. Number of Operations to Make Network Connected

現在有 n 台電腦以及一些 cables 將電腦點對點連接，問需要移動至少幾條 cable 才能讓在所有電腦連成單一網路。
以 graph 的角度來看，電腦就是 nodes，cables 就是 edges。

要將整張 graph 連接起來，至少需要 n-1 個 edges。若一個 graph 裡面有超過 n-1 個 edges，剩下的就是多出來的 edges，可以供我們拿來移動的 edges。
所以第一件事就是要檢查 edges 數量 >= n-1。

當檢查完畢之後，我們有至少 n-1 條 edges，一定可以用這些 edges 將所有 nodes 連接起來。
因為題目只問需要移動幾條 edges，我們可以假設我們移動的都是多出來的 edges，不必去動原本的 n-1 個 edges。

假設原本的 graph 被切分成分離的 m 塊 connected components，則我們需要移動 m-1 個 edges 去連接，因此問題變成了找出目前有幾塊 connected components。

因為公司有這本書的中文版，在各種等待時間，慢慢把這本看完了，同時也一邊寫些自己認為的重點。

其實我覺得 Clean Code 適合的閱讀對象，是從來沒有接觸過任何 Coding Style 的人。

如果你跟我一樣，有和別人合作過，平常有遵守一些準則（例如 PEP8），或是使用包含 Styling 的 linter (pylint / eslint / rubocop …)，這本書還是能找到能學習的地方，例如命名原則、封裝的部分、模組的拆分、測試撰寫等等，這些開發準則以及自動化的 formatter 沒辦法告訴你的部分。

也難怪第一次聽到別人推薦大家看這本書的時候，把它歸類在「選讀」，卻又說裡面的內容很重要。因為很多觀念在現在已經是日常了。

比較後面的章節，從系統、平行化開始，討論了一些比較深入的知識，Java code 也開始變難懂了，而持續精鍊、JUnit 等章節，就真的是針對 Java 的實例做說明，而非原則介紹的部分，這些對我來說讀起來就比較吃力一點。而平常會聽到大家討論的，也都是前面章節討論一些基本原則的部分。因此對於時間比較少的人或許可以先點到為止。

我看網路上的心得也很少人真的讀完後面 XD

列舉一下我覺得比較重要的章節：

• Chp. 1 ~ Chp.10
• Chp. 12 簡單的總結
• Chp. 17 一個清單，其實包含了 Chp. 14-16 的一些啟發

我認為重要順序是倒著的，完全沒時間可以先看 Chp. 17

另外 Chp. 11 其實也蠻重要的，但是裡面太多 Java 的部分了，如果以後學 Java 再來細看吧。

大概是這樣，下面就附上我紀錄的每章節重點吧。

前言

Clean code 是一門學派，不是絕對正確

減少閱讀程式碼的時間

雜亂程式會拖累開發時間

讓程式清楚明白，不要隱藏意圖，避免 anti-pattern

童子軍規則：離開營地前，讓營地比使用前更乾淨

變數命名

• 類別：名詞，方法：動詞
• 避免無意義的字：the, variable, name
• 避免跟形態衝突的字（會誤導），除非他真的是那個形態：list, array
  • 或是省去：Accounts > AccountList
• 能搜尋
• 能唸出來
• 意義區別
  • e.g. source, destination 取代 a1, a2
• 同一概念統一字詞
• 在命名內加入 context，或是用 Class 包起來

善用詞性

類別：名詞
方法：動詞