После завершения XHTML, проекта CSS, мы должны попытаться оптимизировать наш код? - PullRequest
0 голосов
/ 20 марта 2010

После завершения XHTML, проекта CSS и клиента Even я должен попытаться оптимизировать свой код HTML, CSS, если есть какая-либо область?

Если да, то как еще можно улучшить и оптимизировать код и какие вещи можно / нужно оптимизировать?

Должен ли я оптимизировать, чтобы получить наименьший размер файла, или я должен оптимизировать код для лучшей читаемости?

Ответы [ 5 ]

4 голосов
/ 20 марта 2010

Я бы посоветовал взглянуть на Yahoo!YSlow и Google Page Speed ​​.Они дадут вам гораздо лучшие советы по повышению производительности, чем оптимизация HTML / CSS.

3 голосов
/ 20 марта 2010

По моему опыту, большие "оптимизации" после факта имеют тенденцию приносить больше вреда, чем пользы. Если клиент доволен, очевидных проблем с масштабируемостью нет, а код более или менее удобен в обслуживании, не беспокойтесь об этом. Кроме того, нет особых причин оптимизировать скорость работы HTML / CSS, поскольку узкое место почти всегда связано с подключением к вашей базе данных, а общий размер загрузки текстовых файлов в любом случае зачастую относительно невелик. Если вам ДЕЙСТВИТЕЛЬНО нужно, чтобы они были меньше, посмотрите на автоматическое сжатие.

Лично, если бы я был тобой, я бы просто сделал это и ушел.

2 голосов
/ 20 марта 2010

Я бы выбрал удобочитаемость, а не оптимизацию размера файла, чтобы у следующего человека, который откроет файлы HTML / CSS, не было плохого дня.

2 голосов
/ 20 марта 2010

Я думаю, вам следует рассмотреть следующие действия в следующем порядке:

  1. Обзор производительности: рассмотрите, как вы и ваша команда могли бы лучше работать над проектом, чтобы быстрее создать лучший продукт. Области мозгового штурма, которые были препятствиями, которых можно было бы избежать, и как их избежать в следующий раз.
  2. Аудит безопасности: анализ системы на наличие потенциальных уязвимостей. Как гласит пословица, «100 атакующих уничтожаются всего лишь одним« ооо! ». Ошибки безопасности, как правило, относятся к таким видам упущений.
  3. Документация: предоставьте документацию, которая понадобится технологической группе для ускорения работы приложения, когда они появятся через 18 месяцев, чтобы добавить новые функции.
  4. Профессиональное развитие: повышайте свои навыки в какой-то области, чтобы вы могли быть столь же успешными в вашем следующем проекте, как и в этом.
  5. Иди домой пораньше: Wii, XBox, управляй воздушным змеем, жарь гамбургер, делай все, что хочешь, и будь счастлив, что ты хорошо поработал над этим проектом.

Всего лишь мои 0,02 доллара. : -)

0 голосов
/ 12 августа 2010

Зависит от того, насколько счастлив клиент, я полагаю, и вероятности того, что он станет постоянным клиентом, если это ваша цель для проекта.

Если бы ни здесь, ни там, я бы не стал беспокоиться. Слишком много хлопот, и нет повторного использования. единственное исключение было бы, если бы его явно плохой sql, который был взломан, чтобы «заставить его просто работать», который часто используется, или тяжелые анимации javascript, я бы шел дальше и начинал новый проект как можно скорее после проверки успеха того, кем вы являетесь собирается завершить.

Если вы измените код - вам нужно будет повторно протестировать его.

почему бы не потратить это время на тестирование?

Вы можете получить больше пользы от рефакторинга кода для собственного использования (если это возможно).

Если вы довольны выполнением всех требований - передайте проект клиенту раньше, чем он ожидал.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...