前言：為什麼不是 X 才是空教室？X 在這個專案裡真正代表什麼？

前幾天把使用者查詢空教室的流程串起來之後，我開始注意到一個很小、但其實很重要的細節。

在 QueryResultViewModel.kt 裡，程式會判斷某間教室在指定時段是不是可以使用，判斷的其中一個條件，是看課表資料裡的欄位是不是：『X』

其中有一個很重要的條件：

schedule.mon1 != "X"

乍看之下只是一個很簡單的判斷，但我第一次讀到這裡時，其實把 X 的意思理解反了。

所以今天我想先把這個判斷釐清：在這個專案裡，X 到底代表什麼？

一開始我認為

一開始看到 X 時，我沒有特別去想它的意義，我只知道這段程式是在判斷教室是否可以使用，所以很容易直接把X 以為是「有空教室可以使用」。

但重新回頭看程式碼後，我發現這個理解其實和程式的判斷式完全相反。

程式寫的是：

!= "X"

意思也就是：不是 X，才會被視為可以使用。

實際讀完程式碼後

和 Hermes Agent 一起重讀檔案後，我回頭看了 QueryResultViewModel.kt 裡的 isRoomAvailable()。

這個函式的工作就是判斷：某間教室在指定的星期、指定的節次，是否可以使用。

程式會先根據目前的時段找到對應的課表欄位。例如：

星期一 + 第一節
    ↓
    mon1

接著再判斷這個欄位是不是 X。

概念上可以簡化成：

schedule.mon1 != "X"

這裡最重要的是 !=，也就是代表：不是 X。

因此判斷結果可以簡單整理成：

• 是 X → 不可用
• 不是 X → 可用教室

這時候我才發現，自己之前其實是只注意到了 X 這個值，卻忽略了前面的 !=。

流程整理

把這個判斷放回前面整理的查詢流程，就會變得比較清楚。

使用者選擇：

大樓
↓
星期
↓
節次
↓
樓層

接著 QueryResultViewModel 會開始篩選教室。

其中一個條件就是：

找到符合條件的教室
        ↓
確認大樓、樓層
        ↓
找到指定星期與節次
        ↓
判斷該時段是不是 X
        ↓
是 X → 排除
不是 X → 保留
        ↓
emptyRooms

所以 emptyRooms 並不是直接從資料庫拿出來的，而是經過條件篩選後產生的結果，而「是不是 X」就是其中一個關鍵條件。

Hermes Agent 幫我檢查出的重點

Hermes Agent 在這裡協助我重新檢查自己的理解，而不是直接替我下結論。當初和 Agent 分析 QueryResultViewModel.kt 的相關程式時，可以看到 isRoomAvailable() 裡實際使用的是：!= X：

    private fun isRoomAvailable(schedule: ClassroomSchedule, timeSlotColumn: String): Boolean {
        return when (timeSlotColumn) {
            "mon1" -> schedule.mon1 != "X";
            "mon2" -> schedule.mon2 != "X";
            "mon3" -> schedule.mon3 != "X"；
            ...
            "tue1" -> schedule.tue1 != "X"；
            ...

這表示如果對應的課表欄位 不等於 X 時，則教室可以用（有空教室）。

所以這次真正重要的不是 AI 告訴我「X 是什麼」，而是它讓我回到實際的判斷邏輯，確認自己的理解有沒有和程式碼對得上。

這個檔案帶出的維護觀察

這次看到的問題比較偏向可讀性與理解成本，而不是功能錯誤。

像是：

schedule.mon1 != "X"

如果只單看這一行，其實不容易知道：X 到底代表什麼。

第一次接觸這個專案的人，必須繼續往其他地方追，才能理解這個字串和「教室是否可用」之間的關係。

目前程式既然可以正常運作，這不一定代表需要立刻修改。但如果未來要提高維護性，可以考慮讓這種狀態值具有更明確的語意，而不是直接在判斷式裡使用：X。這樣其他人閱讀程式碼時，就不用先猜這個字串代表什麼。

不過這部分我目前先記錄下來，因為如果還不了解完整的資料結構，就急著修改，很容易只是在修自己還沒完全理解的東西。

小結

今天其實只解決了一個很小的問題：X。但這個小問題讓我發現，看懂程式碼不只是知道它「在判斷什麼」，還要確認自己有沒有正確理解判斷條件。

我原本把 X 的意義想反了，但實際看程式碼後才發現：!= "X" 真正代表的是：不是 X，才會被視為可用教室。

這也讓我重新注意到，前幾天看到的 emptyRooms 並不是一個單純的資料集合，它背後其實經過了大樓、樓層、星期、節次，以及時段狀態等條件篩選。

先知道程式怎麼判斷，再往下追它判斷的資料從哪裡來。

這句話是我從今天的文章中，所學到的寶貴經驗。

下一篇預告：從首頁到詳細頁：我把使用者查空教室流程串起來了

探討了空教室查詢系統中，一個很小卻很重要的邏輯－ X 之後，使用者查詢的流程就告了一段落。

我們介紹了：首頁 MainActivity 到查詢頁 QueryResultActivity/ViewModel 、列表 EmptyRoomAdapter 、再到詳細頁 RoomDetailActivity。

下一篇，我們要來總結使用者查詢流程，透過這次的總結，我們就可以更清楚了解到各檔案／頁面之間，是怎麼互相合作，完成了第一階段的「使用者流程總圖」。