如果有人要求你改善系統

身為工程師,不時會接到要求改善系統。 這個反應太慢,那個吃太多 memory,那那個又用太多電.....等等。 很多人,大部分人的第一個反應是「A 方案可能有效,試試看」。 一些簡單的問題或許直接這麼做就可以,但如果問題是手機耗太多電這種廣泛的問題, 那又該怎麼辨?

我個人建議依據下列幾個步驟,才能真正的解決問題。

  • 建立測試報告,瞭解現在的實況為何?
  • 依第一步的成果,檢查並比較(如果有比較對象)問題是否存在,並設立改善目標。
  • 尋找並測試解決方案,並和步驟一的結果比較。
  • 實作、改善前一步驟的成果。

大多數 developer 和 PM,都喜歡直接跳到步驟四。 但往往走錯方向,或在解決一個不存在的問題。 這每一步都很重要,少了任何一步,都會讓你浪費很多時間。

步驟一的目的是要建立比較標準,例如,在進行某一動作時的記憶體使用量。 有了這個明確、完整的報告,才能有明確的起跑點,知道離終點(或起點)有多遠。 不沒有比較標準時,就像瞎子摸象,不知道自己到哪了。

步驟二,確認問題是否存在。 有時 PM、partner 或客戶丟過來的問題,可能只是感覺或錯覺,不一定是事實。 以步驟一的結果當成參考,我們可以分析問題,確認否真的存在。 並且瞭解目前的缺失,以設定實際而有效的改善目標和方向。

步驟三,則是快速測試各種可能的改善方案。 經過前一步驟,我們會得到許多想法。 這些想法需要實驗測試過才知道是否有效。 此一步驟的實驗、測試並不需要完整的實作,以最快速,甚至是最髒的方法, 驗證所有可能的方案。 透過和步驟一的成果作比較,我們能明確的知道改善是否有效,離目標有多遠, 是否還需要更多方案或更有效的方案。 此步驟之後,基本上已經知道工期有多少,或是在工期結束時,能達到什麼效果。

步驟四,則是實作在前一步驟證明有效的方案。 步驟三的 code 可能有一堆 hard code 或一些 assumption,這些都必需重新 實作過,才能真正的成為 production 的 code。 步驟三的 code 務必用最快的方式進行,如果 gdb 裡面可能可以用 script workaround。 或是,寫一段獨立的 code 比較和之前的演算法差異有多少。 驗證有效之後,才在第四步驟實作和最佳化。

以上是個人進行改善計劃的流程。 鑑於許多人根本是沒章法的橫衝直撞,因此寫下此篇。