Clean Code Craving

Code 可讀性低又到處重複的話，經常導致 bugs 不斷發生。一旦我們用 git blame 發現是同事幾年前寫的 code，就會想說為什麼這麼醜? 但如果是自己寫的，就...沒辦法啦，以前不知道在想什麼亂寫的。真的可以這樣想嗎? 沒辦法寫出 Good Code 的阻力 要怎麼寫出好的 code? 有些原則我們都可能聽過:  KISS , DRY , YAGNI , SOLID , 甚至是 CRISP ，一定還有一大堆我沒列出來的原則，這些都是不錯的 building box，但是老是有一些現實因素干擾著我們: 時間緊迫 隔天就要 release 的程式，user 今天臨時才發現一個很嚴重的 bug 要修。但仔細一看其實是簡單的小錯誤，但又發現要改的 code 剛好可以 refactor 達到 DRY，我們會怎麼做? 當然要 DRY，於是改了大概一百行程式碼 還是改發生錯誤的那一行就好，避免 refactor 又製造不可預期的 bug 但其實這並不是二分法，大多時候我們會評估時間還有程式碼的複雜度。有可能折衷一下： refactor 20 行信心高的 code，發個新 issue 等到下次 release 再去 refactor 剩下的 80 行 code。 不熟悉 寫程式的怎麼會不熟悉? 但一個大型 project 通常都是分工的，我們如果剛好是新進員工，或是剛踏進同事負責的領域，周圍一定圍繞著我們不熟悉的程式碼，這時我們也不敢大刀闊斧地更改同事已經寫好的程式碼。 有時候更慘，寫這段 code 的人已經離開公司，或剛好休長假，但目前要做的 issue 就剛好需要你改同事的程式碼，這時候我們可能只會追求 correctness，把其他 principles 全部拋於腦後，寫出醜到爆的程式碼，但至少功能正確。 Legacy code 也常常是我們都不熟悉的範圍，甚至是當初寫這段 code 的同事也早就忘記他當初為何這樣寫了。 太複雜 當 issue 非常複雜，牽扯到一些困難的 algorithm，但已經有明訂的 design spec 的時候，實作時才發覺是不是另外一種寫法比較好，但如果發生問題我們就很難清楚地知道到底是 design spec 有問題，還是因為我們自作聰明亂改? 與其給自己找麻煩，還不如就乖乖照著 spec 走。 當可以寫 Good Code 的時

有些再簡單不過的指令像是 mv, cp, rm 遇到檔案一多的時候有時候可以跑好幾分鐘，甚至一小時以上。我也不曉得他什麼時候會跑完，30 秒? 10 分鐘? 2小時? 都有可能。 手邊也暫時沒其他工作可以平行進行的話，也只能放著讓他跑。 但時不時就會好奇他跑完了沒，一直來回切換視窗，或是去忙別的事卻一直跑回房間看螢幕。這時候我們就會很想要讓他跑完時通知我們。 Sequential Commands 最簡單的方法就是與其執行一個指令，不如執行 multiple commands，讓前面指令跑完就跑通知用的指令，我們這邊以 sleep 當作一個跑很久的指令： sleep 10; notify_me 要注意的是這裡最好用 ; 把指令串起來，最好不要用 &&，因為 && 一定要前面的指令成功 (return zero exit code)，後面的指令才會執行，我們最好別太把握前面的指令跑到一半一定會不會發生錯誤。 通知的媒介 至於通知的指令要用哪種方式，我就有試過以下的方式： 播放聲音通知 在 VNC 視窗傳送通知到 VNC 桌面 (e.g., notify-send) 用第三方工具傳送通知 (e.g., Slack, Teams) 寄送 email 通知 但實際用過之後才發現一些缺點。聲音很容易因為人不在房間就沒聽到；VNC 視窗傳送就限制你只能在 VNC 視窗跑指令，而且人沒盯著螢幕也很容易錯過；第三方工具看起來最棒，但有時因為第三方工具或網路不穩就是會沒送到通知。 寄信+手機 app 還是最可靠 最可靠的還是透過簡單的指令像是 mail, sendmail, mutt 等工具來寄信。不過 IT 要先設定好信箱，但公司通常都會有。 於是我們就可以在 .bashrc 寫一個 function，例如我們可以使用 mutt 來當作寄信的工具: # Send an email with only the subject # # Examples: # mail2me # mail2me "Command finished" function mail2me() { local -r subject="$1" mutt -s "${subject}" &quo