Влияние на производительность с «чистым кодом»

Question

На моем рабочем месте мы планируем крупный рефакторинг нашего основного продукта - веб-приложение с несколькими «модулями». Я процитировал это, потому что это одна из наших главных проблем: модули на самом деле не являются модулями, все это монолитно. Приложение написано на PHP с умными шаблонами и использует Pear для доступа к базе данных MySQL. На самом деле нас не беспокоит независимость от базы данных, хотя было бы неплохо, если бы это не заняло бы месяцы.

Наша основная проблема заключается в том, что время / стоимость разработки увеличивается в геометрической прогрессии из-за ошибок, возникающих в несвязанных местах, и из-за отсутствия общей архитектуры, на которую можно полагаться, чтобы получить наиболее распространенную функциональность (каждый модуль в основном копируется / вставляется из предыдущего один, то адаптируйся).

У меня есть некоторый опыт работы с принципом веб-MVC, главным образом в ASP.NET MVC. Мне нравится чистое разделение и тестируемость. Однако при попытке сделать это на локальном компьютере приложение работает намного медленнее, чем должно быть.

Хорошо, достаточно введения, чтобы ответить на вопросы: - Стоит ли полагаться на модули кеширования? Это удаляет большую часть накладных расходов, используя хорошую архитектуру? Что-то вроде APC.

• Приложение в основном читается. Запись в основном отдельных значений (изменить одно поле в записи). Любой OR / M для PHP, которые хороши в этом?
• Также ищем гибкий MVC-фреймворк. Я знаю Zend, CakePHP, может Symfony?

Сложность в том, что у нас нет такой роскоши, как возможность полностью переписать. Нам придется постепенно улучшать очень грязную кодовую базу. Это должно быть сделано во время написания нового кода или исправления ошибок. Одна вещь, которую я действительно, ДЕЙСТВИТЕЛЬНО хотел бы иметь, это написать регрессионный тест для новой ошибки перед ее исправлением, чтобы предотвратить ее повторное появление позже (это иногда случается).

Стек, который я сейчас рассматриваю, содержит:

• MVC рамки выбора
• Ведение журнала (log4php?)
• ИЛИ / М по выбору (не обязательно должен быть динамическим, генерация кода тоже подойдет)
• Контейнер IoC на выбор
• Smarty Templating, возможно, абстрагированный, так что мы можем его отключить, если потребуется.
• Кэш Opcode по выбору (мы используем один сейчас, забыл, какой, нужно спросить sysadmin)

Главное, что меня беспокоит, это влияние на производительность создания чистого кода на PHP. Видя, что это анализируемый язык, а не что-то вроде веб-стека .NET / Java, создание абстракций для другого встроенного кода (с обязательным разделением в разных файлах) может создать новые проблемы на другом уровне.

---

Примечание. Повторно помечайте, если вы найдете более подходящие теги, я не уверен в текущих.

Answer 1

Чистая настройка обычно не является проблемой производительности. Большая часть производительности тратится на базы данных или другие внешние системы, с которыми вы разговариваете.

Кроме них, как правило, есть одна или две точки доступа, которые, возможно, стоит оптимизировать, но для этого следует начать с чистого дизайна, а затем использовать профилировщик (например, XDebug или ZendDebugger) для выявления узких мест.

Чистый дизайн программного обеспечения намного важнее, чем прирост производительности на 0,01% благодаря «оптимизированному» дизайну. Обычно даже дешевле покупать и использовать больше оборудования, чем беспокоиться об «оптимизированной» кодовой базе, которая не поддерживается.

Answer 2

Что касается управления компонентом MVC с помощью компонента спагетти-кода, у нас была похожая проблема с большим проектом. Что работало хорошо, так это просто взять каталог и сделать так, чтобы новый docroot для приложения MVC (Zend Framework в нашем случае) был таким, чтобы:

старая часть:
http://site.com/data.php
http://site.com/other.php

новая часть: http://site.com/app/controller/action/...

Повторная аутентификация, у вас есть несколько вариантов. Вероятно, наиболее логичным является перенаправление вашего скрипта login.php в логин MVC, а затем передача его обратно на исходную страницу, на которую вы хотите перейти, с необходимой информацией, передаваемой в качестве параметра GET. Это позволит одновременно и прозрачно существовать и новым системам одновременно.

В связи с медлительностью, прежде чем вытащить XDebug, я бы попытался выделить проблемную часть и просто вывести время, необходимое для этого. Быстрее ИМХО.

Answer 3

Я бы выделил время на составление тестов со следующими аргументами для руководства:

1. Когда разработчики исправят ошибку, разрешите им написать тест на ошибку. Ошибки повторяются намного чаще, чем они, вероятно, должны, и это дешевый и эффективный способ полностью остановить это.
2. Когда разработчики создают новую функциональность, разрешите им писать тесты под ней. Поскольку они полностью знакомы с функциональностью на тот момент, это самое дешевое время для создания «сети безопасности» автоматизированного тестирования.

Не конфетка, сколько времени займет у вас тестирование; будь то 1% вашего времени или 50%, отдайте это менеджеру прямо, но подчеркните, что построение автоматизированного тестирования в качестве системы безопасности не даст пользователям обнаружить столько ошибок и сэкономит время разработчика для новой разработки вместо исправления ошибок.

Answer 4

Нет веской причины, по которой хорошо структурированный объектно-ориентированный код должен работать значительно хуже, чем код sapghetti php в веб-приложении, управляемом базой данных. Вам нужно выполнить некоторое профилирование, чтобы найти узкие места и соответственно оптимизировать.

Answer 5

У вас сложная (но не редкая) ситуация.

Что касается организации кода для минимизации ошибок, все, что я могу дать, - это верхушка DRY.

Что касается проблем с производительностью, их легко найти, потому что их очень медленно показывает вам с помощью этой техники .