從需求出發理解背後技術的思考脈胳

最近在技術上多了不少體悟，關鍵是要掌握住問題的需求，接著不斷思考和嘗試，避免卡在特定的規則或工具裡，將重心放在隱藏在這些東西背後的核心思想。

直接看現有的工具或別人的作法很難有所體會，但自己從頭邊做邊想，會得出自己一套理論, 接著會出乎意料地更快理解這些工具和作法。畢竟在足夠嚴苛的需求下，方法可能有些差異，背後的精神卻是類似的。

比方說，若程式反應速度要求在 1ms 以內，全部資料來源都得在記憶體或網路，不能使用硬碟。那麼，針對這種應用，單機程式能做的事只有將東西塞在記憶體裡取用。

然而記憶體有限，資料總有放不進去的時候。在這種速度要求且資料過大的前提下，可能的作法大概是：

• 像 cache 那般有套機制留住最常用的資料。
• 在記憶體裡存 index，index 內存必要的資料，若需要更多資料再從硬碟讀。
• 先做前處理「壓縮」資料成摘要，摘要必須小到可以放入記憶體內。資料的品質(正確性)也許會有一些損失，但是是必要的取捨。之前在讀 YouTube 關聯影片和 IBM 的 Watson 論文時，有看到類似的思路，工作上也做過類似的事。和前述方法不同的地方是，資料的筆數變少，轉為另一種高質量的資料。

再以 Test Driven Development 為例，最重要的不是 TDD 的三步規則，也不是相關工具要怎麼用，而是導入「在設計的開頭, 就將測試視為主要考慮項目」，其它東西都是這個想法的衍生。

從這個角度出發，實作久了自然會理解為什麼介面要開洞放入物件，為什麼需要 factory 隔離生成和操作邏輯。至於是否真的有先寫測試，現在我覺得不是鐵則，在有為測試而考慮的設計下，在必要時補測試可能更划算，將時間花在刀口上。但若一開始沒為測試考慮，事後要補就很辛苦，加測試的價值又更低了。

再往上拉一個層次來看，解決問題的前提，本來就是如何確認問題有被解決，若無法確認問題有無被解決，用什麼方法也是白搭，不知成效如何。從這個角度來看，在設計之初就考慮測試，並不是什麼新穎或強人所難的事。但要走到這步，如同學其它東西一般，需要累積不少經驗。

總結來說，要學習一個技術最好的方法，就是在有適當的需求時再學。平時看到和自己需求無關的知識，加減有個印象在腦裡即可。待要用到時可利用腦裡的索引找出相關資訊，先有個廣泛認知。接著根據自己的需求可以明白那些是比較相關的知識，邊看邊動手做些雛型試試。有了這些操作經驗和背景知識後，再從頭確認一次自己真正的需求為何、有那些限制和對應解法，就能理解要如何應用這些技術和工具到自己的情況裡。