嘿那裡！在開始之前請注意...我已經很久沒有寫信了。多年來我一直威脅要這樣做，最後我發現這是一個很好的話題。我有點生疏，但會努力堅持下去，希望能有所進步。
EventPress 可能是我所做的最重要的事情。我從一開始就參與其中，該應用程式在過去 10 年中經歷了 3 個主要版本，呈指數級增長。版本 4 現已發布，在我們處理它的過程中我想更改一些更改。
首先，介紹一點歷史。 EventPress 歸 HotPress Media 所有，之所以成立是因為客戶需要一個簡單的解決方案來管理事件 RSVP，以取代他們的 Excel 電子表格。 EventPress 的第一個版本很醜。沒有規範，我們在沒有適當計劃的情況下運行了該項目，最終得到了一大碗意大利麵。但它奏效了，並幫助我們踏入了南非最大的公司之一的大門。
版本 2 是一個巨大的飛躍。我們在介面方式上沒有太大的改變，但是底層框架卻發生了很大的變化。 EventPress 被遷移到 Laravel（當時的版本 5），儘管版本 1 中的許多程式碼都轉移到了版本 2，但結構要好得多，我們遇到的問題也少得多。那時我們仍然沒有任何類型的測試套件，我們基本上是在「它可以在我的機器上運行」的基礎上進行測試。不太好。
版本 3 對 UI 進行了徹底修改，Tailwind 成為首選 CSS 框架。儘管仍然有相當多的版本 1 程式碼隱藏在黑暗的角落，但大量程式碼已被更改。第 3 版的一個重大變化是全新的分發系統。在此過渡期間，我們學到了很多關於發送群發郵件的知識。
許多面向大眾的 UI 都是版本 2 的直接副本。即使現在，與會者看到的大部分內容仍然是版本 2 的程式碼。相反，版本 3 為程式碼庫帶來了更多的結構。某種邏輯開始出現。我們編寫了瘦控制器並嚴重依賴服務容器。版本 3 也是 EventPress 第一個有測試套件的版本。
我寫 PHP 程式碼已經很久了，但我是自學的。 EventPress 就像被扔進了深淵，沒有任何關於如何游泳的指導。這是一個巨大的學習曲線，但它讓我達到了今天的水平。我自己建立了這個東西，其他開發人員的投入很少。
這次，我將透過部落格記錄 EventPress 4 的開發過程。不是因為我要尋求認可，而是因為我想把這次記錄下來。也許我的解決方案可以幫助其他獨立開發人員。我學到了很多關於建立和運行大型 PHP 應用程式的知識。
EventPress 4 將進行大規模重寫。儘管大量 EventPress 3 程式碼最終會出現在版本 4 中，但它不僅僅是複製貼上。我覺得是時候最終擺脫自版本 1 以來一直存在的所有陳舊內容了；我想要一個更強大的測試套件；我想利用一些更新的技術。
我的計劃是在解決這個問題時每月至少寫一次東西。我會努力強迫自己堅持下去。
所以首先，投入戰鬥......
EventPress 4 將不會獲得新的 UI。我們將使用版本 3 中的幾乎所有介面，並且可能只是進行一些細微的更改。 EventPress 的 UI 是使用 Vue 3 和 Tailwind 建構的，而 Inertia 是我們選擇的黏合劑。
EventPress 4 將是版本 3 的一對一功能副本。這意味著隨著版本 3 在未來幾個月內不斷發展，版本 4 也需要隨之發展。不過，目前還只是一些計畫。
首先，我研究了版本 3 仍在努力的地方，並就如何在版本 4 中改進這些元素做了一些筆記。我已經建立了一個關於如何建立此版本的想法事件出版社。有一些熟悉的東西和一些全新的東西：
我知道其中有一些有趣的選擇。辛烷值對我們來說很重要，因為我們以前從未使用過類似的東西。 Octane 是 Laravel 的第一方包，可協助您在 PHP 應用程式伺服器上執行應用程式。支持 Swoole、RoadRunner 和 FrankenPHP。我們研究了所有三個選項，並暫時決定使用 FrankenPHP。它比其他兩個更新，但提供了非常好的性能。 Swoole 提供了並發工作線程，這很好，但不是我們認為自己需要的。然而，問題在於它需要安裝 Swoole 擴充功能。這不是我們期望企業客戶做的事情。我也有一些使用 FrankenPHP 的經驗，所以這是有道理的。
我們已經使用 Nginx 多年了。它太棒了，我強烈推薦它。然而，FrankenPHP 附帶了它自己的 Caddy 伺服器，因此我們也正在對此進行試驗。我們可能不會堅持使用 Caddy，但現在，它在清單中。
PHP 8.4 尚未發布，但由於 EventPress 4 暫時不會發布，因此我們開始使用最新版本是有意義的。截至撰寫本文時，PHP 8.4 距離發布還有大約一個月的時間，因此我們正在使用最新的候選版本。
InertiaJS 2 的情況大致相同。它也處於測試階段，但由於我們距離發布還有很長的路要走，它可能會在 EventPress 之前很久就發布。此外，我們在 BETA 版本中運行了 InertiaJS 1 很長時間，沒有出現任何問題。
我是最近的靜態分析轉換者。我用得最多的是 PHPStorm 為我提供的我編碼的東西。對於 EventPress 4，我們決定全力以赴，將 PHPStan 納入其中。 PHPStan 是 PHP 的第三方靜態分析器。它的配置非常簡單，並幫助我消除了許多其他項目中的一些錯誤。
基於 EventPress 的大小，這裡也很有意義。為了完成這項工作，我新增了一個 test:types Composer 腳本，我可以隨時執行該腳本，並將其新增至 CI 腳本。
我從未運行過 PHP 程式碼 linter。我使用過 PHP Mess Detector 幾次，但從未真正投入其中。對於 EventPress 4，我們決定使用 linter 來幫助保持程式碼整潔和一致。我們選擇了 Laravel 自己的“Pint”，它實際上只是 PHP-CS-Fixer 的包裝器，並提供了一種非常簡單的方法來保持程式碼整潔。再次，我添加了 lint 和 test:lint Composer 腳本以使其更易於運行。
在開發過程中我在 Mac 和 Linux 機器上工作。我的辦公桌上有一台 M1 Max，已經用了好幾年了，辦公室裡還散佈著幾台 Linux 機器。我的主要驅動程式是 Mac，我的大部分開發工作都是在 Mac 上進行的，但我的所有程式碼都在 Linux 機器上運行。通常是 Ubuntu 伺服器。
EventPress 4 為這個難題添加了一些新的部分，但我認為在大多數情況下我可以繼續按照目前的方式進行開發。我使用 Homebrew 安裝大部分工具，使用 Laravel Valet 運行本地開發環境。我不是Laravel Herd 用戶（這很好，但我更像是Herd Pro 用戶，我無法證明每年花費99 美元購買一個可以完成我已經可以做的所有事情的工具，只是速度更快一點，並且包含在一個漂亮的使用者介面）。
所以我的計畫是在我的本機電腦上執行一個使用 MySQL 資料庫運行的 eventpress4.test 網域。我將在早期開發過程中使用此狀態一段時間，並每隔幾天左右使用 Octane 進行一些測試。一旦我們完成了早期部分，我們將開始更頻繁地使用 Octane 進行開發。我們將託管一個運行該應用程式的測試伺服器，因為我們希望它在生產中運行。
EventPress 從未被容器化。然而，EventPress 4 很可能會走這條路。我們仍在嘗試一些事情，但我們已經與一些企業客戶進行了交談，我們認為這將有助於使他們的部署過程變得更加容易。我們在 Docker 容器中執行 EventPress 3 進行了一些早期測試，我們認為這對於未來所有 EventPress 版本來說都是正確的舉措。
多年來，我們一直嚴重依賴 GitLab 作為我們選擇的 CI/CD 服務。 GitLab 運行許多複雜的 CI 管道，並為我從事的幾乎每個專案進行部署。
不過，我也已經是 GitHub 用戶很多年了。我主要將它用於我的開源工作，但最近開始將一些較小的專案轉移到付費 GitHub 帳戶，這給我留下了深刻的印象。有一些事情與 GitLab 的工作方式非常不同，但在大多數方面我真的很高興。
因此，EventPress 4 程式碼將託管在 GitHub 上，我們將使用 Actions for 或 CI 管道以及所有部署。
我想這篇文章就到此為止了。仍有一些計劃需要完成，但我已經開始編寫一些程式碼並編寫一些測試。我已經有了一個基本的身份驗證層（感謝 Laravel），儘管其中大部分與 EventPress 3 類似。我將在下一個中展示一些程式碼。答應我！
以上是建構事件新聞第 1 部分的詳細內容。更多資訊請關注PHP中文網其他相關文章！
