Image

昨天的轉貼有提到「正確」和「適合」這件事，決定轉貼一下前幾天滑到的推文：
和年轻朋友聊天的总结 (Part. 1) - Xiaowen

其中有一段我覺得很不錯：

同一個技術棧，在不同的行業，不同的場景里，可能有完全不同的工程形態，技術生態。

理解業務，才能讓自己橫向的去比較技術在行業里的不同，更立體的建立自己對技術的理解，未來真的需要你做技術選型，架構決策的時候，你的出發點才能是：「選擇最合適的技術」，而不是「選擇我最熟的技術」

因為我是個懶惰的人，因此在決定要怎麼解決某個需求的時候，很自然就會選擇已經熟悉慣用的方法

所以看到上面的『「選擇最合適的技術」，而不是「選擇我最熟的技術」』這句話，有種敲響警鈴的感覺

最近也漸漸學習到：除了這些技術上的問題以外，更多時候潛在的限制都是從業務需求而來的。

客戶能接受某兩個服務之間的資料同步有延遲嗎？大約能接受延遲多久之後資料才一致？

哪些功能查詢資料時一定要是即時的不然會有糾紛？哪些雖然流量高但是不即時更新也不會出事？

這些業務場景，其實都會影響到我們能夠選擇怎樣的實現方式來進行。同時，我們也不可能說只要採用什麼做法怎樣實現就每次都完美無缺

就像前一篇轉貼文章裡面寫的：「不同的團隊、不同的公司、不同的時空背景，同一個議題也可能會有不同的解答」

算是分享一點菜雞小心得。準備休假來去爽打一整天幻獸帕魯，耶嘿

延伸閱讀：[架構師的修練] #2, SLO - 如何確保服務水準? - 安德魯的部落格 > Case Study