🔧 阿川の電商水電行
把程式碼全部丟給 AI，但自己對內部一無所知的日子令人不安
你是否也有這樣的感受？
針對這些情況，我想藉由我在現場的經驗和一些失敗談，分享幾個抓住技術「本質」而非「表面」，從而加速成長的提示。
-
不要忽視電腦的「內部」
剛成為工程師時，我拼命想做到「把任務做完」。雖然會查怎麼寫程式碼，但對更底層到底發生了什麼，一點概念都沒有。
神秘當機與「五大裝置」
有一次我寫了一個要一次處理大量資料的程式。在本地環境可以運作，部署到正式環境後系統卻陷入沉寂。前輩問我「有考慮記憶體的配置嗎？」我當場當機。
電腦主要由下列五種角色的裝置構成（概念上可分為）：
- 控制裝置／運算裝置（CPU）：電腦的「心臟」，負責執行指令與運算。
- 記憶裝置（記憶體、儲存裝置）：暫時保存資料的記憶體，以及永久儲存的 HDD/SSD 等。
- 輸入裝置：鍵盤、滑鼠、各種感測器等。
- 輸出裝置：顯示器、印表機等。
這些透過作業系統（Operating System, OS）這個基本軟體，來仲介硬體與應用程式。那時候我完全沒有意識到，程式會消耗「記憶體（有限資源）」這件事。
「了解電腦的運作原理」，等同於擁有一張能推測故障原因的地圖——這點讓我印象深刻。
-
了解開發的「流程」。程式撰寫只是生命週期的一部分
成為工程師後才發現，寫程式的時間只是整個開發流程的一小部分。系統開發有一套標準流程，稱為生命週期（ライフサイクル）。
- 系統企劃與需求定義：明確為了什麼目的，以及系統應該具備哪些功能。
- 設計：包含使用者會看到的畫面設計（外部設計），以及程式內部結構的設計（內部設計）。
- 實作（程式撰寫）：依照設計書實際撰寫程式碼。
- 測試：透過單元測試、整合測試、系統測試等，確認沒有錯誤且符合需求。
- 導入與維護：將完成的系統上線運行，並持續修正錯誤或新增功能。
現代的開發方法：敏捷與 DevOps
近年來，以短週期反覆開發與釋出、快速應對變化的敏捷開發（Agile）為主流；同時開發（Development）與營運（Operations）緊密連結、快速交付價值的 DevOps 觀念也被重視。
如果只看實作（程式撰寫）階段，後續工程會很辛苦
剛開始沒經驗的我，只關心在「實作（程式撰寫）」階段讓眼前的程式能運作。但程式不是寫完就結束的。
在開發中的程式碼審查（Code Review）需要向夥伴傳達程式的意圖，釋出後的維護則會由未來的自己或其他維護者來修改，程式碼是「永遠有人會讀」的前提下撰寫的。
把可讀性擱置一旁的程式碼會為周遭的人帶來麻煩。來看例子。
Before：只有原作者看得懂的程式碼
這種寫法是「暫時能跑就好」，對審查者或未來維護者等缺乏考量。
javascript
// 直接用 1 或 2，乍看無法知道代表什麼
// 在審查時會引發問題，之後修改也容易造成錯誤
function getPrice(p, t) {
if (t === 1) {
return p * 0.8;
} else if (t === 2) {
return p * 0.5;
} else {
return p;
}
}After：意圖明確，對閱讀者友善的程式碼
讓審查者一讀就懂，且在維護階段也能安全修改的寫法。
javascript
/**
* 根據使用者等級計算折扣後價格
* @param {number} basePrice - 原價
* @param {string} userRank - 使用者等級（REGULAR, VIP, GOLD）
*/
const USER_RANK = {
REGULAR: "REGULAR",
VIP: "VIP",
GOLD: "GOLD"
};
// 將折扣率定義在一處，未來變更只要修改這裡
const DISCOUNT_RATES = {
[USER_RANK.REGULAR]: 1.0,
[USER_RANK.VIP]: 0.8,
[USER_RANK.GOLD]: 0.5
};
function calculateDiscountedPrice(basePrice, userRank) {
// 若找不到對應等級，回傳原價
const rate = DISCOUNT_RATES[userRank] ?? DISCOUNT_RATES.REGULAR;
return basePrice * rate;
}當你能從整個生命週期俯瞰時，就會站在「將來接棒的審查者或維護者」的角度，思考現在該如何表達程式碼。
-
了解網路與資料庫
當你成為一名會寫程式的工程師後，就會發現除了語言語法外，網路與資料庫的知識同等重要。若把系統比作人，網路像是傳遞電訊號的「神經」，資料庫則像是負責記憶的「大腦」，它們是系統正常運作的生命線。
網路：防止通訊「走失」的地圖
多數應用透過網際網路與其他電腦溝通。學習網路知識的理由之一，是為了「找出通訊在哪裡停擺」。
- 知識不足時：遇到「畫面無法顯示」等問題，無法分辨是自己程式的問題、通訊路徑（神經）中斷，還是對方伺服器當掉，難以正確切割原因。
- 知識充足時：理解通訊規則（協定）後，可以更快定位錯誤發生的位置，以最短路徑解決問題。
資料庫：保護與活用資訊的「資料倉庫」
使用者的 ID、發文內容等各種重要資訊，都需要安全地保存到資料庫中。對於產品開發而言，資料庫可說是系統的一部分「大腦」。幾乎所有 Web 服務都是從資料庫取出資料來運作的。
- 知識不足的風險：
若資料儲存方式混亂，當使用者增加時系統可能會變得極其緩慢，或導致重要資料遺失或混亂，造成嚴重事故。 - 知識充足的好處：
不只可以維護系統的可靠性，還能提升資料取出速度（效能）。若資料庫設計良好，日後要新增功能時，也能避免讓程式碼變得複雜、順利推進開發。
-
加速成長的心態
剛起步的工程師常常只追逐最新技術。但累積現場經驗後，我發現支撐技術的「基礎心態」更為重要。
IT 業界日新月異，昨天的常識隔天可能就過時。因此比起純粹的知識量，更重要的是以下三種心態：
- 持續學習的動力：
不被技術潮流牽著走，持續接收新資訊的態度是不可或缺的。「自己持續學習」本身，就是工程師最強的生存策略。 - 邏輯思考力：
不論是定位程式錯誤或做出高效的系統設計，將事情整理並有條理地思考的能力都是必要的。把複雜問題拆成最小單位逐一解決，決定了開發品質。 - 溝通能力與團隊合作：
系統開發從來不是一個人的工作。正確理解客戶需求、與團隊成員順利協作所需的「表達力」與「傾聽力」，能帶領專案走向成功。
為了在技術之上創造價值
這些心態需要透過日常學習與實務不斷磨練。把技術當成手段來運用，成為能持續為社會創造價值的工程師吧。
最後
對於沒有經驗的人來說，現在或許像是在黑暗中摸索，但不用擔心。帶著上面介紹的指引，真誠面對眼前的課題，你的職涯一定會有所成長。一步步往前走吧！
PRUM 的工程師有超過 95% 是從無經驗起用。如果有興趣也歡迎來公司網站看看。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
