Этапы создания сайта

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

В реальных проектах разработка начинается вовсе не с написания кода. Кодирование составляет лишь небольшой процент от общих трудозатрат. В разработке может участвовать несколько человек совершенно разных специальностей.

Идея, выраженная в ТЗ

Если вы работаете на заказчика или являетесь сами себе заказчиком и исполнителем, вы должны очень хорошо понимать, какой сайт вы хотите создать: какие у него будут задачи, какая аудитория, какой дизайн. Без этого видения конечный результат придется переделывать, что явно не входит в ваши планы.

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

Необходимо проанализировать, какой товар будет выставлен на сайте и для кого, ведь от этого зависит структура сайта и контента, дизайн, методы продвижения и много чего еще. Здесь необходимо вплотную работать с заказчиком, так как он, вероятнее всего, лучше знает о своем товаре, чем вы. Не стесняйтесь задавать глупые вопросы.

Когда информация собрана, разработчик составляет техническое задание, которое предоставляет заказчику. ТЗ необходимо для:

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

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

Цель создания сайта

Макетирование и верстка

Если заказчик готов платить, создается дизайнерский макет будущего сайта. Дизайнер на основе черновых набросков, прикрепленных к ТЗ, «рисует» сайт в графическом редакторе. В конце можно наглядно продемонстрировать, какой дизайн ожидается, а также доработать или в корне изменить некоторые детали.

Сегодня уникальным дизайном вряд ли кого-то удивишь. Более того, художественные выкрутасы городить — почти бессмысленное дело, так как верстать придется под несколько экранных устройств, а на телефонах, с которых в интернет выходит более 55% пользователей, все загогулины придется урезать. И тем не менее, раз контора платит…

Популярные причины, по которым избегают совсем уж уникальный дизайн:

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

С макетом или без него, верстальщик создает HTML-шаблон сайта. С помощью CSS этот шаблон стилизуют, JavaScript применяют для анимации и эргономики интерфейса, а также для асинхронных запросов. Здесь большой комплекс технологий, поэтому иногда верстка производится несколькими людьми, в зависимости от амбициозности проекта.

Шаблон верстается под любые размеры экранов, и это тоже накладывает дополнительные часы и дни работы, если все делать с нуля. Существуют специальные CSS-библиотеки (Bootstrap, Semantic UI, Uikit и др.), заметно ускоряющие адаптивную верстку сайта за счет настраиваемой CSS-сетки и готовых элементов интерфейса. Правда, большинство таких сайтов сильно похожи друг на друга.

CSS-библиотеки дают преимущества, но как быть с уникальным дизайном? Дело в том, что не каждый дизайнер может визуализировать макет с учетом особенностей этих библиотек. Следовательно, верстальщик и дизайнер должны разговаривать на одном языке во избежание разногласий и сюрпризов.

У CSS-библиотек есть недостатки; куда же без них:

  • Конечный CSS-файл содержит много лишних стилей, которые каждый раз запрашиваются с сервера, что подтормаживает загрузку страницы.
  • Добавляется новый уровень абстракции. Во многом вы оперируете не самими стилями, а уже готовыми классами, и это приводит некоторых в замешательство, препятствует быстрому решению нетривиальной задачи.
  • Приходится «играть по правилам» библиотеки, иначе нет смысла ее использовать. Чтобы игра была выгодной для вас, инструмент нужно хорошо изучить.

Когда речь идет об HTML-шаблоне, подразумевается, что этот шаблон будет разрезан на куски и запрограммирован. В противном случае можно говорить, что HTML-шаблон — это почти статический сайт, страницы которого остается только копировать и наполнять текстом и картинками. Но сегодня так делают редко.

Макет сайта

Программирование сайта

В общих чертах программирование сводится к тому, что сайт получает данные из базы данных (БД) и динамически генерирует HTML-страницы, а также сайт принимает данные от пользователя и записывает их в БД. Это стандартный функционал, присутствующий почти на любом сайте.

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

Программа, о которой идет речь, работает на удаленном сервере хостинг-провайдера, там же находится сервер БД. Программы пишут на языке PHP, Java и др., все зависит от уровня задач.

Заказчики в основном доверяют CMS-кам, так как о них много шума в интернете, можно убедиться, что вы — не первооткрыватель. Однако CMS, как и самописные движки, имеют две стороны медали.

Преимущества от использования CMS

  • Бесплатность. Очень много достойных движков бесплатны, и для старта проекта это хорошее подспорье.
  • Надежная поддержка. Бесплатные движки поддерживаются огромным интернет-сообществом энтузиастов, вам помогут найти любой ответ. Популярность движка также позволит подыскать другого специалиста, если прежний вас подвел.
  • Много готовых модулей. Практически под любую задачу кто-то уже написал расширение для движка, которое остается только установить.

Недостатки CMS

  • Чрезмерная универсальность. В попытке объять необъятное производители движков состязаются в поиске «серебряной пули». Чтобы показать простую веб-страницу, система выполняет длинную цепь логических задач, что сказывается на производительности сайта.
  • Уязвимость. Ежедневно и ежечасно ведется работа над устранением слабых мест в системе, однако, противоположную работу ведут и злоумышленники, особенно когда система очень востребована в массах.
  • Диктует свои жесткие правила, еще сильнее, чем фреймворки (готовые архитектурные каркасы), лишая программиста свободы мысли настолько, что конечные результаты очень похожи друг на друга.

Программирование сайта — сложная и ответственная работа. Если однажды не загрузилось изображение — не беда, — проблема, если чьи-то денежки ушли не туда. Поэтому код должен тщательно тестироваться как в момент написания, так и в целом, перед сдачей проекта.

Наполнение и тестирование

Любой контент как-то отображается, имеет допустимую ширину и высоту, записи не должны выходить за свои границы. Так предусмотрено дизайном. Что если разработчик ввел несколько тестовых наименований товаров, длина которых не превышает 70 знаков, а владелец, сев наполнять сайт, ввел реальное название товара, длина которого 150 знаков и она вышла на следующую строку? Блок под названием сместится вниз и произведет неожиданный эффект.

Казалось бы, мелочь, но их много, и даже не относящихся к дизайну. Например, в БД была отправлена запись, превышающая по количеству символов допустимую длину. Программист, в целях оптимизации, написал city varchar (20), думая, что населенного пункта с более длинным названием не существует. Однако покупатель указал, что он проживает в с. Старокозьмодемьяновское. Это просто пример.

О чем идет речь. Перед сдачей проекта должны быть наполнены любые уникальные блоки сайта хотя бы по одному экземпляру (товар, статья, сообщение и пр.). Желательно, чтобы их было гораздо больше. В процессе реального наполнения вылазят ошибки, которых не было видно раньше.

Должны быть протестированы все ссылки, включая страницу 404 и др., все POST-запросы, все кнопки должны работать согласно ТЗ. Тестирование — особая часть разработки. Его рекомендуется доверять людям, которые не писали тестируемый код и вообще далеки от программирования. Они лучше выявляют ошибки, так как способны выполнить такие действия на сайте, которые программисту и в голову не пришли бы.

Наполнение сайта контентом

Что дальше?

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

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

Сайт постепенно переходит в стадию наполнения и продвижения. Процесс поддержки сайта не заканчивается никогда, а кто именно будет это делать, вопрос уже финансовый. Ценность сайта обретается не столько в момент его первой публикации, сколько спустя годы систематической работы над ним. Сайт получает трафик, узнаваемость, постоянных клиентов, и все это приносит доход его владельцу.

Выше приведен приблизительный порядок разработки сайта. Это не означает, что ему нужно следовать без оглядки. Все индивидуально. Например, можно пойти путем предварительной подготовки контента, и наполнить сайт на стадии создания. Можно обойтись без чернового и дизайнерского макетирования, если заказчик готов положиться на мнение разработчика.

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

captcha