Создание реальных веб-приложений редко бывает настолько простым. Несколько лет назад "интерактивный" веб-сайт предоставлял возможность отправки формы по электронной почте и это было все. В наши дни веб-сайты стали веб-приложениями, другими словами, настоящими программными средствами, доступными через Веб. В результате вместо коротких сценариев веб-сайты содержат тысячи и тысячи строк кода. Проекты подобного масштаба требуют планирования и управления в такой же степени, как и разработка любых других программных средств.
Прежде чем приступить к обзору проектов, рассмотрим некоторые приемы управления крупными веб-проектами. Это постоянно развивающееся искусство, и, как показывает изучение рынка, постигнуть его не так-то просто.
Возможно, вам уже известно, что проектирование — это применение методов систематизации и количественных измерений к разработке программных средств. Другими словами, это приложение принципов проектирования по отношению к разработке программ.
Отметим, что данный подход заметно отсутствует во многих веб-проектах, что вызвано двумя основными причинами.
Во-первых, разработка веб-приложений зачастую напоминает создание отчетов. Она предполагает построение структуры документа, графическое оформление и публикацию. Этот подход ориентирован на документ. Он вполне применим для статических сайтов малого и среднего размеров. Однако, с возрастанием динамического содержимого веб-сайтов до уровня, когда они предоставляют не столько документы, сколько услуги, данный принцип становится непригодным. Многим вовсе не приходит в голову воспользоваться принципами проектирования программного обеспечения.
Вторая причина состоит в том, что условия разработки веб-приложений во многом отличаются от разработки обычных программных систем. Работа ведется в исключительно сжатые сроки и под постоянным нажимом создать сайт немедленно. Ведение проектов обычных программ предполагает последовательность и методичность, а на планирование специально выделяется время. При разработке веб-проектов часто господствует ощущение, что на планирование вообще нет времени.
Отсутствие планирования Web-проектов приводит к таким же результатам, как и при отсутствии планирования для любых других программ: ошибки в коде, нарушение сроков и неудобочитабельный код.
Трудность заключается в выборе методов сопровождения проектов программного обеспечения, пригодных для разработки Web-приложений, и отказе от всех остальных.
Не существует универсального метода планирования жизненного цикла веб-проектов. Однако есть ряд моментов, которые необходимо учесть. Ниже приводится их перечень, а более подробное обсуждение содержится в последующих разделах. Необязательно следовать этим рекомендациям в порядке их изложения, если это не подходит к определенному проекту. Главное здесь — иметь представление о данных вопросах и выбирать рекомендации, применимые к конкретному случаю.
Программисты часто по ошибке создают код, который уже существует. Если известны необходимые компоненты приложения либо хотя бы необходимые функции, перед тем как приступить к разработке, проверьте, что имеется в наличии.
Иногда программисты повторно реализуют функции потому, что не прочли в руководстве о том, что существующие функции предоставляют необходимые возможности. Всегда обеспечивайте возможность быстрого вызова руководства в интерактивном режиме либо загружайте текущую версию и просматривайте ее в автономном режиме. Однако имейте в виду, что интерактивное руководство довольно часто обновляется. Кроме того, такое руководство содержит ссылки, что делает его великолепным ресурсом с комментариями, рекомендациями и примерами кода других пользователей. Оно часто содержит ответы на вопросы, которые обычно возникают после чтения основной страницы руководства. Вот адрес, где находится руководство по РНР:
http://www.php.net/manual/ru/
http://docs.php.net/manual/ru/
Некоторые неанглоязычные программисты поддаются искушению писать функции упаковщики, которые фактически присваивают PHP-функциям новые имена на родном для разработчика языке. Эту практику часто называют "синтаксическим сахаром" (syntactic sugar). Так делать не рекомендуется — это усложняет для других чтение и сопровождение кода. Если вы изучаете новый язык, учитесь правильно его использовать. Кроме того, подобное добавление уровня вызова функций замедляет выполнение кода. С учетом всех обстоятельств, подобного подхода следует избегать.
Если выяснилось, что необходимые функциональные возможности не обеспечиваются базовой библиотекой РНР, существует два пути. Для простых задач имеет смысл создать собственную функцию или объект. Однако при написании достаточно сложного кода, такого как покупательская тележка, система электронной почты Веб или Web-форумы, нередко обнаруживается, что работа уже кем-то проделана. Одно из преимуществ работы с сообществом Open Source состоит в том, что код компонентов подобных приложений, как правило, распространяется бесплатно. Если найден компонент, похожий на требуемый, пусть даже и не вполне соответствующий, можно просмотреть исходный код и на его основе выполнить модификацию или создать собственную программу.
После завершения разработки собственных функций или компонентов имеет смысл всерьез задуматься над тем, чтобы предоставить их сообществу РНР. Именно этот принцип делает сообщество разработчиков на РНР таким полезным, активным и информированным.
Веб-инструмент
Обсудить на форуме