不知道為什麼我吃完早餐就寫了這個。
越簡單越好
要設想你在5年後打開專案時也知道這是什麼東西。
要設想你哪天喝醉酒或是被車撞了但臨時要改bug也知道要去哪裡改。
好的程式應該是簡單而能夠長久陪伴著你的，就像愛情一樣。
遍地都是註記
註記很好，不需要太多規矩，有註記本身就很好。
不是每次都能在良好的狀態下載入所有context來了解程式。
註記很好，哪怕只是LAMO之類的隻字片語，也能在某天有所幫助，或起碼博君一笑。
註記很好，任何形式的註記都很好，就像愛情一樣。
測試、測試、還是他媽的測試
沒有測試，那每次改動都是一種無形的壓力。
如果這是你自己的產品，關乎你銀行帳戶裡的數字，你就會想寫測試了。
在AI時代，我認為測試其實是可以「Generative Driven」的，不過這個之後再談
測試很好，任何形式的測試都很好，就像愛情一樣。
再說一次，越簡單越好
因為很重要所以我要說第二次。
我覺得很多人都搞錯一件事，那就是好的架構師其實是盡量不畫架構圖的。
他們設定的是凝練後的原則以及思考模式，架構圖是基於此的副產物。
如果你需要畫出雄偉壯麗的架構圖來解釋你的架構，那我覺得挺失敗的。
不過愛情需要好好解釋，這不太一樣。
模組化就是全部
是的，模組化就是全部。
模組化代表清楚的封裝，可測試性，去耦合，可替換性。
站在組織或商業的角度看，這代表生產力，可預測性，可流通性，以及組織彈性。
模組化其實就是種商品化。
如果你的軟體是由資本驅動，而不是浪漫的新詩集，那模組化就是必然的走向。就像愛情一樣。
可以說，VTuber是種模組化的愛情
把對的東西、在對的時間、放在對的地方
對，大概就是這樣。
火箭科學或生物工程之類的另當別論，在Application Development方面，這大概就是所有你要掌握的事。
把對的東西、在對的時間、放在對的地方，就會得到好的結果。
就像愛情一樣。
他媽的不要有例外
我喜歡彈性，但某些核心而堅定的原則是不可以有例外的。
例外就像水壩的小裂縫，乍看之下沒什麼，但會越來越擴散，最後毀了一切。就像你跟你的前任一樣。
自動化啦，哪次不自動化的
可以自動化的東西在一開始就自動化。
要習慣寫一些有的沒的script，不管事複製貼上或是讓AI生成髒兮兮的都無彷，重點是減輕心智負擔。
任何需要操作的事情都需要消耗能量，請把能量留給有意義的事情。
例如愛情。
最後一次，越簡單越好
簡單的定義在於「低理解負擔」。
就算你是孤傲的一匹狼，也有狀況低落的時候。你要確保你的代碼無時無刻都是無負擔的。
少了負擔，你才能把時間花在其他事情上面。
不要在程式碼中展現個性或個人癖好，平凡如水的程式碼才是最棒的。
簡單是智慧的終極形式，
就像愛情一樣。