有效收集有关新 PHP 项目内部运作的信息。工具?技巧?脚本?

发布于 2024-10-26 11:47:13 字数 2077 浏览 1 评论 0原文

我即将加入一个已经开发了几年的 PHP 项目。它将是巨大的、稀疏的文档、许多文件、成堆的代码,并且不能期望一致的质量水平。

您将如何收集尽可能多的有关正在发生的事情的信息?

  • 预计不会自动加载,位于 至少不是广泛的,所以 包含可能会做得很好 揭示相互依赖性。

  • phpDocumentor消化 项目文件可能会给出一个想法 关于哪些类/方法/函数 存在。

  • 也许phpCallGraph 方法/函数关系。

  • 分析一些通用用例 XDebug 了解有关 层次结构和概念。

  • 检查重要的日志文件... 检查警告,已弃用 用法、错误。

  • phpinfo()

  • 也许提取所有评论并 将它们处理成一个 html 文件。

没有涵盖单元测试、数据库……

你会做什么?您对上述工具的充分利用有何经验?

您可以假设任何必要的条件。

提取哪些统计信息可能有用?

有人使用这些工具的经验吗?

编辑来自“用于质量检查的PHP工具”

编辑 2 来自 Bryan Waters 的回答:

为 PHP 项目设置部署/构建/CI 周期 - Pekka 建议

编辑 3

只是找到了 Gabriele 演讲的 PDF Santini - “代码的统计分析 - 听听你的 PHP 代码”。这就像一座金矿。

I am soon to join a PHP project that has been developed over the course of several years. It's going to be huge, sparsely documented, many files, piles of code, no consitent quality level is to be expected.

How would you go about gathering as much information as possible about what is going on?

  • Autoloading is not be expected, at
    least not extensively, so
    inclued might do a good job
    revealing the interdependencies.

  • Having phpDocumentor digest the
    project files might give an idea
    about which classes/methods/functions
    are present.

  • Maybe phpCallGraph for
    method/function relations.

  • Profiling some generic use cases with
    XDebug to gain an idea about the
    hierarchies and concepts.

  • Inspecting important log-files ...
    checking out warnings, deprecated
    usages, errors.

  • phpinfo().

  • Maybe extracting all comments and
    process them into a html-file.

Didn't cover Unit-Tests, Databases, ....

What would you do? What are your experiences with mentioned tools to get the most out of them?

You can assume any condition necessary.

What statistical information could be useful to extract?

Has somebody experience with those tools?

EDIT from "PHP Tools for quality check":

EDIT 2 from Bryan Waters' answer:

Setting up a deployment / build / CI cycle for PHP projects - suggested by Pekka

EDIT 3

Just found this PDF of a talk by Gabriele Santini - "Statistical analysis of the code - Listen to your PHP code". This is like a gold mine.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

可是我不能没有你 2024-11-02 11:47:14

我同意你的问题确实有大部分答案。

这就是我可能会做的。
我可能会从 Sebastian Bergman 的工具开始,尤其是 phploc,这样您就可以了解您正在查看的混乱(代码库)的范围。它为您提供类、函数计数等,而不仅仅是代码行。

接下来,我会查看 apache 日志或 google 分析并获取请求最多的 10 个 php url。我将使用分析来设置 XDebug,并运行前 10 个请求并获取文件、调用树。 (您可以使用cachegrinder工具查看这些)

最后,我会通读其中一两个跟踪的整个执行路径,这是最有代表性的整体。我会使用我的 Eclipse IDE,但将它们打印出来并用荧光笔去城里也是有效的。

如果有多个系统拼凑在一起,那么前 10 种方法可能会失败。您应该可以使用 Xdebug 快速查看前 10 个岛屿的编码是否相似(如果每个岛都是一个独特的岛屿)。

我会查看 mysql 数据库并尝试了解它们的用途,特别是查看表前缀,您可能有几个不同的应用程序堆叠在一起。如果数据库中有很大一部分未被前 10 个应用程序触及,则您需要寻找子应用程序。如果您发现其他子应用程序通过 xdebug 分析器运行它们,然后通读代表该子应用程序的路径之一。

现在返回并查看 phploc 中的范围编号,看看在您的审查期间代码库(可能计数类或函数)的百分比未受影响。

您应该对最常运行的代码有基本的了解,并了解有多少个角落、缝隙和壁橱用于骨架存储。

I agreee that your question does have most of the answers.

This is what I would probably do.
I would probably start with Sebastian Bergman's tools, especially phploc so you can get an idea of the scope of the mess (codebase) you are looking at. It gives you class, function counts, etc not just lines of code.

Next I would look in the apache logs or google analytics and get the top 10 most requested php url's. I'd setup XDebug with profiling and run through those top 10 requests and get the files, call tree. (You can view these with a cachegrinder tool)

Finally, I'd read through the entire execution path of 1 or two of those traces, that is most representative of the whole. I'd use my Eclipse IDE but print them out and go to town with a highlighter is valid as well.

The top 10 method might fail you if there are multiple systems cobbled together. You should see quickly with Xdebug whether the top 10 are coded similarliy are if each is a unique island.

I would look at the mysql databases and try to understand what they are all for, espacially looking at table prefixes, you may have a couple of different apps stacked on top of each other. If there are large parts of the db not touched by the top 10 you need to go hunting for the subapps. If you find other sub apps run them through the xdebug profiler and then read through one of the paths that is representative of that sub app.

Now go back and look at your scope numbers from phploc and see what percentage of the codebase (probably count classes, or functions) was untouched during your review.

You should have a basic understanding of the most often run code and and idea of how many nooks and crannies and closets for skeleton storage there are.

冰雪之触 2024-11-02 11:47:14

也许您可以建立一个持续集成环境。在这种环境中,您可以收集您想要的所有统计数据。

Jenkins 是一个优秀的 CI 服务器,带有大量插件和文档。

Perhaps you can set up a continuous integration enviroment. In this enviroment you could gather all the statistics you want.

Jenkins is a fine CI server with loads of plugins and documentation.

无可置疑 2024-11-02 11:47:14

为了检查可能出现的问题(重复代码、潜在错误...),您可以使用其中一些工具:

https://stackoverflow.com/questions/4202311/php-tools-for-quality-check

HTH

PS。我不得不说,在我看来,你的问题已经包含了很多很好的答案。

For checking problems which could be expected (duplicate code, potential bugs...), you could use some of those tools:

https://stackoverflow.com/questions/4202311/php-tools-for-quality-check

HTH

PS. I Have to say that your question, IMO, contains already a lot of great answers.

玩物 2024-11-02 11:47:14

如果您对统计感兴趣,请查看 CRAP 索引(变更风险分析和预测),它衡量代码质量。

有一篇由两部分组成的不错的介绍性文章:

第一部分
第二部分

If you're into statistical stuff, have a look at the CRAP index (Change Risk Analysis and Predictions), which measures code quality.

There are a two-part nice introductory article:

First part
Second part

回忆那么伤 2024-11-02 11:47:14

由于构建了巨大的意大利面条般的遗留 PHP 项目,并且遭受了这些项目的困扰,我认为使用分析工具只能做这么多。他们中的大多数人只会告诉您该项目的质量很糟糕:)

单元测试和源代码文档工具通常需要在代码中进行一些积极的贡献才能产生可​​用的结果。也就是说,它们肯定都值得尝试 - 我不熟悉 phpCallGraph 和 Sebastian Bergmann 的工具。此外,phpDocumentor 或许能够理解至少部分代码。 PHPXref 也是一个很酷的概览工具,这里是一个(缓慢的)演示。

最好的开始方法可能只是执行一个需要在代码库中完成的简单任务,然后在丛林中奋力拼搏,遵循包含内容,尝试掌握库结构等,直到完成工作。如果您要加入团队,也许附近有人可以寻求指导。

我会专注于让探索过程尽可能方便。一些(琐碎的)要点包括:

  • 使用可以快速引导您进行函数/方法、类和变量定义的 IDE

  • 运行调试器

  • 绝对将所有内容置于源代码控制下并提交每个更改

  • 拥有一个允许您轻松部署更改以进行测试,并轻松切换到不同的分支或完全回滚所有内容。这是有关如何设置类似内容的相关问题: 为 PHP 项目设置部署/构建/CI 周期

Having both built, and suffered from, huge spaghetti-y legacy PHP projects, I think there is only so much you will be able to do using analysis tools. Most of them will simply tell you that the project is of terrible quality :)

Unit Testing and source code documentation tools usually need some active contribution inside the code to produce usable results. That said, they all are surely worth trying out - I'm not familiar with phpCallGraph and Sebastian Bergmann's tools. Also, phpDocumentor may be able to make some sense out of at least parts of the code. PHPXref is also a cool tool to get an overview, here's a (slow) demo.

The best way to start could be just taking a simple task that needs to be done in the code base, and fight your way through the jungle, follow includes, try to grasp the library structure, etc. until the job is done. If you're joining a team, maybe have somebody nearby you can ask for guidance.

I would concentrate on making the exploring process as convenient as possible. Some (trivial) points include:

  • Use an IDE that can quickly take you to function/method, class and variable definitions

  • Have a debugger running

  • Absolutely keep everything under source control and commit every change

  • Have an environment that allows you to easily deploy a change for testing, and as easily switch to a different branch or roll everything back altogether. Here is a related question on how to set something like that up: Setting up a deployment / build / CI cycle for PHP projects

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文