“干净代码”对性能的影响
在我的工作场所，我们计划对我们的核心产品（一个具有多个“模块”的 Web 应用程序）进行重大重构。我引用这一点是因为这是我们主要关心的问题之一：模块并不是真正的模块，整个事情是整体的。该应用程序是用 PHP 编写的，带有 smarty 模板，并使用 Pear 访问 MySQL 数据库。我们并不真正关心数据库独立性，尽管如果不需要花费几个月的时间来实现那就太好了。
我们主要担心的是，开发时间/成本呈指数级增长，因为错误在不相关的地方突然出现，并且没有一个健全的通用架构来依赖来获得最常见的功能（每个模块基本上都是从前一个模块复制/粘贴，然后适应）。
我对 Web MVC 原理有一些经验，主要是 ASP.NET MVC。我喜欢它提供的清晰分离和可测试性。然而，当在本地计算机上尝试此操作时，该应用程序比应有的速度要慢得多。
好了，介绍够了，接下来回答问题： - 我应该依赖缓存模块吗？这是否可以使用良好的架构消除大部分开销？类似APC之类的。
- 主要是阅读应用程序。写入主要是单个值（更改记录上的单个字段）。有擅长此方面的 PHP OR/M 吗？
- 也在寻找灵活的MVC框架。我知道 Zend、CakePHP，也许还有 Symfony？
棘手的部分是我们没有能力进行完全重写。我们必须逐步改进当前非常混乱的代码库。这必须在编写新代码或修复错误时完成。我真的非常希望能够做的一件事是在修复新错误之前为它编写一个回归测试，以防止它稍后再次出现（这种情况偶尔会发生）。
我目前正在考虑的堆栈包含：
- 选择的 MVC 框架
- 日志记录（log4php？）
- 选择的 OR/M（不必是动态的，代码生成也可以）
- 选择的 IoC 容器
- Smarty 模板，也许是抽象的，所以我们如果需要的话可以把它关掉。
- 选择的操作码缓存（我们现在使用一个，忘记是哪一个，必须询问系统管理员）
我担心的主要一点是在 PHP 中创建干净代码的性能影响。鉴于它是一种与 .NET/Java Web 堆栈之类的语言相反的解析语言，为其他内联代码创建抽象（在不同文件中强制分隔）可能会在另一个层面上产生新问题。
注意：如果您想出更合适的标签，请重新标记，我不确定当前的标签。
At my workplace we're planning a major refactor on our core product, a web application with several 'modules'. I quoted that because that's one of our main concerns: modules are not really modules, the whole thing is monolithic. The application is written in PHP with smarty templating and using Pear for accessing a MySQL database. We're not really concerned with database independence, although it would be nice if that wouldn't take months to implement.
Our main concerns are that development time/cost is increasing exponentially because of bugs popping up in unrelated places and not having a sound common architecture to rely on to get the most common functionality (each module is basically copy/paste from the previous one, then adapt).
I've got some experience with the web MVC principle, mainly in ASP.NET MVC. I like the clean separation it offers and the testability. However, when trying this on a local machine the app is simply a lot slower than it should be.
Alright, enough introduction, off to the questions:
- Should I rely on caching modules? Does this remove most of the overhead using a good architecture provide? Something like APC.
- The application is mainly read. Writing is mainly single values (change a single field on a record). Any OR/M for PHP that are good at this?
- Also looking for a flexible MVC framework. I know Zend, CakePHP, maybe Symfony?
The tricky part is that we don't have the luxury of being able to do a full rewrite. We'll have to incrementally improve a currently very messy codebase. This has to be done while writing new code, or fixing bugs. One thing I'd really, REALLY like to be able to do is write a regression test for a new bug before fixing it, to prevent it from popping up again later (this happens, occasionally).
The stack I'm currently considering contains:
- MVC framework of choice
- Logging (log4php?)
- an OR/M of choice (doesn't have to be dynamic, code generation is fine too)
- IoC container of choice
- Smarty Templating, perhaps abstracted so we can switch it out if we need to.
- Opcode cache of choice (we're using one now, forgot which one, have to ask sysadmin)
The main point that worries me is the performance implications of creating clean code in PHP. Seeing it's a parsed language opposed to something like the .NET/Java web stack, creating abstractions for otherwise in-line code (with obligatory separation in different files) might create new problems on another level.
Note: Retag if you come up with more appropriate tags, I'm not sure on the current ones.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
通常，干净的设置不是性能问题。大部分性能都花在了数据库或您正在使用的其他外部系统上。
除了这些之外，通常还有一两个热点可能值得优化，但为此您应该从干净的设计开始，然后使用分析器（如 XDebug 或 ZendDebugger）来识别瓶颈。
干净的软件设计比“优化”设计带来的 0.01% 性能增益重要得多。通常，购买和运行更多硬件比担心无法维护的“优化”代码库更便宜。
Having a clean setup isn't a performance issue, usually. Most performance is spent with databases or other external systems you're talking to.
Except for these there are usually one or two hotspots which might be worth optimizing but for that you should start with a clean design, then use a profiler (like XDebug or ZendDebugger) to identify the bottlenecks.
A clean software design is way more important than the 0.01% performance gain by a "optimized" design. Usuallyit's even cheaper to buy and run more hardware than worry about an "optimized" codebase which is unmaintainable.
我会强调预算时间来构建测试，并向管理层提出以下论点：
不要粉饰测试需要多长时间；无论是 1% 还是 50%，直接交给经理，但强调将自动化测试构建为安全网将阻止用户遇到尽可能多的错误，并将节省开发人员进行新开发而不是修复错误的时间。
I'd stress budgeting time to build tests, with the following arguments to management:
Don't candy coat how long testing will take you; whether it's 1% of your time or 50%, give that to the manager straight, but stress that building automated testing as a safety net will stop users from hitting as many bugs, and will save developer time for new development instead of bugfixing.
至于使用意大利面条代码组件管理 MVC 组件，我们在大型项目中遇到了类似的问题。效果好的方法是获取一个目录并为 MVC 应用程序（在我们的例子中是 Zend Framework）创建新的文档根目录，这样：
旧部分：
http://site.com/data.php
http://site.com/other.php
新部分：
http://site.com/app/controller/action/...
重新身份验证，你有几个选择。也许最合乎逻辑的是将您的 login.php 脚本重定向到 MVC 登录，然后将其传递回您想要的原始页面，并将必要的信息作为 GET 参数传递。这将允许旧系统和新系统同时且透明地存在。
关于缓慢，在我拉出 XDebug 之前，我会尝试隔离有问题的部分并仅输出它所需的时间。恕我直言，更快。
As far as managing an MVC component with a spaghetti code component, we had a similar issue with a large project. What worked well was just taking a directory and making that the new docroot for MVC app (Zend Framework in our case) such that:
old part:
http://site.com/data.php
http://site.com/other.php
new part:
http://site.com/app/controller/action/...
Re authentication, you have a couple of choices. Probably the most logical is to redirect your login.php script to the MVC login and then pass it back to the original page that you want to go with necessary info passed as a GET parameter. This will allow legacy and new systems to exist simultaneously and transparently.
Re slowness, before I would pull out XDebug, I would try to isolate a problematic part and just output times it takes. Faster IMHO.
没有任何充分的理由表明，在数据库驱动的 Web 应用程序中，结构良好的面向对象代码的性能应该比 sapghetti php 代码差得多。您需要进行一些分析以找出瓶颈所在并进行相应优化。
There isn't any good reason that well structured object oriented code should perform significantly worse than sapghetti php code in a database driven web application. You need to do some profiling to find where your bottlenecks are and optimize accordingly.
您确实遇到了困难（但并不罕见）的情况。
至于组织代码以尽量减少错误，我所能给出的只是 DRY 的提示。
对于性能问题，这些很容易找到，因为它们非常缓慢地向您展示它们，通过这种技术。
You do have a tough (but not uncommon) situation.
As far as organizing the code to minimize bugs, all I can give is a tip of the cap to DRY.
For performance issues, those are easy to find, because their very slowness shows them to you, by this technique.