Re: [心得] 我在科技業遇到的鬼故事之一
大家好我是原po，大家討論那的激烈，我覺得我需要補充一下。
我認為有一個癥結點需要解釋一下，雖然有可能解釋完結果可能更糟 XD
因為中間有一段，完全是我的臆測，我也沒有絕對證據去證實我的論點。
如果各位要反駁我，我也完全接受。
我主要是要講一下，為何我會覺得B應該被火？
這個流程我最一開始以為的版本(1)是：
A mark 無法複製 -> B 確認無法複製 -> commit -> QA無法複製 -> release
但是第一次bug review meeting後，因為B說的話，我跟QA的認知是版本(2):
A mark 無法複製 -> B 確認問題還在 -> commit -> QA無法複製 -> release
QA跑去跟老闆告狀後，老闆把我跟B主管找過去，說如果調查是故意炸客戶，要火。
我跟B主管把B叫過來調查這件事，B這時給的是版本(3):
A mark 無法複製 -> B 沒有確認過 -> commit -> QA 無法複製 -> release
所以這時，B承認他沒有確認過。因為我們公司的流程，各自有各自的UT。
必須通過了UT，才會到QA那邊去打IT。但是B承認他沒有過UT就commit。
所以故事最終B被處罰是因為他手上的feature沒有經過自己UT測試就commit。
我對版本(3)有一些懷疑，由於過程中，我一直反覆問他兩個關鍵問題。
所以對話次序上我沒有100%肯定我記憶中的順序，敬請原諒。
我問B：你寫always，表示你一次也沒有pass過UT，為何你會commit?
B說：我只測過一次，A mark無法複製我就相信他，然後commit。
我問B：你只測過一次怎麼會是always。
B說：測一次中一次，我就寫always
我問B：你相信他無法複製，為什麼後來會說你早就知道會fail，你是故意commit?
B說：他寫無法複製，那肯定問題還在啊！
我說：這不一定吧？
B主管說：你是想說他無法複製肯定沒有解，所以想提醒大家對不對？
大概是上面這串對話，我反覆不斷用不同的方式問了好幾遍。
因為這過程中，B自己坦承吃下了兩個低級錯誤：
1. 只試一次就說是always
2. 沒有通過feature UT就commit code
但是我的理解是B這個資深工程師，不太可能犯這兩個低級錯誤。
我內心的推測是：他最初的說法其實才是對的。
也就是：『他反覆測了好幾次，都過不了(always)，於是發bug給A。
A mark 無法複製後，他也拿UT起來測試，結果fail了。
後面就是如他所說，他發現這問題根本沒有解，一氣之下commit上去要炸A。』
最後老闆把我跟B主管叫過去說要處理B的時候，B主管跟B先套過招。
他們發現承認故意後果很嚴重，所以他們有有兩種選擇:
1. 不承認測過
2. 當時有測過結果是pass就commit了。
但是處理的當下，因為還不知道root cause，所有人都認為是always發生，包含B+客戶
所以要騙說當下有測過，結果是pass的說法很可能會被打臉。
於是他們選擇承認低級錯誤，規避『故意』這件事情。
另外他說他只測一次，同樣也可能是要規避always發生的bug，卻沒有複驗這件事。
我覺得他們的說法沒有說服我，但是我也真的沒有證據，所以最後選擇大家下台階。
另外當下我忙著要去處理客戶資料損毀的問題，沒有心思去深究這件事情。
另外我的部分，我前面有說我去處理客戶資料救援有成功。
客戶部分也沒有再追究這件事，最後整個產品是有順利賣出去。
所以我的部分，其實公司是沒有特別『處理』我。 但是升遷當然就不用想了。
以上跟大家報告一下
--
Hi，鬼
供詞都可以被他們喬 你也太軟 我以前在ptt的回覆也都
我覺得是你想太多了，如果B真的很懂也重複測過，怎麼後
來無法在B的環境復現？後來你們才發現是因為LAGG的問題
？
這樣 以為不得罪人 但後來就釋懷了
B很神的前提是他知道客戶和他的環境一樣有LAGG而你們沒
有，這前提你覺得有可能嗎？
wmt又在說什麼...
應該說B故意炸的前提*
其實我們有發現B team工程師不一定會更新test code的習慣
他們只關注自己開發的地方，test code沒有很頻繁去update
但是B的環境是不是一直都是有問題的LAGG，我也沒有證據。
所以B主管也有說LAGG test code修正了，這樣大家都解套。
你不如說說為什麼A在被你review過issue確認可以close以
後還被懲處吧 你有坦住你下面的RD嗎? 尤其他還是你身為P
L卻沒把客戶需求釐清的第一受害者
檢討B的紀律問題跟你們project出bug真的有關?
A的部分，我有極力去擔，但是我承認我沒有手段可以扛住。
所以A走掉，也是我戰力損失。
B的問題是老闆認為故意的話要火
但是feature owner沒確認就commit，的確是有責任的。
所以B不是被認定這個事故該負責的人嘛
你用一大段臆測指控B和其主管，A和QA都你的人你好意思
B被處理不是自爆的部分，而是沒有確認這件事。
如果關閉bug有經過B同意，B確實有責任，但要說B是故意炸
客戶我覺得太腦補了點
所以你沒保住A但保了B?...
p大和s大你們兩個說的feature owner是不同人唄
對，所以我自己腦補的部分我一直沒說。
但是我沒有因為腦補結果去處理B
所以B鬼的點在哪? 沒有紀律自業自得 但你是不是該學學B
主管怎麼維護自己的戰力?
B故意炸A 客戶只是被牽連
你沒說但你一直在提醒大家B是故意的啊XD
因為他自己說他是故意的啊XD
原來還花這麼多無謂時間在究責
B主管真的很強，我沒話說。
但實務上你覺得有可能嗎？
你用他的嘴砲來這邊講，看看多少人認為B故意炸客戶…
我是認為實務上，B不會犯這麼低級的錯誤，如此而已。
到底是去當國中生搞小團體的還是去工作解決問題的啊
就有供詞 但B主管想保B翻供
低級的錯誤才是最容易犯的好嗎…因為隨手就可以成功
我其實只能去評價A，B的部分我其實沒有權限去作任何事。
wmtsung你要這樣理解也是合理，這也就是為何我沒有去深究
誰說B炸客戶... 他要炸人是真的 客戶只是工具 講第二
次了
有可能就只是一連串的低級錯誤加上嘴賤而已。
連帶大家雞飛狗跳而已
不覺得你們的module會不會造成資料毀損全公司只有你們t
eam最懂嗎？是期待別人幫你測出問題，最好還能幫忙找到
root cause？最後再來全力檢討問題的問題，下次B換成不
會亂自爆的C你們還不是要繼續炸？
你看你又來了 保錯了人不說 現在還要替別人自圓其說
所以A被處理是因為炸資料，B被處理是因為他沒UT。
奉勸原po別再糾結B心態如何 A被提報出bug時你身為最初埋
炸彈的人是否出來坦坦承這是你的錯誤導致的?
錯誤我們一直都有承認，最後也有受到處罰，這部份沒問題。
我覺得分兩個路線，一個是寫出bug，一個是沒過UT。
重點在A沒有做錯
而且B只測過一次是在事後你問B才知道，那A當初到底怎麼
和B討論這個bug也是很神…我自己測不出來一定是叫發bug
再重測看看
只測一次寫always 被火剛好
前面有提到B是拒絕幫忙，他認為bug report足夠。
如果當初B對A說謊導致後續，你拿這個來打B還比較實在
A屬於RD寫出bug，我認為不應該去重責，所以我只認定1/10
那在B拒絕時你應該先找B的主管啊
一氣之下就炸客戶無法接受。
B的主管是認為我們要自己複製+QA幫忙，他的說法其實也合理
畢竟我手上有QA, B主管沒有。
你認為他為什麼會寫出沒考慮到LAGG的bug? 是不是你提供
他的spec跟測項沒有? 那這bug是誰的責任?
兩邊都在推託串資源義務，彷彿在當兵敵不動我不動
我上面有提到，其實是我應該要負責讓QA有LAGG項目。
好 那麼A的1/10是不是該算你這?
是我也會贊成處裡B啦，但這只是出氣打不長眼，真正要改
善流程還是要從A和QA明明有收到資料毀損的issue明明什
麼都沒動還不喊停
A的code沒有考慮到packet order問題，LAGG只是其中一個
我跟A都有能力把這bug攔下來，但是我們兩個都miss了。
那說實在的，B也只是來支援，你們部門當時都無法復現也
只能自己擔，應該說客戶炸了之後你們還是可以解決，那只
是在當下你們輕忽沒有全力去找原因而已
我看了五天下來，完全不知道order有關
技術細節我沒有提太多，LAGG環境下，packet會out of order
B不是來支援，B owner一個feature，A才是支援他。
我owne application, 所以B是支援我。
ok 那麼issue close時A提供的解方也還是沒有涵蓋到這 你
是review的人 A還是要擔這1/10?
按照工作流程，不是code被review，出事就是reviwer全責。
B是來串接的 支援？...
你是leader, review這個點是可以用來保護A的你知道嗎?
我是以組織來看啦，至少這個案子應該是你們部門為主吧？
不然不會只有B在這裡啊
我認為就是因為有review，才敢喊A只有1/10
案子其實以我為主，但是我的team大部分都是support其他人
跟我想得差不多 只是原來還有翻供
B是owner一個feaure，工作就是把好幾個function串起來
題外話 嗑瓜觀眾可以讀Lamport的The Part-Time Parliament
我覺得不能說是翻供，只是在原本說法上作最大程度的解釋
只是這個解釋，很讓我無法相信。
現代分散式系統的理論發軔點
就是供詞蓄意然後不能這樣講給老闆聽不然老闆會抓狂
火B 這怎麼不是翻供...
就我沒有他們翻供的決定性證據。
就跟偵探劇結局一樣：你這麼說只是你的臆測，有證據嗎？
如果這真的是翻供，我覺得B的主管很神！
B的主管不管是技術還是政治上，都強我好幾個檔次。
不管怎樣,老闆是心有定見啦,沒有相信你們報上去的A和B的
技術我不知 因為沒資訊 但政治我已經嗅出來了
因為版友是第三者，對你的說法只能看“發生了哪些事”，
對你的主觀說法(包括對話轉述)以及猜測(包含這篇的許多內
容)都不能盡信，你可以試試用這樣的觀點去看整件事。另外
，居然沒有在客戶的模擬環境做sanity test，我看你們是很
猛喔
責任有限,考績和分紅被砍就是老闆的態度了
B大概也被mark了,否則怎會只因為代刷門禁被火
sanity test是啥
不就是蓄意改成低級錯誤方向解釋 是翻供無疑
tsairay大講的有道理耶，我解惑了。
老闆心裡根本不相信A和B責任有限,只是給兩位主管一個台階
下,不拆穿而已,實際上老闆心裡就是認定A和B有責任才會砍
考績和分紅
代刷門禁這種事就可大可小啊 XDD 的確有可能藉題砍他
但也有可能對於某些特別注重誠信的老闆來說是禁忌
主要是B不是A 強調要調查B是否蓄意 雖然制度差但這老
闆顯然不是傻子
我都有從老闆行為反推論
這件事沒有處理好，心理一直有一個疙瘩。
我會po上來，我覺得也是一種尋求慰藉跟療癒。
大家的分析後，我突然懂了。老闆其實什麼都知道。
我跟B主管就是還在幫他賺錢接案子，他不會給我們難看。
尤其是門禁這件事，我原本覺得莫名其妙，現在整個都通了XD
其實能當到老闆的..都不笨啦,不會盲信下屬報上來的主觀
我覺得我心種某一個執念可以生天成佛了 XD
意見,他們也會自己從各種客觀條件得出自己的結論
辛苦啦，其實不用跟鄉民太認真。誰對誰錯又豈是我們這些
局外人可以判斷的
我覺得最大的問題是橫向溝通有問題,,再次發生也不意外
最終結果走了3個戰力 如果這樣可以視為老闆排毒成功 我
也沒啥好說了 就祝福原po及其部屬
我剛剛想通一件事，老闆其實最相信的不是我或B主管
而是QA,因為QA是老闆直屬部隊，暫時借給我指揮而已。
事情可能是QA跟老闆告狀的時候，老闆就明白了。
後面都是我們在演猴戲而已.....T T
感謝各位給我的指教，真的獲益良多。
QA的feedback就是我們橫向溝通要加強沒錯。
是 但Qa懲處一點都沒有很難說的過去
QA就是去被PDCA這件事，感覺好像有處罰，實際上是沒有。
PR owner要負最大責任
這事背景越補越多XD 可以最困難的永不是技術問題而是政
治手腕。常理來我是支持原PO版本2的想法，如果我開的
bug，我看到修正了不太可能忍住不複測。
如果環境複測不出來，事後就會說複測不出來，不會嘴砲
說要用客戶HL問題。
所以真相大概就是複測過真的有問題，然後丟去客戶那看
爆炸。老經驗主管得知後，再幫忙想理由避責。
（這種事其實我工作上一年都要碰上幾次，作多了自然知
長官喜歡聽哪些理由來解釋靈異事件。）
不要叫整合的當你們的QA好嗎 你們都關了還要人家幫你把關
必要時A跟B跟他們的老闆要抓過來一起war room debug才是
一下說事後發現LAGG拔掉所以才會打不出來，一下說你覺得B
出去前有測過fail故意炸客戶，啊LAGG都拔了B還打得出來？
好了啦，你就是想公審B結果翻車，可以下去了
一點擔當都沒有只會搞政治的主管
假設B從沒參與這次開發，就從頭到尾沒人會戳到這個bug，
你們一樣會炸客戶，還在扯B有多少責任，笑死
你不如說說是哪家產品這麼雷好讓大家避開以免資料被毀
畢竟這家公司不是因為被B惡搞才會炸到客戶喔，是RD有機會
造出一個沒人測到的bug把資料刪光
花一堆時間在究責，想辦法說服大家B的態度有多差，卻沒
檢討過自己負責的產品為什麼會造出這種bug還放出去
你身為PL知道這個issue存在，知道A搞了三週無法復現就相
信這個bug會自己消失？其實客戶資料會被刪光就是你跟A造
成的，你沒有要求A把根因找出來
現在眼看風向不對開始出來補充說B沒過UT就commit，阿你
的產品你的流程怎麼會讓人沒過UT就能release啊？誰知道你
說的B沒過UT就commit是真的還是開始編故事為了帶風向啊？
搞半天責任是在B沒有做好UT是嗎？都是B的錯就對了
資料刪光這個issue是可以隨便關的嗎= =
還有A測3個禮拜測不出來沒有call help嗎？照理說是要找A
team的人來挖bug吧？大家都在幹嘛= =？
A的環境測不出來，身為leader不是第一步就是跟客戶確認
環境嗎？如果客戶環境跟A一樣就沒事，不一樣就弄成一樣
啊，三個禮拜都沒人確認喔= =？
原PO其中一篇說測不出來，後來跟A一起review把可能有問題
的地方修改之後就close（通靈debug)，直到客戶炸開才回頭
調查發現原來是LAGG會引發問題，若早一開始就認真看待去
把環境確認好怎麼會炸到客戶那邊？這個bug也不是說，有
機率閃退這種小事
別帶著情緒做事吧。B該不該被火，不是你這個職級與角色該
決定的。
而且前一篇說B沒什麼責任，這一篇又說責任在B。你連當個ow
ner的角色該做什麼都有點混亂了吧。
而且喔，太多都是你"自己"無證據預設立場推測出來的結論。
何必把自己搞那麼累。
最後，正常有點品質的軟體公司或管理流程，UT都是跑在開發
者以外的電腦，而且會自動記錄。有沒有UT，以及Log根本沒
機會造假。
原PO有機會可以去了解正常CI流程，以後遇到同樣的事情，或
許會有不同想法。
簡單的說，你就是沒做好把關，讓bug出去客戶端了嘛，推那
麼多責任做啥，結果B自爆讓你找到一個宣洩甚至卸責的出口，
頂多說B職業操守有爭議，但你事實上就是Owner，你自己也說
你扛責辭職了，那感覺還要上來批鬥B，分享什麼鬼故事做啥
確實，你要感謝B嘴邱，不然你連鍋都沒得甩
如果關issue後要commit前B沒再試一次或是試過還是炸了卻
commit 我覺得B確實要扛責任
不過我比較好奇不管B有沒有自爆 你們在review的時候最終還是
會找到B那邊吧 一定會問B最後有沒有再試一次吧
always = 只測一次，B這個人說的話，沒有可信度
剛剛想到，第一篇原po講的A認為B搞砸環境，那B即使在自
己機器上複測fail也沒有意義了不是嗎？
原PO可以多學習溝通協調力+政治敏感度，跨部門有衝突
難免，如何在不同部門"合理"調動資源，協調力很重要，
可能主管也認為原PO處理還沒有很好，所以升遷就先庭住
其心可議 一開始講鬼故事的時候怎麼不好好描述 想引導
B是鬼
原PO就被卡升遷7pupu，現在還放不下，不然原PO、A、B
都離職了，還要拿出來鞭屍
原來是這樣
不管B最後到底有沒有測 結果是不變的 因為B確實
commit了 A/QA/原PO因為盲區而有的過錯與B原來的過錯
是兩回事 都說了N次 不要拿前者的過錯來cover B的過
錯 整天洗B沒錯 B很嚴重是事實 這本來就不是一個人導
致的
你也只能相信原po說的 除非你找到其他當事人加入戰局
原PO說B沒什麼責任的前提是B確定不是故意要highlight
事情已經結束原PO是分享故事 要卸什麼責？ 如果你是
原PO在這種公司並遇到這種事情你會怎麼做？ 我敢說
幾乎所有主管都沒那麼認真 很多主管為了省心不會主動
追蹤或技術難點確認完畢
部門內再檢查的結果不就是無法復現摟
你才在整天洗B很嚴重…
之前還要說別人洗地，自己的行為最像在洗地
B很嚴重有理有據 太多拿自己經驗以及腦補想法臆測的
不是洗地是什麼 本來就是根據內文找線索推論而出 在
你眼裡就變成洗地... 你們講的一堆東西都無法驗證 什
麼B只是嘴臭
況且我也沒有說其他人都沒問題 沒幫其他人洗地
你的洗地概念跟其他人很不一樣... 但知道你的意思
事實上，他們公司的處置已經告訴我們，B就算自爆，責任
也只跟差不多
你跟A以及QA都知道B提出過有問題 也清楚A跟QA沒複製出來
當你們關閉該問題時 就是在背書該問題可以忽視
你跟A跟QA都知道 那問題沒有真正被處理 可能有未爆彈
release前你們不清楚哪些功能有上線? B只錯在嘴臭而已
處置A與B同是因為原po保了B 以低級錯誤論處
close沒有可以忽略的說法 那只是你的經驗 開源專案與
公司內開關都是有的事情
推
爆
首Po講一個我在科技業遇到的鬼故事 這件事主要發生在兩個人身上： A:是我同部門的同事，主要開發kernel層以下的功能。 B:是隔壁整合部門的同事，主要是開始kernel層以上的功能。 有一天A開發了某一個功能，B整合完之後發現會導致資料損毀。於是B發了一個bug給A，![[心得] 我在科技業遇到的鬼故事之一](https://i.imgur.com/13sxjYWb.png "[心得] 我在科技業遇到的鬼故事之一")
這個怎麼想都是公司的問題 居然沒有CI/CD? 環境怎麼會是以個人當標準? CI/CD過了 誰local有問題就你家的事啊 這種垃圾公司原PO還是快逃13
難怪IC house要推當責Accountablity 提到的每個人都幾乎有責任啦 就跟空難和起司理論一樣 不是只有一個單純的原因造成 Product owner每天或每周都應該了解進度/severity72
這篇文最鬼的明明就是原PO，這個Feature在他的組開發然後有問題，自己組的人+QA竟然 測不出來，結果隔壁組的人竟然有權限把Feature打開，B就算說原本就知道有問題硬要搞 最後補一句「有可能是我自己環境有問題」也是能全身而退 說到底身為新Feature的lead管產品品質+QA都管不好，有問題的code還能進到release br anch，最後還能PO出來讓大家評論B，這才是我看過最鬼的鬼故事吧78
我是原po，我來交代一些細節，供大家參考一下。 角色： 我在這裡的角色是application owner，我要推一個應用給客戶去使用。 我這個application需要多個feature來組成，B是我其中一個feature owner。 B這個feature需要多個kernel function整合才有辦法達成，當然B自己也要寫不少code。8
→ pokkys: 所以B根本不需要講他是故意的話。 07/25 19:37 所以大部分的人都搞錯重點了 因為事情對或錯往往都不是重點 而是看哪個部門比較大聲 B大也可以裝傻 退一步假裝真的是當時誤以為自己搞砸環境4
不是mindset也不是制度問題吧 是你們所有人的環境為什麼都跟客戶不一樣？ B只有一開始的環境類似於客戶 後來也不一樣了所以可能也做不出來 環境不一樣25
再回一篇，先說我不是B但是這個細節出了更明顯不是B的問題了啊 這個Bug本來就是一個corner case只是好巧不巧在B開發的時候遇到一次，要是今天B剛好 就沒遇到這個Bug，你們還不是一樣照常Release，客戶一樣爆掉，這樣B不就剛好衰幫你 發現Bug而已？ 你硬要說B的態度有問題，他也只是表達出他遇過且在你們根本沒修的情況本來就很可能8
到這邊為止 A看起來有把問題反應給你 你的工作應該是跟B的主管協調,看能不能讓B優先處理這個issue吧 大部分職場都會把開發需求區分piority 如果這是個嚴重的issue, piority設高並且必須優先處理.24
第一篇文章推文： pokkys: 我的職位要扛feature成敗，所以我也因此卡到升遷。 pokkys: 沒有火B這件事我也是傻眼+不滿，所以我比B還早離職 XD 第二篇文章內文： 其他人的部分，我是極力不想對A究責，B的主管也是一樣的態度。最後我們兩個送上去給老闆的說法是這兩個人的責任，10分裡只有1分。
27
[討論] 對岸的軟體工程師本ID在台北一家陸商待過一個月 發現對岸SW RD的整code習慣是這樣 覺得自己寫好了，就commit了 commit之前不做驗證，不初步抓一下bug 連local build pass都沒有12
[討論] 同事喜歡追根究底是躁鬱症嗎就是啊 我們東西做完會給驗收的人驗 如果他發現bug就會退回來給我修 但是他會一直問到底是什麼原因造成的bug 我會用他聽得懂的方式回答 他就會咄咄逼人的問為什麼不那樣修22
[請益] git協同合作問題遇到一個情境 想請問應該如何操作 假設現在 有一個主分支release 兩個feature branch 第二個分支需要用到第一個分支部分代碼![[請益] git協同合作問題](https://i.imgur.com/hgMRn5lb.jpg "[請益] git協同合作問題")
16
[問卦] 同個 commit 不同 commit hash 之謎如題，沒在用 Git 請左轉 剛剛在兩個 remote 上面看同一條 commit，發現它倆有不同 commit hash 我知道如果有 rebase 過的話 commit hash 會不同 但除了 rebase，還有其他原因會讓 commit hash 有變化嘛？ 我很好奇!17
Re: [討論] 怎麼跟自以為是的同事相處^^^^^^^^^^^^^^ 不要做這種假設，很多programmer 選擇這行就是因為他們對人技巧不好、但好死不死又 適合寫程式 除非你觀察到產品A一直找不到其他前端，或者新加入的前端離職率很高，否則我們沒有 客觀事實9
[請益] git rebase的問題各位好 本人在近來在公司需要將專案中某個pull request的commit統合成一個 下圖為pull request，本公司用的是bitbucket 我看了一些網路教學和youtube，仍然想不出解法。我的做法如下：![[請益] git rebase的問題](https://img.youtube.com/vi/8j0H6urZ-bU/mqdefault.jpg "[請益] git rebase的問題")
8
[心得] 用 ChatGPT 幫忙整理 Code Changes部落格: GitHub: 相信大家對 ChatGPT 不會很陌生，這是目前在生成式人工智慧 (AIGC: AI Generated Content) 內的當紅炸子雞，然而 ChatGPT 對於軟體工程師有什麼影響呢？能否透過 ChatGPT 改善團隊流程或協助開發？而我現在想到最直接的就是用 ChatGTP 幫忙寫 Git![[心得] 用 ChatGPT 幫忙整理 Code Changes](https://i.imgur.com/AG6MWQeb.png "[心得] 用 ChatGPT 幫忙整理 Code Changes")
6
Re: [討論] 靠submit紀錄來除錯是一個不好的習慣嗎我覺得抓bug要看經驗 不同情境有不同的使用方式 像是從git log抓bug，使用git blame指令 是俗稱的抓戰犯 通常用在追踨bug追到一段code2
Re: [請益] bug「可遇不可求」，各位還會去debug它嗎?1、crash的bug 2、10%機率 放在任何公司都沒有人認為這叫機率不高 10%基本上一定有解 10%當機很規律好嗎？XD
![[討論] 同事喜歡追根究底是躁鬱症嗎](https://i.imgur.com/Fqnp1Iib.jpg223.138.224.128 "[討論] 同事喜歡追根究底是躁鬱症嗎")