前言

這篇是我在解 HackerRank Solve Me First 時的刷題筆記.

題目本身非常簡單, 但我在第一版解法裡犯了很典型的錯誤: 直接在 main() 裡把所有輸入硬湊出答案, 雖然能 AC, 卻沒有真正遵守題目的函式合約, 也埋下了可維護性與邊界條件風險.

題目要求與初始盲點

題目要求完成一個 solveMeFirst(a, b) 函式, 回傳兩數相加的結果.

我的初始寫法偏向「結果導向」, 直接在平台預設處理 I/O 的 main() 中把輸入加總:

function main() {
  let sum = 0;
  inputLines.forEach((num) => {
    sum += +num;
  });
  console.log(sum);
}

為什麼這樣會過

HackerRank 多數題目的評測邏輯是給 stdin、比對 stdout. 只要 console.log 的結果正確, 就可能拿到 Accepted.

潛藏的問題與盲點

  1. 沒有符合介面合約: 題目指定要實作 solveMeFirst, 但我完全繞開.
  2. 邊界條件風險: 若輸入包含空行或非數字字串, +num 的行為容易失控, 可能出現 NaN.
  3. 把實務慣性帶進刷題: 工作上可先求可用, 但演算法練習更應聚焦在函式本身的時間與空間複雜度.

觀念校準: I/O 與邏輯分離

刷題和實務架構一樣, 都適合遵守單一職責原則 (Single Responsibility Principle).

  • main / 執行環境: 負責讀取輸入、轉型、輸出.
  • solveMeFirst / 核心邏輯: 只處理運算與回傳, 不關心資料來源.
// 1. 核心邏輯: 保持純粹，專注在運算.
function solveMeFirst(a: number, b: number): number {
  return a + b;
}

// 2. I/O 處理: 負責與平台環境溝通.
function main() {
  const a: number = parseInt(readLine(), 10);
  const b: number = parseInt(readLine(), 10);

  const result = solveMeFirst(a, b);
  console.log(result);
}

核心體悟

  1. 先讀懂合約: 先看 Function Description (函式名稱、參數、回傳型別), 再寫程式.
  2. 別讓 I/O 污染邏輯: I/O 與演算法綁在一起, 題目一複雜就很難 Debug.
  3. 把簡單題當成習慣訓練: Easy 題不是只有求 AC, 而是練出可擴充、可測試、可維護的解題肌肉.

總結

這題真正的收穫不在加法本身, 而是寫法觀念的校準:

  • 能 AC 不代表設計合理.
  • 演算法函式要保持純粹.
  • I/O 只做橋接, 邏輯只做計算.

把這個習慣養好, 後面中高難度題目的可讀性與除錯效率會差很多.

參考資料