原生優先

在寫自訂程式碼做某件事之前，先確認平台本身是不是已經能做到。這不是風格上的偏好。它會影響你的建置執行起來要花多少成本、搬遷時有多安全，以及日後別人要看懂它有多容易。

一句話說完這個概念

如果有人能夠指出一項功能，並把它說成是平台的一個特色，那麼這項功能幾乎可以肯定早已內建在平台裡。自己用自訂程式碼重做一次，會把它的運作方式藏進一段得有人去讀才看得懂的程式碼裡，往往隨著平台演進而愈用愈過時，而且很常到頭來需要一個內建做法根本用不到的登入憑證。

平台開箱即有的典型功能

這類平台本身就內建了大量現成功能：讀寫結構化紀錄、透過常見管道寄送電子郵件與聊天訊息、行事曆、試算表、檔案儲存、處理送入的文件、暫停流程等待人來處理、由一個流程呼叫另一個流程、在流程中做路由與迴圈，以及乾淨地停止一次執行。與各帳號及其他系統的連線，存放在平台自己的連線儲存區裡——只需設定一次，由建置參照使用，絕不會寫進建置自己的邏輯裡。

在寫下第一行自訂程式碼之前，值得先查一查平台目前的功能清單，看看有沒有現成的做法已經能完成這件事。新功能經常上線，最安全的預設做法永遠是先查再建。

什麼時候真的有理由用自訂程式碼

以下兩件事必須同時成立：

沒有任何內建功能能完成這件事，而且你能具體說出自己查過什麼、為什麼那樣做不夠。
這段程式碼是純粹的——它只針對拿到的數值做運算，本身不會拿著自己的憑證去呼叫其他系統。如果它真的需要連到其他系統，也是透過平台自己的其中一個連線去做，而不是靠寫死在程式碼裡的金鑰。

任何偏離原生優先原則的例外，都應該明白寫下來：考慮過什麼、為什麼沒有採用，以及未來要滿足什麼條件才能撤除這段自訂程式碼。把這樣的例外當成一筆暫時、有名有姓的技術債來看待，而不是一個悄悄變成永久的選擇——一旦平台推出對應的內建做法，就立刻撤除它。

為什麼這件事比聽起來還重要

建置裡永遠不該存放任何憑證。 一個只使用平台自身連線的建置，裡面不會有任何登入資訊、API 金鑰，或任何同類的東西。這代表這個建置本身可以安全地分享、匯出，或搬到另一個帳號——裡面沒有任何東西需要輪替、遮蔽，或讓人擔心。
使用內建功能建置出來的東西，非工程背景的人也讀得懂。 他們可以打開它，一步一步看清楚每個部分在做什麼，完全不必打開任何程式碼。自訂程式碼則會把這一切藏在一道只有工程師才讀得懂的牆後面。
它經得起搬遷。 把一個用內建功能組成的建置匯出到另一個帳號，完全不需要重新接線。一個把憑證寫死在裡面的建置，搬過去就會壞掉，更糟的情況是，它會悄悄用錯的帳號權限繼續運作，卻不動聲色。像 Gmail 這類使用服務商登入的連線，是由有權限的人針對每個帳號各自授權一次；郵件伺服器（SMTP）連線則是用伺服器的詳細資訊設定一次即可。

好的樣子是什麼

這個建置在平台自己的畫面裡可以一步一步讀下去，不必打開任何程式碼就看得懂。
在建置邏輯裡搜尋任何看起來像憑證的東西，什麼都找不到。
如果有任何一段自訂程式碼，都附有一則說明，寫出考慮過哪一項內建功能、為什麼它不夠用。
把這個建置搬到另一個帳號，它的行為完全不會變。

一個實際範例

以一個報價代理人為例：寄出完成的文件完全不需要任何自訂程式碼——讀取紀錄、依狀態路由、格式化日期、寄出郵件、更新紀錄，這些步驟全部都是內建的。核准步驟的做法也一樣，用一個內建的任務，暫停流程直到有人做出決定，接著自動接續下去，把文件寄出。自訂程式碼通常只會用在少數幾件事上：運算本身、一次資料庫查詢、最後的驗證檢查，以及文件本身的版面配置。