:::::::::::::::::::::::::::::::::::::::::::
Главная страница
:::::::::::::::::::::::::::::::::::::::::::
Обучение
Лучшие ученики
Преподаватель
Регистрация
:::::::::::::::::::::::::::::::::::::::::::
Гостевая книга
:::::::::::::::::::::::::::::::::::::::::::
Документация
:::::::::::::::::::::::::::::::::::::::::::
О сайте
:::::::::::::::::::::::::::::::::::::::::::
Повышение квалификации
:::::::::::::::::::::::::::::::::::::::::::
21 ошибка программиста PHP Стерлинг Хьюз. 29-09-2003 Описания семи, последних, смертельных ошибок. Эти ошибки концептуальны по своей природе и являются причиной появления ошибок, описанных в 1-ой и 2-ой частях статьи. Они включают и такие ошибки, как недостаточное внимание, уделённое как проекту в целом, так и коду программы, в частности Одна из наиболее сильных сторон PHP является, одновременно, и его слабой стороной: PHP очень прост в изучении. Это привлекает многих людей; однако, несмотря на его кажущуюся простоту, не так-то просто научиться использовать этот язык правильно и эффективно. Как правило, дело в недостаточной практике программирования. Неопытные программисты становятся перед лицом необходимости создания сложных веб-приложений. Поэтому сплошь и рядом допускаются ошибки, которых избежал бы опытный программист, такие как необоснованное использование функции printf()или неправильное использование семантики PHP. В этой серии из трех статей представлены наиболее, по нашему мнению, характерные ошибки. Эти ошибки можно классифицировать по нескольким категориям, от некритических до смертельных. Наряду с анализом этих ошибок, представлены способы их избежания, а также некоторые маленькие хитрости, накопленные за многие годы практики программирования. Часть третья 7 смертельных ошибок • Целевая аудитория • Введение • 7. Программирование методом вырезать-вставить: неверный подход • 6. Отсутствие в проекте технических директив • 5. Отсутствие экспертной оценки программы • 4. Латание проекта • 3. Исключение конечного пользователя из процесса разработки • 2. Отсутствие плана • 1. Сорванные сроки • резюме • об авторе • 21 ошибка программиста PHP, часть 1 • 21 ошибка программиста PHP, часть 2 Целевая аудитория Эта серия статей предназначена для тех программистов на языке PHP, которые хотят избежать наиболее общих ошибок в написании кода. Читатель, как минимум, должен знать общий синтаксис PHP, а также весьма желателен некоторый опыт использования языка на практике. Введение Одна из наиболее сильных сторон PHP является, одновременно, и его слабой стороной: PHP очень прост в изучении. Это привлекает многих людей; однако, несмотря на его кажущуюся простоту, не так-то просто научиться использовать этот язык правильно и эффективно. Как правило, дело в недостаточной практике программирования. Неопытные программисты становятся перед лицом необходимости создания сложных веб-приложений. Поэтому сплошь и рядом допускаются ошибки, которых избежал бы опытный программист, такие как необоснованное использование функции printf()или неправильное использование семантики PHP. В этой серии из трех статей представлены наиболее, по нашему мнению, характерные ошибки. Эти ошибки можно классифицировать по нескольким категориям, от некритических до смертельных. Наряду с анализом этих ошибок, представлены способы их избежания, а также некоторые маленькие хитрости, накопленные за многие годы практики программирования. Часть 1: Описываются 7 детских ошибок (#21-15, в обратном порядке, в соответствии со степенью серьёзности по нашей классификации). Такие ошибки не вызывают серьёзных проблем, но приводят к уменьшению эффективности работы программы, а также выражаются в громоздком трудночитаемом коде, в который, к тому же, трудно вносить изменения. Часть 2: Следующие 7 ошибок (#14-8) относятся к серьёзным. Они ведут к ещё более значительному уменьшению скорости выполнения кода, уменьшению безопасности скриптов; код становится еще более запутанным. Часть 3: Описания семи, последних, смертельных ошибок. Эти ошибки концептуальны по своей природе и являются причиной появления ошибок, описанных в 1-ой и 2-ой частях статьи. Они включают и такие ошибки, как недостаточное внимание, уделённое как проекту в целом, так и коду программы, в частности. 7. Программирование методом вырезать-вставить: неверный подход Некоторым новичкам свойственно копировать чужой код, например скрипты проверки адресов, отправки почты, обработчики форм. Результатом такой деятельности является мешанина операторов, хоть и криво, но делающая своё дело. И если при всех оптимальных условиях код и будет работать, то при настоящей проверке обязательно свалится. Причём латание дыр никогда не сделает ваш код: • расширяемым: программа будет выглядеть как набор обрывков кода сляпанных вместе. Попросите опытного программиста что-либо изменить в таком скрипте, и он почти наверняка предпочтёт написать свой. Нечитаемый код - нерасширяемый код. • безопасным: вы вставляете в свой проект код чужого человека; при этом вы точно не знаете, что же именно код делает. Задумайтесь над этим. А что если код содержи подложный системный вызов, который сносит все файлы с вашего жёсткого диска? Кроме того, один и тот же код не может быть одинаково защищён и безопасен для разных систем. Ну и, наконец, вы просто копируете чужие ошибки. • быстрым: если вы собираете код из кусочков разных скриптов, не ждите от него быстрой работы. Ибо в этом случае логическое развитие скрипта попросту отсутствует; а всем известно, что в основе быстродействия скрипта лежит его логика. Правильный подход: изучить, потом скопировать Прежде чем копировать чужой код, внимательно его изучите. Проанализируйте, чтО было сделано и как. И только если код хорошо читается, вписывается в логику вашей программы и не содержит ошибок, только тогда его можно рассматривать как кандидатуру на копирование. Если эти правила соблюдены, скопированная часть может быть быстро и безболезненно интегрирована в проект. Библиотеки: то, что вам нужно Используйте библиотеки PHP-функций только из надёжных источников, как, например, PEAR или PHP Classes Repository. Дополнительная функциональность, которую предоставляют вам API из этих библиотек, пойдут вашему проекту только на пользу. Итак, если вы нашли уже готовую библиотеку нужных вам функций (из надёжного источника), то её использование только приветствуется. 6. Отсутствие в проекте технических директив Как-то раз, в самом начале моей карьеры, я работал над одним капитальным проектом (на PERL) в команде с тремя другими программистами. Поскольку я был ещё молод (и к тому же не был руководителем проекта), никаких технических директив (ТД) у нас не было. Каждый взял свою часть проекта и работал над ней в одиночку. Когда же мы стали собирать проект, наши части сильно разнились по своему стилю. Например, один из моих коллег в названии переменных и функций использовал БиКапитализацию. Я использовал underscore (_). Руководитель проекта избрал самый оригинальный стиль и использовал оба метода в зависимости от настроения (что, собственно, и вызвало конфликты в пространстве имён; всем известно, какая это головная боль для разработчика). В общем, это был не проект, а свалка. Понадобилось 20 часов дополнительного времени; хотя ничего бы подобного не случилось, если бы мы удосужились составить чёткие ТД для своего проекта. ТД описывают структуру и внешнее представление исходного кода проекта, определяют методы и стратегию реализации конечного продукта. Для разработки любого проекта нужно составить ТД и следовать им. В ТД должны определяться самые разнообразные аспекты работы: как общие моменты, например, разбитие исходного кода (его файловая структура), так и более конкретные, например, правила именования переменных (суффиксы и префиксы, глобальные прописью). ТД - это пакет соглашений, которые должны выполняться независимо от личных предпочтений программистов. В ТД фиксируются решения по всем спорным моментам, как например: • какие переменные объявлять глобальными, и как они будут дифференцироваться от локальных переменных. • Структуру хранения документов, то есть правила, в какую директорию поместить тот или иной файл: src или lib. • Стиль и содержание комментариев. • Правила документирования. • Ширина строк. ТД должны быть оформлены в своего рода документ; копию его должен получить каждый из участников проекта. По завершении проекта, этот документ должен храниться для последующих обращений к исходному коду. Пример ТД проекта Для лучшего понимания, попробуем составить образец ТД: без подробностей, только основные пункты. Естественно, все необходимые элементы будут представлены, но представлены скорее схематично: настоящие ТД могут свободно занимать 10-40 страниц. Стоит заметить, что для каждого нового проекта не обязательно писать новые ТД с нуля: достаточно просто обзавестись готовым шаблоном и при необходимости вносить в него изменения. ТД по представлению проекта DesignMultimedia.com Итак, приведём пример ТД по внешнему представлению проекта. Разработав подобный документ, вы можете сосредоточиться только на непосредственной реализации проекта и не беспокоиться более о несвязности исходников, конфликтов именования или о структуре сайта, если вы разрабатываете свой сайт. Введение Эта часть определяет следующие моменты: • файловая структура • колонтитулы файла • документирование исходников • комментарии: стиль, значения, определения • директивы по сборке проекта • правила именования переменных Файловая структура (на примере DesignMultimedia.com) В именовании переменных данного проекта должны соблюдаться следующие правила: [1] В именах классов используется бикапитализация. [2] Имена функций пишутся строчными буквами, для разделения слов используется underscore (_). [3] Прочие, более конкретные правила. 5. Отсутствие экспертной оценки программы Идея добавить этот пункт появилась у меня во время подобной проверки, о которой попросил меня друг. Изучив его код, я был в состоянии сократить количество переменных на треть (что давало 400% увеличение скорости обращения к базе данных), количество строк в программе примерно вдвое, кроме того, внести ещё множество улучшений с общим результатом 1000% увеличение скорости (то есть в десять раз быстрее). Мораль? Мораль в том, что качество, скорость и защищённость вашего кода возрастёт неимоверно, если у вас под рукой всегда есть другой опытный программист, который изучит ваш код. Другой человек заметит ошибки, о которых вы даже и не знали, найдёт более простые пути решения той или иной задачи. Кроме того, ему легче найти в вашем коде места, сильно замедляющие работу PHP или представляющие собой потенциальные дыры. Одна из причин небывалого успеха проекта PHP, языка с открытыми исходниками, - это то, что код видело множество людей. Тысячи людей бесплатно проверяли PHP на наличие ошибок, на потенциальные сбои, на несовместимость, на скорость работы и т. д. Таким образом, к появлению новой версии PHP, код просмотрело как минимум 2-3 очень опытных программиста. В идеале, проекты среднего/крупного масштаба просматривают, по меньшей мере, два приглашённых со стороны программиста. Как и в любом другом виде творчества, свежий взгляд всегда очень кстати. Однако в большинстве случаев люд обходятся одним проверяющим. Опытным экспертом считается тот, кто способен быстро дать оценку проделанной работе и внести конструктивные предложения как по содержанию кода, так и по реализации проекта в целом. Нередко бывает полезно составить небольшой список вопросов к человеку, просматривающему код. Вот несколько возможных вопросов: • Какова цель кода XXX? • Как файл XXX вписывается в остальную часть проекта? • Каков алгоритм нейтрализации ошибок? • Можем ли мы отследить действия среднего пользователя данной программы? • Где пользователь программы может ошибиться? 4. Латание проекта Допустим, вы написали приложение и приходите к мысли, что некоторые вещи стоит переделать. Латать - значит писать патчи (заплатки) вместо того, чтобы изучить причину возникновения ошибки и устранить её. Если вы допустили подобную ошибку и понаписали патчей, то получите криво работающий код, компромисс и в скорости и в безопасности. Показатели недоработок проекта Естественно, при первоначальном проектировании приложения, вы считаете, что ваш ход мыслей - самый правильный. И понять, что что-то пошло не так, вы можете в самый последний момент, когда приложение (а также его части) написано почти до конца. Существуют два показателя того, что план проекта не состоялся: • Слишком частая реанимация кода: программа постоянно сваливается и вы находите различные способы заставить её работать. Однако это никак не вписывается в изначальный план проекта. С другой стороны, хотя это и не лучший выход из положения, но в рамках уже составленного вами плана это лучшее, что можно найти. • Слишком сложная реализация. Для решения простых задач выполняются сложные операции. В приведённом ниже примере для вывода строки используется цикл for: Этот код хорошо написан; он циклом проходит по строке и правильно выводит знаменитую фразу Джорджа Буша. Правильный синтаксис, правильная вложенность. И, тем не менее, тот же результат мы могли бы получить при простом выводе целой строки (print()). Исправление недостатков программы Когда вы осознаёте, что в программе есть недостатки или же она попросту реализована не лучшим образом, вы предпринимаете соответствующие шаги по оптимизации кода. И в этом направлении есть масса вариантов: вы можете оставить всё как есть, можете изменить некоторые модули программы или же переписать весь проект заново. В большинстве случаев бывает весьма полезно получить мнение независимого эксперта: просмотрев и изучив код, он сможет адекватно оценить масштаб недоработок. Рассмотрим три категории ошибок: o Небольшие, локализованные ошибки: иногда ошибки в вашей программе не так критичны для её функионирования и внесение исправлений не оправдывает затраченные деньги и время. o Как исправить: в этом случае необходимо как-либо задокументировать факт наличия ошибки. Когда вы решите изменить или обновить ваше приложение, заодно вы исправите и эту ошибку. Примером ошибки подобного класса может послужить неправильная организация данных в отдельной части приложения (простой массив там, где логичнее было бы использовать ассоциативный; стек там, где дерево более уместно). o Значительные, но локализованные ошибки: иногда же получается так, что вы действительно вынуждены переписать часть приложения. Например, если вы пишете свою ОС, в Диспетчере Окон может быть уйма ошибок, в то время как остальной код в полном порядке. o Как исправить: всё, что вам нужно - это перепроектировать именно Диспетчер Окон (а не всю ОС). Это, наверное, самый распространённый случай в практике программирования: отдельные модули содержат ошибки, но в целом структура проекта выполнена корректно. o Значительные, обширные ошибки: наконец, крайний случай, когда ошибки содержатся в реализации самой инфраструктуры проекта. o Как исправить: если неверно спроектирована сама инфраструктура приложения, обычно необходима переорганизация на уровне взаимодействия различных модулей программы. Это, безусловно, самая трудоёмкая работа, отнимающая уйму времени, и к ней редко прибегают, если речь идёт о проектах, находящихся на последних стадиях реализации. Примером таких ошибок могло бы стать использование простых файлов для хранения всей информации в такой огромной поисковой системе как Yahoo. 3. Исключение конечного пользователя из процесса разработки Ситуация: вы получили задание по разработке корпоративного приложения специально для вашей компании. Вы потратили часы на поиск и документирование тонны требований, определили стоимость проекта, поставили задачи и выполнили их. Через три месяца вы приносите законченный проект только чтобы услышать в ответ: o Это не то, чего бы мы хотели. o Наши требования изменились. o Да, но.... o Ммм, какая программа? (Ваш изначальный заказчик уже давно уволился из компании!!!!). Случалось ли подобное с вами? Последнее слово в оценке вашего приложения всегда остаётся за пользователем. По определению именно он будет использовать ваше приложение (и, конечно, много раз пытаться использовать его криво). Многие программисты пишут вещи, которые сами по себе являются шедеврами, но, тем не менее, не отвечают требованиям пользователей. И часто это случается из-за одного или нескольких недопониманий. Резюме o ПРОГРАММИРОВАНИЕ МЕТОДОМ ВЫРЕЗАТЬ-ВСТАВИТЬ: НЕВЕРНЫЙ ПОДХОД. Обычно копирование чужого кода - не очень хорошая затея. Здорово будет изучить техники и алгоритмы чужого кода и при случае внедрить в свой проект. Или же использовать готовые библиотеки. Но ни в коем случае не просто слепо копировать чужой код. o ОТСУТСТВИЕ В ПРОЕКТЕ ТЕХНИЧЕСКИХ ДИРЕКТИВ. Составление подобных директив необходимо при разработке любого проекта. Директивы позволяют вести проект организованно, в единых для всех стиле и документировании и таким образом, позволит избежать многих возможных недопониманий в будущем. o ОТСУТСТВИЕ ЭКСПЕРТНОЙ ОЦЕНКИ ПРОГРАММЫ. Пусть кто-то обязательно просмотрит ваш код. Свежий взгляд на проект обязательно выявит такие вещи как неоптимальные SQL-запросы, неправильное применение синтаксиса языка, слишком сложные решения, дыры и другие недостатки. o ЛАТАНИЕ ДЫР. Серьёзные недостатки патчами не исправить. Если вы видите, что что-то спроектировано неправильно (или не совсем правильно), то в большинстве случаев намного лучше перепроектировать и переписать этот модуль. И да воздастся вам впоследствии. o ИСКЛЮЧЕНИЕ КОНЕЧНОГО ПОЛЬЗОВАТЕЛЯ ИЗ ПРОЦЕССА РАЗРАБОТКИ. Никогда не делайте этого. Именно пользователи будут судить о пригодности вашего приложения, когда всё будет сказано и сделано. Привлечение пользователей в сам процесс разработки приложения опять же позволит избежать многих возможных недопониманий. o ОТСУТСТВИЕ ПЛАНА. Забудьте про главное начать, дальше само пойдёт. Выделите время для тщательного планирования. Каждый план проекта должен обязательно включать в себя этапы Изучения Требований, Разработки и этап Тестирования. o СОРВАННЫЕ СРОКИ. Выделяёте достаточно времени на реализацию проекта! В своём стремлении уложиться в нереальные сроки, вы только повышаете свои шансы допустить 20 предыдущих ошибок. Не позволяйте себе потеряться во времени. Об авторе Стерлинг Хьюз (Sterling Hughes) - независимый разработчик веб-сайтов, занимается созданием динамических веб-приложений для некоторых крупнейших мировых компаний. Участвовал в создании cURL and SWF расширений PHP с открытым исходным кодом. Его книга, Настольная книга программиста PHP (The PHP Developers Cookbook), была издана в октябре 2000 года издательством Sams publishing.
Статьи
21 ошибка программиста. Часть1
Подробнее

21 ошибка программиста. Часть2
Подробнее

21 ошибка программиста. Часть3
Подробнее

Вступление в PHP и MySQL.
Подробнее

Ловля ошибок в PHP.
Подробнее

Народная самодеятельность.
Подробнее

Оптимизация запросов в MySQL.
Подробнее

Пишем PHP код. Проба пера
Подробнее

Приемы безопасного програмиров-я
Подробнее

Работа с MySQL 1. Новостная лента
Подробнее

Работа с MySQL 2. Деревья
Подробнее

Работа с MySQL 3. Подробности
Подробнее

Обучающая система "Язык PHP", 2006 г.