很多開發者不喜歡WordPress並不是祕密。因為在他們眼裡，覺得WordPress程式碼基礎混亂。
WordPress核心程式碼真的那麼糟糕嗎？或者您應該深入瞭解，認真研究專案所需？在本文中，我們一起來研究這個問題，以幫助站長或者開發者們捋清思路。
什麼是糟糕的程式碼？
最根本的問題是，我們很難對一個已經存在的程式程式碼直接一錘定音。諸如“一團糟的程式碼”之類的聲音聽起來很可怕，但這對於一般站長來說這意味著什麼？更重要的是，他/她在乎嗎？
有一些屬性可能會使程式碼變得“糟糕”，以下是其中一些：
- 未優化的程式碼與優化的程式碼相比執行速度較慢
- 在專案中混合編碼風格
- 只有作者才能理解的麵條式程式碼（Spaghetti code）
- 不可擴充套件的，與其他程式碼相容不夠好
WordPress確實犯了其中一半的罪行。毫無疑問，各色各樣的編碼風格。函式名稱不一致，某些模組使用嚴格的面嚮物件語言，某些模組使用程序導向語言，許多檔案不使用WordPress自己的樣式指南，這些僅僅是其中的一些問題。
也就是說，WordPress在某種程度上使用了麵條式程式碼，但除了令人討厭之外，這不是一個問題，因為作為一款用途廣泛的產品，成千上萬的人都理解它。
那麼WordPress編碼是否很糟糕？是的，就像國際空間站使用劣質膝上型電腦一樣。兩種說法在客觀上都是正確的，但幕後還有很多其他的東西。
真正的問題是，這有關係嗎？
程式設計人員不要緊
在每個WordCamp上，經常會出現同一個問題：如果WordPress切換到完全OOP方法會很好嗎？部分程式設計師說，當然可以，那將是我一生中最快樂的一天。理性的人（絕對不是程式設計師）鼓吹謹慎，因為此舉將直接牴觸WordPress所代表的一切。
作為程式設計師，我們必須記住，歸根結底，WordPress是針對使用者而非我們的。您可能會認為在一個專案上花費100多個小時會很多，但是使用您的工作的人每天可能會花費8個小時來使用該專案，一年總計達3,000多個小時，並且使用者不僅僅只有一個人。
使用者不在乎
使用者真的不在乎與程式碼相關的任何東西。他們想要一種使用者友好，快速且安全的東西。WordPress在這三個方面都做得很好。或者你可以辯解說，編碼糟糕的外掛可能會破壞WordPress的速度和安全性，但這就像說沃爾沃汽車不安全，是因為我以180公里/每小時撞牆。
編碼器不受影響
絕大多數使用WordPress的人都不受此問題的影響，或者至少不必受此問題的影響。根本就沒有需要觸及專案核心程式碼的情況。這意味著您完全不會受到核心程式碼混亂的影響。
程式設計師唯一可以反對WordPress的論點是它沒有遵循MVC（模型-檢視-控制器）架構。這是一個完全有效的批評，但並不是說MVC是編寫乾淨程式碼的唯一方法。
實際上，您可以在外掛中使用完全物件導向的方法，如果願意，甚至可以使用類似MVC的結構。真正的問題在於主題的構建方式，而不能僅僅注入MVC原理。
就是說，儘管不是MVC，但主題遵循嚴格的準則並且結構合理。這歸結為每個主題的共同點，如果您知道自己在做什麼，就可以輕鬆地與WordPress協作了。
可以編寫良好的程式碼嗎？
問題不在於WordPress核心程式碼的好壞。WordPress核心程式碼有些混亂，但仍然是不錯的程式碼。這並不意味著它不能得到很大的改進，但就其目的而言，它確實很棒。
問題是：是否可以使用WordPress編寫良好的程式碼。答案是肯定的。正如我前面提到的，外掛是自由格式的，因此您可以在其中做任何您想做的事情，包括OOP。
我還想強調一點，OOP並不是萬能的。對於簡單的外掛，一種佈局合理的程式方法可能會更清晰。
主題確實將演示與邏輯結合在一起，這無疑是一個壞習慣。但是，主題的指南佈局合理，通過一些規劃，您可以編寫一個合理且易於理解的主題。
隨著WordPress API的問世，所有其他批評都無濟於事，因為您幾乎可以在任何地方使用資料庫中的資料。您可以使用Laravel進行所有操作，並通過WordPress API提取資料。
小結
因此，歸根結底，WordPress程式碼是否一團糟？是的，其中一些是。某些外掛和主題確實確實包含錯誤的程式碼，並對整個社羣造成影響。像任何其他專案一樣，WordPress也不是完美的。就像任何其他專案一樣，我也認同WordPress不可能做到適合於所有專案。
但是，不使用WordPress是因為“程式碼太亂了”，這是顯而易見的，是愚蠢且短視的行為。儘管核心程式碼有些混亂，但它是快速且安全的。以此為基礎擴充套件系統的任何程式碼都可以很好地編寫。
訣竅是採用程式碼編寫規範的主題或者外掛，或者聘請合格的WP開發，使用可信賴的高質量產品並正確維護您的網站。
評論留言