前言

這篇是我在解 HackerRank Simple Array Sum 時的刷題筆記.

題目本身不難，但解題過程很有意思: 從直覺式的迴圈累加, 走到更宣告式、語意更清楚的 reduce 寫法. 這種轉換雖然看起來只是語法替換, 背後其實是「是否能把邏輯寫得更純粹」的思維升級.

題目要求與最終解法

題目給定一個整數陣列, 要求回傳陣列內所有元素的總和.

我最後採用「核心邏輯與平台 I/O 分離」的方式: 把運算收斂在 simpleArraySum, main 只負責讀取與輸出.

// 核心邏輯: 純粹接收陣列並回傳總和.
function simpleArraySum(ar: number[]): number {
  return ar.reduce((a, b) => a + b, 0);
}

// 系統環境 (main): 保留 HackerRank 預設的 I/O 處理.
function main() {
  const arCount: number = parseInt(readLine().trim(), 10);
  const ar: number[] = readLine()
    .replace(/\s+$/g, "")
    .split(" ")
    .map((arTemp) => parseInt(arTemp, 10));

  const result: number = simpleArraySum(ar);

  // ...略去平台預設的輸出...
}

思維進化: forEach vs reduce

在解題當下, 我的思路從「先求能動」進化到「讓語意更好懂」:

  • 直覺思維 (Imperative Programming): 一開始會宣告外部變數 let sum = 0，再用 forEach 逐項累加. 這樣能解, 但需要依賴外部狀態(Side Effect)
  • 最佳化思維 (Declarative Programming): 改成 ar.reduce((a, b) => a + b, 0) 後, 程式語意直接變成「把陣列收斂成單一數值」, 也同時消除了外部可變狀態.

複雜度分析

  • 時間複雜度 (Time Complexity): $O(N)$, 因為 reduce 需要走訪陣列一次.
  • 空間複雜度 (Space Complexity): $O(1)$, 只使用固定大小的累加器, 沒有隨輸入成長的額外空間.

核心體悟

  1. 完全適應平台規則: 把解題邏輯寫在指定函式, 外部 readLine 與輸出流程維持平台慣例.
  2. I/O 與邏輯拆開才好維護: main 專注資料流, 核心函式專注計算, 後續除錯與重用都更輕鬆.
  3. 寫法不只求 AC: 從 forEach 轉到 reduce, 代表開始追求語意清楚、結構可擴充的程式碼.

總結

這題的重點不是「加總會不會寫」，而是「寫法是否乾淨」:

  • 能過測資只是基本門檻.
  • 核心函式要保持純粹、可測試.
  • 透過更合適的語法工具(如 reduce), 可以讓程式更直覺也更穩定.

這個習慣養成後, 遇到更長的資料處理題目時, 思路會更快收斂, 程式也更容易維護.

參考資料