###### tags: `約耳趣談軟體`
# 11. 「每天重新構建」是你的好朋友
### 前言
+ 作者在 1982 年買了一台 IBM-PC，成本大約 1 萬美元，寫了一個 hello world，進行編譯，花了 8 分鐘
+ 後來寫了一個黑白棋程式編譯超久，等待期間都在做雜事
+ 有一天突然橫空出世跑出一個 Turbo Pascal，不到一秒時間就把程式編譯完成
+ 從中悟出 REP loop
+ 讀取、計算、印出 (Read, Eval, Print, REP)
+ 輸入、處理、輸出 (IPO)
+ 編輯、編譯、測試
+ 程式開發就是不斷的「編輯、編譯、測試」，接下來的編譯器開發者也是竭盡所能的想加快這循環
+ 當你進到更大的團隊時，顆粒度變大了，從人變成團隊。
「編輯、編譯、測試」變成了「問題報告、問題修復、重新測試」，但一樣要辦法加快這循環

### 每天重新構建
1. 自動：cron 固定時間編譯
2. 每天：連續構建，但可能卡在程式碼控制
3. 完整：多語言、多作業系統、高低階版本皆須重新構建
### 優點
1. QA 可以取得最新版本，確認程式是否穩定
2. 開發者更有安全感，確保隨時可以出貨 (上 Production)
3. 闖禍的人如果忘記把檔案 commit 上去而造成錯誤，可以提早揭露錯誤
4. 讓市場行銷、測試版客戶網站先試用穩定版本
5. 可以把每天重新構建結果保存起來，配合良好版控找到從哪裡開始錯的
6. 承5，可以了解 QA 回報在哪個版本出問題，以及追蹤到何時修復

+ 有一台專門構建的機器，將每天構件成功結果放到專屬目錄
+ 放到今天就是 runner, docker image version

### 小提醒
+ 構建過程應有腳本完成，而不是在某個人「腦裡」
+ 放到今天就是 CI/CD script 與 pipeline
+ 發現問題時，直接進去 VM/Pod 裡面改是最糟的，請從源頭程式碼改
+ 編譯器設成最高級別，有警告就停下來
+ 重新構建出問題，先把一切停下出直到問題修復
+ 構建失敗，應立即通知修復，通知可以放錯誤 log
+ 作者團隊中，誰搞壞了就要當構建值日生，直到下一位搞壞的人出現 (現在不需要了)
+ ~~午餐時間是個不錯的構建時間~~
+ ~~如果跨時區...~~

# 12. 堅定除錯、解決問題
### 前言
==Question: 當軟體有問題時（效能問題、改善空間），你會去解決它嗎？==

+ 請確定出問題時你很快就會知道
+ 擷取 error log 的使用者行為並通知
+ 擷取事發現場錯誤畫面及 log 日誌
+ 每一通 support 電話都視為出問題的證據

+ 請確定你可以在經濟上得到回報
+ 把技術支援的成本算到相關事業部門上，事業部門就開始要求前 10 大問題列表
+ 原本會向尋求 support 的客戶收錢，但這不合理 XD
+ support 免費時，若問題太多也會吃掉利潤

+ 搞清楚對你來說那些問題值得全部修好
+ support 成本
+ 解決問題成本
+ 改善後能多賣幾套? 賣貴一點?

## 討論
1. 俗話說：「沒有監控、沒辦法衡量成效的功能都不算上線」，請問你們都用什麼工具或流程去監控、通知及衡量？
2. 「解決問題的成本太高、價值太低，因而放到現在都沒解決」，舉個你印象最深的例子