很多开发者不喜欢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开发，使用可信赖的高质量产品并正确维护您的网站。
评论留言