「你過去做的這些模型，有實際落地嗎？」
# 前言
這應該是許多新手資料科學工作者，在轉職面試時，都被問過的問題。不外乎地，在分工體系明確、或者有友善的 IT 前輩照應的公司當中，菜鳥資料科學家們的確可以只專注在資料與模型上。但隨著職場閱歷漸長，我們 莫名理所當然地 被期望要會更多東西、懂更多技能、能做更多事情。尤其在這個人人都可以用生成式 AI 來建立模型的年代。
是故，為了生存，我們不得不跳脫舒適圈，開始學習如何自己刻前端、串後端、讓系統自動跑起來、還要有能力規劃整個系統方案架構。職場專業的分水嶺差不多就從這裡開始，們開始親身感受，一位「資料科學家」和「能做出系統的開發者」，到底差在哪裡？
是故，為了生存，我們不得不跳脫舒適圈，開始學習如何自己刻前端、串後端、讓系統自動跑起來、還要有能力規劃整個系統方案架構。職場專業的分水嶺差不多就從這裡開始，們開始親身感受，一位「資料科學家」和「能做出系統的開發者」，到底差在哪裡？
#「會寫程式」和「會做系統」是兩回事
我們姑且先不談「程式碼品質」與「設計模式」這些奢侈的玩意。「會寫程式」和「會做系統」的差異，並非只在技術層面，更多是在思維模式。
在資料科學的訓練環境裡，姑且不論應用領域，只要你的模型在生產環境/線上環境當中也能夠跑出好棒棒的結果，使用者與老闆讚譽有加，恭喜你就算成功了！👍
但對於系統開發而言，我們得看得更多更廣更深更遠……
系統是否在所有預期的輸入條件下都能正確回應？
在非預期的輸入條件下是否能優雅地失敗？
在流量高峰時是否能維持可接受的回應時間？
在需要更新時是否能不中斷服務？
在出錯時是否能讓維護人員快速定位問題？
系統是否在所有預期的輸入條件下都能正確回應？
在非預期的輸入條件下是否能優雅地失敗？
在流量高峰時是否能維持可接受的回應時間？
在需要更新時是否能不中斷服務？
在出錯時是否能讓維護人員快速定位問題？
你不先去解決問題，問題就會來解決你（O）
有些資料科學家可能幸福一點，不必煩腦上面這些問題，但之所以我在這篇文章當中提到了，就是因為我是要面對的那一個 XD
# 那些厲害的工程師在想什麼？
這個系統的邊界在哪裡？它應該負責什麼，不應該負責什麼？
資料從哪裡來，要去哪裡？哪些上下游系統有介接？
輸入的資料是誰提供的，格式是什麼，品質有沒有保障？
輸出的結果要寫到哪裡，誰會讀它？
這個系統的使用者是誰，他們的技術能力如何？
他們能接受多複雜的操作流程？
他們看到錯誤訊息的時候，需要看到什麼才知道怎麼辦？
這個系統需要多可靠？
如果它停機一個小時，業務損失是什麼等級的？
這決定了你要花多少力氣在高可用性（High Availability）的設計上。
這些問題，在「資料科學家思維」裡幾乎是隱形的。資料科學家習慣從「我有什麼資料，我能做什麼分析」出發，但一名資深的開發人員、或者系統架構師，會從「這個系統要服務誰，在什麼情境下，達成什麼目的」出發。而一個想要做出有用的資料科學應用系統的人，就必須兩種都懂。
# 全新系列連載？
凡事總要起個頭，那就從這一篇文章開始，淺談我自己從一個以 Python 為啟發工具的資料科學家，在試圖轉型為能夠設計並實作企業級系統的開發架構師時，需要在思維上和技術上經歷哪些具體的轉變？
To be continued
# 一點參考