如果有人要求你改善系統
身為工程師，不時會接到要求改善系統。 這個反應太慢，那個吃太多 memory，那那個又用太多電.....等等。 很多人，大部分人的第一個反應是「A 方案可能有效，試試看」。 一些簡單的問題或許直接這麼做就可以，但如果問題是手機耗太多電這種廣泛的問題， 那又該怎麼辨?
我個人建議依據下列幾個步驟，才能真正的解決問題。
- 建立測試報告，瞭解現在的實況為何?
- 依第一步的成果，檢查並比較(如果有比較對象)問題是否存在，並設立改善目標。
- 尋找並測試解決方案，並和步驟一的結果比較。
- 實作、改善前一步驟的成果。
大多數 developer 和 PM，都喜歡直接跳到步驟四。 但往往走錯方向，或在解決一個不存在的問題。 這每一步都很重要，少了任何一步，都會讓你浪費很多時間。
步驟一的目的是要建立比較標準，例如，在進行某一動作時的記憶體使用量。 有了這個明確、完整的報告，才能有明確的起跑點，知道離終點(或起點)有多遠。 不沒有比較標準時，就像瞎子摸象，不知道自己到哪了。
步驟二，確認問題是否存在。 有時 PM、partner 或客戶丟過來的問題，可能只是感覺或錯覺，不一定是事實。 以步驟一的結果當成參考，我們可以分析問題，確認否真的存在。 並且瞭解目前的缺失，以設定實際而有效的改善目標和方向。
步驟三，則是快速測試各種可能的改善方案。 經過前一步驟，我們會得到許多想法。 這些想法需要實驗測試過才知道是否有效。 此一步驟的實驗、測試並不需要完整的實作，以最快速，甚至是最髒的方法， 驗證所有可能的方案。 透過和步驟一的成果作比較，我們能明確的知道改善是否有效，離目標有多遠， 是否還需要更多方案或更有效的方案。 此步驟之後，基本上已經知道工期有多少，或是在工期結束時，能達到什麼效果。
步驟四，則是實作在前一步驟證明有效的方案。 步驟三的 code 可能有一堆 hard code 或一些 assumption，這些都必需重新 實作過，才能真正的成為 production 的 code。 步驟三的 code 務必用最快的方式進行，如果 gdb 裡面可能可以用 script workaround。 或是，寫一段獨立的 code 比較和之前的演算法差異有多少。 驗證有效之後，才在第四步驟實作和最佳化。
以上是個人進行改善計劃的流程。 鑑於許多人根本是沒章法的橫衝直撞，因此寫下此篇。
