指正《【社群恩仇錄】byStarTW/instanceof/pan93412》一文中的斷章取義或錯誤描述

https://blog.init.engineer/posts/BlockedPan93412/

這篇文章僅為行使本人 (Pan93412) 之媒體答辯權。

關於訊息的可靠性問題

乾太在未經告知的情況下強行清空我與他的所有通聯紀錄。有鑒於原始訊息證據消失，原文之所有引用皆有杜撰或改寫之可能。即便如此，我仍嘗試推斷原 Context 並給予我這端的解釋。

原文論點的我方看法

怎麼不用 Memcached / MariaDB 還有 Redis，不用 docker-compose 或 k8s 感覺很累

這個訊息的內容斷片嚴重，個人認為可能有被斷章取義。這訊息最可能的出處是我詢問乾太有沒有考慮用 Docker 部屬周邊服務，因為手動配置 Redis 跟 MariaDB 的易便性，的確不及直接 docker-compose 部署方便。但這僅為建議 (feature request)，我未批評原做法不好。

「不考慮換成 PostageSQL 嗎？聽說效能好一點」

欸？等等，前一句你不是說怎麼不用 MariaDB 嗎？怎麼下一秒問怎麼不考慮換成 PostageSQL 了？

算了，繼續看其他的好了。

不要用斷章取義的訊息推斷訊息情境。本訊息出處已不可考，但或許也是作為一個 feature request 提出。由於 Laravel 的 Eloquent ORM 本來就可以自行切換成喜歡的資料庫後端，這純粹就是提供一個遵循 SQL 標準，在普通情境有更加效能的資料庫系統建議。

你現在的開發模式大概跟 jQuery + Notepad++ 那時代差不多

你們是不是都很喜歡把 IDE 當 VI 寫

這裡的 context，是我發現到乾太在 Blade 範本，利用手動輸入元件路徑的方式取用 Vue 元件，完全不考慮讓 IDE 管理元件的名稱。這部分確實是個調侃，因為無論是現代前端或是後端，都盡可能希望仰賴 IDE 的 auto-completion 而非自己手打，而我又是寫 TypeScript 出身的，本來就會對這塊尤其留意。

縱觀包括這一則訊息的原始 context，我確實站在現代前端工程師的立場，批評了 init.engineer 目前前端開發模式的不足，而乾太也在之中，承認他並不是很了解前端開發的生態。我和乾太畢竟開發的領域和習慣大相徑庭，因此誤會與衝突個人認為是難免的。若乾太認為這種調侃使其不適，我在此遞上十足的歉意。

既然 Blade 可以做 Component，為什麼又需要一個 Vue？

問這問題的當下，我並不了解純靠北工程師的 codebase。因此當我讀到 Blade + Vue 的混合程式碼時，就向乾太詢問了這個混合的必要性。畢竟能用一個渲染模板完成的事情，我們為何要拆成兩個？

因為 Laravel 目錄架構與 Vue 習慣的開發模式不同，我問這句的另一個目的也是為了要把 Vue deprecate 掉。這樣我也比較可以不用為了維護 Vue 元件的名稱而操心。

無論是裝了 Laravel 的 JetBrains PHPStorm，還是裝了一堆 Laravel Plugins 的 VS Code，兩個都看不到這個函數的定義

我畢竟剛入門 PHP/Laravel 開發，因此當我發現乾太可以 auto-complete，而我不行的時候，我就向乾太請教設定 Laravel 相關的事宜。這純粹是一個普通，有些新手級的問題，但乾太的斷章取義，似乎讓整個情境變得像是我在指責 Laravel——我並沒有這個意思。

老實說，我不是很喜歡這個 Codebase 的前端擺放方式，所以我其實得承認，我有點在找碴

這個訊息的情境是這樣的：我原本想要自己開一個 repo，用自己熟悉的架構，獨立寫 init.engineer 的 Front-end。後端 API 的部分，我當時也有積極幫乾太尋找能開發純靠北 API 的夥伴。所以我的確有自己的解決方案，但乾太否決了這個建議，要求我寫在原來的 codebase。既然如此，我就像乾太提出了目前 codebase 開發前端的不足。不過我也得承認：在指出問題的過程中，我欠缺換位思考。在此再向乾太致上十足歉意。

見上，畢竟我原本是想要自己獨立一個 repo 寫前端的。啟動 Laravel 很快樂，但用 Laravel 的架構寫前端就不快樂了 ⋯⋯ 除此之外，乾太將我後來用 Laravel 正式貢獻前端的紀錄完全忽略了，實際上我後來花了幾週的時間，學習 init.engineer 的全端開發方式，並貢獻了乾太所期望的首頁 Milestone。詳情可以見 init-engineer/init.engineer PR#88：

當你把項目下放給這個人後，他雖然會嘗試接觸項目相關的技術，但是整個過程會有許多負面情緒、抱怨，甚至是質疑項目技術。

我承認。

如果對於項目技術不熟悉，會質疑項目是否過時了、難以開發，甚至會有「你現在的開發模式大概跟 jQuery + Notepad++ 那時代差不多」諸如此類的言論，反而不是嘗試去了解相關技術。

與上面的 他雖然會嘗試接觸項目相關的技術 相斥。

本部落格所有文章除特別聲明外，均採用 CC BY-NC-ND 4.0 許可協議。轉載請註明來自 我不會寫程式！

ND 部分我只能確保我想反駁的論點完全取自原文。BY 和 NC 皆已遵循。

專案始末

有鑒於還沒有人想知道這方面的事情，我先擱置不寫。

「其他人的想法」又是怎麼一回事？

• haer0248 的回應：我完全承認本文內容我所有的疏失。在此誠摯向阿任道歉。
• Telegram - 靠北 byStarTW (pan93412)：我和幾位朋友都找不出後期訊息中明顯的靠北／錯誤點。或許對方是我的粉絲，所以才這麼鍥而不捨地收藏我的語錄？