2019 回顧

2019 下半年同事離職又找不到人，工作始終處於滿檔的狀態，blog 就放著很久沒有更新...

本來要寫一篇跟網路相關的東西，但寫出來大概就會被同事認出來，而且產品也從大家原本不看好的狀態到順利出貨，所以讓老闆認為洩漏商業機密就不好了。

其實原來我也沒有那麼懂

去年老闆約我吃飯時說我對網路怎麼那麼懂...其實我到這裡上班前也是一般般，老讀者就知道，我買了 STM32 實驗板，人家放假出去玩，我在家裡日夜苦練。工作上碰到瓶頸假日就把書拿出來 K，K 一次不懂就 K 兩次，人家放假我來公司加班，某日深夜剛好靈感來了，拖拖拉拉幾個月的問題一次解決。

廠商給的鳥 lib 不好用怎麼辦?反組譯研究組合語言抓到原廠 bug，原廠就是硬要用浮點數，但IC不支援怎麼辦?運用 open source 工具，把 lib 的函數導到我的函數裡，硬是把原廠不願意提供的資訊挖出來。原廠的記憶體管理有 bug 怎麼辦?攔截對方的記憶體管理函數，然後替換成我自己的版本，這樣也順利結案...我是來當 RD 還是來當 hacker!?好在最後也順利結案。

年輕時可能會覺得是靠自己的實力上位，現在我必須說要謝的人太多了(尤其是 Yukuan 兄，在我中年求職碰壁時給予極大的幫助，各位如果有 AI 的案子可以找他)，有很大的運氣成份，如果不是同事不想幹了，我應該還是個普通小員工，沒有想過當主管這件事，也沒有想過發大財，薪水還可以，家人可以溫飽就知足了。

不過想起在 xx4 被挑剔個半死，來這邊反而被當成人才，還是覺得蠻諷刺的，也讓我想起前老闆的名言「你要當小池塘裡的大魚？還是大海裡的小魚？」，不過筆者也不好意思說自己是大魚，至少在食物鏈裡不是最下層了，噗

每個人都該學一點統計與 Excel

公司對於教育訓練的態度講好聽一點是放牛吃草，講難聽一點大概是練蠱吧?反正你作不出來就會因為壓力自行離職，再找新人繼續操到產品做出來為止。

這種情況下免不了就會土法煉鋼，甚至高層也傾向這麼做，例如把鏡頭黏在車屁股，然後載著我到市區、郊區晃一圈，看到出圖卡頓就把車停下來，然後我趴在行李箱裡改 code。

這樣被折磨了數次之後，也沒有真的讓產品可以順利出貨。那最後怎麼解決的?

首先我回頭研讀教科書，弄清楚那些底層知識，我還記得 TCP/IP Illustrated: The Protocols關於 TCP 的章節我至少讀了 2-3 次。 ARM System Developer's Guide 關於 cache 的章節我也讀了 2 次。Wi-Fi 門檻對我比較高，但我也想辦法弄到從科普到專業的各種教材，能讀懂多少算多少。

然後我用 iperf 打封包確定頻寬跟理論值沒有相差太遠，並且注意到一項重要事實，通訊程式很容易累積誤差，如果 user 看到的影像跟實際情況差了數秒這種產品沒有人想買。

很快我就發現，我在學校學到的那些傳統 rule-based algorithm 對這個問題沒有什麼幫助。這其中的挑戰是：

• 要如何確認是真的環境變差(例如真的在白天市區內)，還是偶發性的干擾?
• 如何確認自己的修改是有效的?

先補充一點，我要怎麼知道 iperf 打封包的結果符合預期?因為這是 Wi-Fi 並不是 Ethernet，辦公室總是有各種干擾，測試出來的頻寬會上上下下，我知道有人馬上會說你應該在shielding room 測試，很抱歉公司不要說 shielding room 連 shielding box 都沒有，那我總不能跟老闆說你先蓋一間 shielding room 不然我不幹了(不過後來找了折衷的辦法-地下停車場)。

退而求其次的作法，就是用統計的方法，確認數據是否大部分落在某個合理範圍內，筆者只好從最基本的統計開始學起，接著用 Excel 跑出標準差，確認數據符合常態分佈(雖然理論上可能不是最適合的機率分佈)。

回到要如何確認環境變差，好在小弟認識 ChamberPlus 大師多年，聽過 first order filter，照貓畫虎搞了一陣子，效果居然也真的出來了。

最後一項也是最痛苦的，你要怎麼知道你的修改是有效的? 在環境變差時降低資料量，並且是平滑的改變?最笨的方式就是盯著螢幕，反正出圖卡頓就是沒改好，筆者年紀大了，這種搞法恐怕產品還沒出貨就先得到白內障還是青光眼。

然後我又想起 Excel 這個好東西，我把數據灌到 Excel 畫出折線圖、直方圖，馬上就知道自己修改的成果如何，數據是集中還是分散?有沒有把資料量限制到頻寬極限的某個百分比以下?再配合分割再測量的基本統計觀念，確認自己的修改是往對的方向走，終於順利結案。

還有一招是用統計中的相關係數加以分析，如果修改真的有效，那應該是正相關或者負相關，經此一役讓筆者深覺統計真是太重要了，難怪高中數學會把統計放入教材(不過筆者當年唸的是技職，完全忽略這部份)。

Excel 甚至可以分析 RTOS 下軟體的效率瓶頸與 bug，這個有空以後再說吧。

下面提幾本看似風馬牛不相及，但在黑暗中摸索的開發過程中點亮了幾盞燈

這本書講統計預測犯罪的章節給了不少靈感

這本暢銷書賣得很好，不知道有多人是跟風，還是跟我一樣真的從中受益呢?裡面關於網路的章節讓頗受啟發

 只要有人搞什麼CS領域10大推薦名著，這本書常常是榜上常客，不愧是前人豹死留皮的精華，書中提到的 Little's Law 讓我重新審視最簡單的 FIFO，這個簡單的資料結構大多數人都會，但要從 FIFO 中分析出系統效能就需要功夫了

年輕時折磨你的身體，年老時你的身體折磨你

費曼的彩虹：物理大師的最後24堂課這本書裡費曼提過：「以前年輕時只要喜歡的食物我就會拼命吃，直到自己不舒服為止，我再也不會這麼做了」

這兩年有時 bug 沒解出來，時間一久就會忘了吃飯，結果太晚吃或錯過一餐下一餐吃太多身體就出狀況了(很巧的是剛好大多發生在公司聚餐後)

筆者除了用自身的例子建議大家少熬夜多運動， 另外一個感觸是難怪很多公司不想用中年人，這種工作強度大概也只有年輕人受得了，當然也不一定年輕人就沒事，10 幾年前筆者認識的幾位高手當時就生病走了，目前的公司也有高手前輩因病去世。

最近就常常在想，如果知道自己剩下的人生不多了，還會這麼執著於這些技術的東西嗎?這些前輩有的放下工作與病魔對抗，有的仍然不放棄工作還做出成果造福後人。如果是我會選擇哪一條路呢?