前言

這篇是我在解 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 只做橋接,邏輯只做計算。

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

參考資料