技術架構閒聊:站在巨人的肩膀上
在做軟體技術的過程中,常常會遇到「未知」的問題,例如某個商業邏輯很複雜,因此寫了很長一段程式碼來處理,既複雜又容易出錯。或是需要作一個新的功能,需要從零開始寫程式,進行的過程中可能會遇到未知的狀況,是一個風險。
不過,在我自己的經驗中,通常真正未知的問題的比例低於10%。大部分的問題,在這個世界中都有人遇到過。所以當遇到問題時,我首先會在網路上搜尋、找人詢問、或是到 Github 上找類似功能的程式碼,通常這樣可以解決 80% 以上的問題。
有些問題特別複雜,在網路上找不到,但這就表示沒有人碰過嗎?其實,複雜的問題通常是複合型的問題。這種問題需要先跳脫問題本身,從問題的本質著手來解決。
還記得十幾年前,遇到一個問題是我印象非常深刻的:當時公司的主要服務正在進行改版,開發的時候並沒有遇到問題,但作壓力測試的時候發現效能非常差。原本一台伺服器能夠服務的使用者數量,新的程式需要10台伺服器才能勉強提供服務。伺服器的CPU很忙,但後端資料庫負載並不高。新舊程式都是PHP,商業邏輯差不多,但舊程式沒有用PHP框架。
用搜尋關鍵字查了很久,包含框架的論壇和 Stackoverflow 都查遍了,都沒有人遇到類似的問題。當時是用 FreeBSD 作業系統,在它的論壇上也沒有人有遇到過。甚至還有老外覺得這一定是硬體問題,建議我們去查查看是不是有硬體故障的狀況。
不過因為這個問題不是只有在某些伺服器上出現,而是全部測試用的伺服器都發生,所以我們一開始就排除了硬體問題,從軟體的角度下手。後來真的找不到原因,所以我們跳脫了問題本身,從效能的本質來檢視。資訊科系的必修,計算機組織和作業系統告訴我們,保護模式下分為 Kernel Space(作業系統核心運行)與 User Space(應用程式運行)兩部分,所以當發生效能問題時,可以先確認CPU花時間在哪個地方。
經過分析,發現CPU的時間花在Kernel Space比較多,繼續深入後發現是CPU常常會在User/Kernel之間切換,這樣 context-switch 造成 CPU 過於忙碌。於是用這個關鍵字去查,發現網路上已經有人遇到類似的問題,也提出解決方案。於是我們嘗試了一下,一下子就把這個困擾我們幾周的問題解決了。
這個經驗讓我以後遇到問題的時候,第一個想法會是「這個問題應該有人遇過」。若直接的關鍵字查詢沒結果,我會利用之前所經歷過、學習過的方法,嘗試將這個問題拆解成小問題,然後再分別擊破。
「站在巨人的肩膀上」是牛頓的名言,在軟體開發的領域,無論是解問題或滿足需求,若從問題或需求的本質出發,都能找到前人用過的方法來初步嘗試。大致滿足後,再來微調與客製化,無論是效率或品質,一定比從頭開始造輪子來的好。
本電子報固定每週會出刊一篇文章。如果你對技術管理也有興趣,歡迎按下面的按鈕來訂閱喔!
如果你有興趣跟我聊聊關於技術管理,可以加入我的 LINE@。