讓我們先來定義它吧

最近接到了一個需求，是要把一個我本來就已經提供的功能，升級為可批次處理。

批次處理這個很好懂啊，就一次輸入一堆資料，然後對每一筆資料做一模一樣的事情，完全就是程式設計的基本功啊(??)。

接到這個需求，當然要先想一下怎麼做再來動手，我準備在畫面上放一個挑選資料的區塊，分割成左右兩邊，左邊是可以挑選的，右邊是已經挑選的，這個介面很常見並不算複雜，然後加上一個輸入變更原因的文字方塊；不過在我把整個程式的架構設計得差不多的時候，客戶突然問我，可不可以讓每個項目有不同的變更原因。

當然礙於我得對我的工作內容保密，所以整個程式的內容不能講得太明白，這樣子可能不太好懂，所以用以下這個我虛擬的程式來說明吧。

某校的教務系統裡提供一個程式，可以讓老師「批次當人」，程式畫面大概像下面這張圖一樣。

操作的方法是先查詢系級的學生名單，名單會出現在左下的區塊，然後把要當掉的人選出來當掉，被當掉的人名字就會移到右下的區塊，最後選擇當人原因後儲存。

但是有老師反應如果他手上四種原因當掉的學生都有，那他就要操作四次，這樣很麻煩，所以在這些老師的建議下，程式改成下面這個樣子。

操作方法是查詢後，選擇要當的學生跟當掉的原因，然後按下當掉，學生的名字跟原因就會出現在右邊的區塊，把所有的學生跟當掉原因都選好後，再儲存結果。

第二種方法給人比較快速簡單省事的錯覺，但是其實按鍵的次數並不會比較少，其實以哪一種方法來操作意思都差不多，而且介面也不會差到哪裡去。

但是如果我們給每次批次加上一個批號，意思就大不相同了，讓我們用表單來說明。

第一種方法，是每一批次都是同樣原因，這裡批次被定義為相同原因被當掉的學生要放在同一批。

第二種方法，這裡的批次就只是同一次當人作業下犠牲的學生為同一批。

用另外一個例子在說明，今天有一批新兵結訓要下部隊，有專車要載這些人去部隊，新兵雖然都從同一個營區出發，但會分發到不同的地方去，這時候專車的開法有兩種，第一是每台專車都只載前往同一個目的地的新兵，第二是每台專車沿途停靠各目的地陸續放人下車，當然兩種方法各有好壞，只能視當時的狀況來決定要用何種方法。

至於我碰到的這個狀況，我覺得批次這東西多少是有意義的，如果把不同原因的東西放在同一批不會很奇怪嗎？但是客戶認定的批次就只是把本來要分好幾次完成的作業一次完成，只是一個省事的方便做法。因為認知的不同，這個要求在我眼中看起來就像是在表單上自行擴充欄位一樣亂來。

所以我說，讓我們先來定義批次這件事吧，我認為批次是這樣，你覺得批次是那樣，兩種我都能幫你們做，那種方法比較好，我想請你們自己評估之後再告訴我吧。

結果因為要實現第二種方法，需要比較長的開發時間（當然成本也會高一些），所以決定採用我的原設計（也是客戶需求最原始的模樣），當然節省營運成本也是一種專業，不過我的資訊專業還是為了此事躲到角落去哭了。