PHP开发CMS的常见问题与解决方法

等等，我前年接手了一个旧的 CMS 项目。
代码像垃圾山一样堆积起来。
其中一个变量名为“8 g7 h”，SQL语句直接绑定了用户输入。
结果客户端上传文件的时候，有人直接包含了PHP代码，导致服务器炸了。
当时真的是受不了了。

1 .代码质量问题 这个项目最独特的地方是功能注释，其中大部分都是空的。
还有一个标记为“尚未实现”的函数，下面是 5 00 行实际代码。
后来我们用 Laravel 进行了重构，强制每个方法都有注解，并且我们也将所有变量都改为驼峰式命名。
结果，在测试过程中发现了许多兼容性问题，并花了两周时间才完成。
现在回想起来，法规仍然非常重要。
例如，PSR-1 2 类似于交通规则。
一开始感觉很烦人，但是用了之后就习惯了。

2 安全问题 最可怕的是权限控制。
管理员可以删除所有文章，但只有编辑可以阅读它们。
结果有一天我突然发现后端变成了登录页面。
后来我们增加了一个中间件层来限制非管理员访问编辑界面，同时也使用了JWT进行单点登录。
现在，每次有人请求权限时，我都会首先说：“您是否请求发布便签的权限？”对了，他们现在用的密码还是md5 ，这实在是太可怕了。

3 性能问题 去年冬天，项目流量突然激增，服务器CPU升至3 00%，PPT后台登录停止。
当时电子表格没有索引，查询依靠扫描全表。
最慢的SQL需要3 秒才返回。
更改了Redis的索引+缓存后，母版页现在可以处理5 00次同步，但一想到每年可能还会发生6 1 8 ，我还是感到愧疚。
我现在每周五晚上都会做一次压力测试，看到监测曲线像心电图一样脉动真的很有趣。

4 可用性问题 一位顾客抱怨后台按钮太小，而另一些顾客则表示品类管理太复杂。
现在新版本已经改为拖放了，但是在测试过程中，他发现老用户双击后会崩溃，因此必须添加确认弹出窗口。
设计稿经过八次审查，最终证明最好的解决方案是添加一个“返回原始流程”按钮——尽管这显然是规范的一部分，但客户从未注意到它。
上周，有用户询问：“可以添加一键恢复默认设置吗？”我突然觉得这个要求很现实。

等等，还有别的事。
他们现在使用的作曲家是完整版本 1 .x。
当我建议升级时，O&M说“担心不兼容”。
结果上周我发现某个插件依赖的ext-phar已经被新版本的PHP弃用了，真是吓人。
现在存储库中有一个名为“不兼容风险列表”的文档，但每次更新都像引爆炸弹。
我真不知道这个工作还能持续多久。

如何使用Composer解决PHP项目中的代码质量问题？thecodingmachine/phpstan-strict-rules助你提升代码规范

哎呀，说到提高 PHP 项目的代码质量，就不得不说到 Composer 和 thecodingmachine/phpstan-strict-rules。
当我做项目的时候，这两个小工具就是我的救星。

首先，您必须通过 Composer 安装这个库。
记得使用开发模式，以免影响生产环境。
该命令是：composer require --dev thecodingmachine/phpstan-strict-rules。

然后，对于自动配置，如果你已经安装了phpstan/extension-installer，那就省心多了。
如果没有安装，则必须手动将规则文件引入到 phpstan.neon 配置文件中。
这行命令是：包括：-vendor/thecodingmachine/phpstan-strict-rules/phpstan-strict-rules.neon。

这个图书馆有很多严格的规则。
例如，对于异常处理，必须使用Exception的子类，不能直接抛出基本异常。
此外，catch 块不能为空，它必须被处理或重新抛出。
我以前也犯过这个错误，当时我不明白。

再比如，超全局变量，如$_GET、$_POST等，是不能直接使用的。
它们必须通过框架的请求/会话对象来使用。
不过，在初始化脚本中，例如index.php，您仍然可以暂时使用它。

还有条件语句。
交换机必须有一个默认分支。
建议抛出异常来处理意外值。

安装完成后，必须运行静态分析。
命令是：vendor/bin/phpstananalyze。
它会标记哪里违反了规则，并告诉你问题出在哪里，例如未处理的异常和直接使用超全局变量。

修复建议是根据提示更改代码，例如将$_GET['id']替换为框架的request对象方法。

团队协作和持续集成也非常重要。
标准必须统一。
不要说一个人应该用这个，另一个人应该用那个。
在持续集成过程中添加 PHPStan 检查，以确保代码在合并之前能够通过质量检查。

效果是代码质量提高了，维护成本降低了，协作效率也提高了。
不过，这东西也不是万能的。
有时它需要与其他工具结合使用，例如phpstan/phpstan-strict-rules或squizlabs/php_codesniffer。

总结一下，这个方法还是比较实用的，特别适合中大型团队或者长期维护的项目。

PHP 函数命名规范解读：何时使用大驼峰？

上周，一位客户问我 PHP 中的大驼峰命名法是什么意思，我向他解释了这一点。
事实上，这很有趣。
之前写代码的时候并没有太注意这些命名约定。

首先，大驼峰命名法主要是为了提高代码的可读性和一致性。
例如，在PHP中，公共函数（PublicMethods）采用驼峰式命名方式，首字母大写，后续单词的首字母也大写。
这样一看就知道这个函数是public的，可以从外部访问。

让我给你举个例子，如下所示：
php 类用户{ 公共函数 getFullName() { // 正确：大驼峰 返回 $this->firstName 。
”。
$this->姓氏； } }
请注意，尽管官方 PHP 标准（例如 PSR-1 ）没有强制要求方法名称的大小写，但大驼峰式命名方法是许多传统项目或团队约定中的做法。

再比如，类名（Class Names）也必须使用大驼峰命名法，这样才能清楚地区分类别和其他标识符。
像这样：
php 类用户配置文件{ // ... }
接口名称也使用大驼峰式大小写，有时前面带有 I 前缀，例如 IUserService。

比较驼峰命名法和驼峰命名法。
CamelCase 通常用于私有方法、变量或非公共函数。
例如：
php 私有函数计算年龄() { // 小驼峰 // ... }
帕斯卡命名法（PascalCase）将每个单词的第一个字母和第一个字母大写，用于公共函数、类和接口。

总的来说，虽然PSR标准并不严格，但大骆驼案是一种被广泛接受的做法，尤其是在需要明确区分访问权限的情况下。
类和接口必须使用驼峰命名法命名，这是 PHP 社区的常见约定。

一致性优先，因此您最好先检查项目的规范并遵循项目内的命名约定。
另外，使用 PHP_CodeSniffer 这样的工具可以帮助你自动检测命名约定，非常方便。

无论如何，这取决于你。
合理应用驼峰命名确实可以提高代码的可维护性和团队协作的效率。
我还在思考这个问题，以后可能会更深入地探讨。