Apr
13
|
Пару советов по созданию проектов
|
В частности я буду иметь ввиду проекты на PHP, но некоторые советы возможно применять и к другим языкам.
Сразу оговорюсь, что мои советы — не есть последней инстанцией и каждый должен включать мозг, применяя тот или иной совет и думать, почему именно так, а не иначе и возможно есть лучшие способы сделать тоже самое.
Большая часть этих советов собрана с разных источников, что-то я для себя экспериментальным путем нашел. Часть советов касается безопасности при создании веб-приложений, т.к. это один из самых сложных моментов (как на меня) для многих программистов.
Итак, мой набор советов.
- Выключайте отображение ошибок на продакшене. Очень частая ошибка, избегайте ее, незачем давать пищу для размышлений для взломщиков. На экран пользователя не должна вообще отображаться какая-либо информация о серверной части, а тем более ошибки. Сделать это можно поместив в .htaccess строку php_flag display_errors Off
- Путь на файловой системе. Не используйте никогда директив по типу define (’PATH_ROOT’, ’/hosting/bla-bla/’) . Это глупая стратегия. Каждый раз править настройки при переносе проекта на другой сервер — абсурд. Используйте «магическую константу» __FILE__ , которая моментально вернет путь к текущему файлу (допустим конфигу), от которого можно получить нужный путь к корню проекта.
- Ядро проекта. Контроллеры, модели и прочее должно лежать как минимум на уровень выше, чем часть, доступная через веб-браузер. Хорошая стратегия строить приложение так — что директория ядра и директория, указанная в DOCUMENT_ROOT — лежали на одном уровне (у меня эти папки обычно имеются как application и public). Данное разграничение призвано обезопасить проект от перезаписи файлов через уязвимость в проекте. Хорошей практикой также будет снять бит на запись от имени пользователя, под которым запущен веб-сервер.
- Загрузка файлов, изображений и т.д. Допустим, что все загружаемые файлы кладутся в папку uploads в папке public. Тогда первым делом лучше всего положить в папку uploads файлик .htaccess со следующей строкой — php_flag engine off — это поможет защититься от любителей залить бекдор через уязвимость в коде загрузки файлов на сервер. Это конечно слабая защита от загрузки бекдоров на других языках (например на перле), но «школьники» уже не пройдут. А лучше всего конечно делать безопасную загрузку, без уязвимостей. Но на всякий случай рекомендую подстраховаться таким образом — лишним не будет. Строка запрещает выполнение пхп-кода из данной папки и подпапок.
- Мультиязычность. Планируйте возможность мультиязычности еще на этапе проектирования и создания приложения, даже если это сейчас и не нужно. Это съекономит много сил и нервов, когда «вдруг» мультиязычность понадобиться, а в ядре ничего не заложено для этого. На подобные грабли в свое время наступил проект connect.ua, не повторяйте чужих ошибок
- Оптимизируйте все до того, как появятся нагрузки. Не стоит ждать, пока проект начнет тормозить под нагрузками и только тогда решать вопрос. Поставьте изначально байт-кешеры кода, например eAccelerator (или другие по вкусу), настройте кеширование на стороне клиента (хорошие советы в этом плане можно найти на webo.in) и на сервере. Это даст существенный прирост производительности (иногда порядка 300 и более процентов), что существенно снизит нагрузки и повысит скорость загрузки страниц у пользователей.
- Настройте оповещение об измененных файлах за сутки. Я обычно это делаю через помещение в крон строки: 0 0 * * * find /path/to/public/dir -mtime 0 | mailx -s «report » my@mail.com > /dev/null 2>&1 , после этого мне раз в сутки приходит список измененных файлов в директории, анализируя который можно понять, все ли хорошо. Тоже самое можно настроить и для ядра проекта. Данный отчет однажды спас меня, когда произошел взлом одного из моих проектов и по всей фс были накиданы бекдоры — через эти списки мне легко удалось всех их удалить, без поднятия проекта из бекапа. Лично для меня — это теперь незаменимая вещь, лог которой я просматриваю раз в сутки обязательно на наличие подозрительных изменений.
- Всю разработку ведите на SVN и на дев-сервере. Не стоит делать правок «наживо» на продакшене. Я считаю оптимальным — настроить SVN так, чтобы при комите данные сразу попадали на дев-сервер, где можно еще раз протестировать сделанные изменения. Это очень удобно для разработки и тестирования. Как правило дев-сервер может быть отдельной машиной, но также это может быть и виртуал-хост на той же машине, где и продакшн. Правда последний вариант не рекомендую, т.к. при тестировании могут быть разные ситуации, вплоть до зацикливания кода и нехорошо, когда это влияет на работу текущих пользователей.
Если еще что-то вспомню важное — допишу.
Успехов!