fisher (raa) wrote,
fisher
raa

основные ошибки php-team, которые встретились за год,
плавно переросшие в .
всем, разумеется, очень стыдно ;)

I. security - все знают, но продолжают косячить.
- sql-injections.
всегда, на автомате, mysql_escape_string (или ей подобная,
но не addslashes) при вызове query-методов.
и только непосредственно при передачи аргуметров, а не во
"внешнем" коде (в ряде мест грешат при передаче аргументов mоdel-методам).

- xss.
всегда htmlspecialchars при отображении (и только при
отображении - после всей прочей логики), лучше htmlspecialchars
с ENT_QUOTES - заранее избежим ошибок при верстке
форм где значения инпутов в одинарных кавычках + js
(не на 100%). есть ньюансы (utf7 и тд).

- все приходящие параметры проверять

II. culture
- functions.
не более 5 параметров. не более 100 строк на функцию. все приходищие параметры проверять.
за пакет навроде *** (ок 20-ти аргументов в методе ***) - публичное порицание.

- если мы обращаемся к $A['x'], то либо ключ 'x' _всегда_ есть, либо проверять isset/empty.
ошибка детсадовская, публичное порицание

- три-равно (===) при сравнении строк, boolean! либо strval, либо strcmp.
ошибка детсадовская, публичное порицание.

- error handling(logging), проверка всего и вся, особенно при написании офлайн-скриптов.
обязательна к прочтению http://www.zend.com/php5/articles/php5-exceptions.php.
за метод, у которого в 10-ти местах return false "без детализации" - публичное
порицание в извращенной форме.
старый код навроде *** (где в одном методе около 10-ти
потенциальных мест падения *** а где именно - расставляй маркеры) -
рефакторить. не бояться звать error_log если об ошибке стоит сигнализировать
но складывать куда-то trace не нужно. идея с отправкой ошибок на мыло - в ряде
случаев очень неплохая (если вероятность положить мейл-сервер или засрать
почту товарищам пренебрежимо мала).

- classes: по возможности лёгкие, без монстров. учитывать особенности php, при необходимости
бить мельче, чем требуется с точки зрения банальной эрудиции.

- не забывать убирать дебаги из кода. рекомендуется метод поиска перед коммитом
всех echo, print, var_dump и Log::message.

- не реализовывать обработку очередей таким образом, что какая-нибудь мелочь
типа пустого имени (ошиблись при импорте) останавливает обработку всей очереди.
ошибка в лог - объект пропустили и пошли дальше (если объекты в очереди независими, конечно).

- поддерживать документацию для "сложных" кусков в нормальном состоянии.

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

III. mvс, templates
- весь код для веб-страниц должен выполняться в следующей последовательности.
1. инициализация путей и прочего, сессии и тд.
2. работа с базой, прочая бизнес-логика
3. отображение. _ничего_ касательно отображения не должно быть в пп1-2.
открывать шаблон тоже лучше непосредственно перед парсингом.
в конце этапа 2 сессия уже сохранена, транзакции завершены, никаких операций
над базой и тд. короче, придерживаться принципа "не начинать работу
на этом уровне раньше (или заканчивать - позже), чем требует здравый смысл"

- меньше вложенности в шаблонах, они должны быть маленькие и понятные.
не бояться увеличения числа мелких шаблонов (тупить на 99% будет пхп,
а не шаблонный движок).

- в виду сложной шаблонной логики обязательно разделы вроде ***
делать через view-класс и маленькими методами, или через отдельные функции.
простыни шаблонного кода быть не должно.

IV. Data
- работать с транзакциями более вдумчиво.
если метод должен что-то получить - пусть только получает.
если только обновлять - пусть только обновляет.
если нужна транзакция - разработчик должен понимать сам где
она нужна и когда, и расставлять операции открытия
и закрытия транзакций не на автомате а с понимаем что куда.
не должно быть "долгих" (по времени) и "больших" (по объему) транзакций.
проверять результат коммита!

- не забывать прогонять сомнительные места на explain

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

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


P.S. A good programmer is someone who looks both ways before crossing a one-way street (Doug Linder).
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 14 comments