承上篇

經歷後端分頁的爭執，對於我可以整理出所有理由，並用大家聽得懂的方式解釋，拒絕盲從做蠢事，不禁有種「在研究所沒學到可以實際應用的生物技術，倒是學會如何整理思緒強力反駁」的感慨，而從此時，我開始對這位所謂的「技術長」的能力開始起疑。

在不久之後，又遇到一件讓我更確信這個人肯定毫無技術可言的證據：

某日，我收到後台管理系統的新需求：在顯示寵物列表資料的同時，也想在列表中顯示有關這隻寵物的主人姓名。由於寵物資訊與會員姓名分散在資料庫的兩張表上，「所以肯定是改寵物列表的那支 API 是吧？」我正這麼想時，我主管卻說：「寵物列表的那支 API 裡面包含會員 id 了，所以你就拿著會員 id 來請求會員詳細資料這支 API，來獲取主人的名字吧～」我：

為什麼、為什麼我一個前端要跟你解釋後端資料庫的基本中的基本啊啊啊啊啊啊？？？？？！！！！！
我立刻沉下臉，問：「你為什麼不 JOIN???」

「蛤？」
我真是不意外他會有這個反應

我深吸了一口氣，壓下那個發怒的衝動，說：「為什麼我顯示一列資料，要再同時打第二支 API，為什麼我顯示一頁的資料有可能同時要再請求十次、或是二十次？你應該要先 JOIN 兩張表，再一次將資料回傳給我。」

「你這樣做是錯的！」主管臉帶慍色，高聲回道。
我直直地看著他，「這個人為什麼會在這個位子上？」我忍不住這樣想。

這時，一旁的 iSO 工程師突然開口：「還是你要將這個動作藏在列表後面的按鈕中，點擊後觸發 API？我就是這樣做。」
我感覺心中又有些東西被消耗了，我回到：「需求是：寵物列表中要顯示主人的名字，不是按個按鈕再顯示，而且，在操作上，要執行搜尋功能時，你的做法要怎麼做到搜尋主人的名字，就算你說不要搜尋功能，將主人名字移到寵物詳細資訊頁面顯示，也會有一樣要 JOIN 的需求。」
即便如此，主管還是堅持：「你這樣做是錯的！為什麼我要 JOIN 兩張大表給你！這樣效能很差！」
我說：「可以 JOIN 部分欄位就好」誰叫你 JOIN 兩張表的所有的欄位了＝＝

「你這樣做就是錯的！」
我無言以對，盯著我主管的眼睛，搖著頭說：「我的學校不是這樣教的。」

這爭執不知道是怎麼結束的，結論是又被我主管各種推遲與四兩撥千斤，當作沒這回事，就像上篇一樣，我雖然沒拿到我要的，我也沒去做主管提出的方法。

這時的我真的覺得這個人真的好可疑，但正當我以為大概就這樣了吧？沒想到跟新來的後端聊聊後，我更想加快腳步離開這個團隊。

附上當時閱讀的好文：JOIN 介紹