Сайт, как и любая другая сложная конструкция материального мира, требует своего порядка разработки и сборки. Соблюдая эти этапы, вы почти гарантированно получите ожидаемый и желаемый результат.
В реальных проектах разработка начинается вовсе не с написания кода. Кодирование составляет лишь небольшой процент от общих трудозатрат. В разработке может участвовать несколько человек совершенно разных специальностей.
Идея, выраженная в ТЗ
Если вы работаете на заказчика или являетесь сами себе заказчиком и исполнителем, вы должны очень хорошо понимать, какой сайт вы хотите создать: какие у него будут задачи, какая аудитория, какой дизайн. Без этого видения конечный результат придется переделывать, что явно не входит в ваши планы.
Часто заказчики сами не знают, чего хотят, либо не могут выразить словами свои потребности. Вам нужно помочь им в этом, пусть покажут примеры, расскажут, как они планируют это использовать. Возможно, какая-то крутая фича на сайте конкурента уже не покажется такой привлекательной, когда для ее работы возникнет необходимость вводить новую штатную единицу (например, онлайн-чат).
Необходимо проанализировать, какой товар будет выставлен на сайте и для кого, ведь от этого зависит структура сайта и контента, дизайн, методы продвижения и много чего еще. Здесь необходимо вплотную работать с заказчиком, так как он, вероятнее всего, лучше знает о своем товаре, чем вы. Не стесняйтесь задавать глупые вопросы.
Когда информация собрана, разработчик составляет техническое задание, которое предоставляет заказчику. ТЗ необходимо для:
- обеих сторон, чтобы каждая удостоверилась, что хорошо понимает друг друга;
- заказчика, который ко времени завершения проекта забудет, что заказывал;
- всех специалистов, участвующих в процессе.
ТЗ пишется в свободной форме и подписывается сторонами. Это документ, позволяющий отстаивать свои права и заставляющий нести обязанности. В нем, помимо текста, могут быть блок-схемы, распечатанные схематические макеты веб-страниц, согласования цветовых палитр и пр.
Макетирование и верстка
Если заказчик готов платить, создается дизайнерский макет будущего сайта. Дизайнер на основе черновых набросков, прикрепленных к ТЗ, «рисует» сайт в графическом редакторе. В конце можно наглядно продемонстрировать, какой дизайн ожидается, а также доработать или в корне изменить некоторые детали.
Сегодня уникальным дизайном вряд ли кого-то удивишь. Более того, художественные выкрутасы городить — почти бессмысленное дело, так как верстать придется под несколько экранных устройств, а на телефонах, с которых в интернет выходит более 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-запросы, все кнопки должны работать согласно ТЗ. Тестирование — особая часть разработки. Его рекомендуется доверять людям, которые не писали тестируемый код и вообще далеки от программирования. Они лучше выявляют ошибки, так как способны выполнить такие действия на сайте, которые программисту и в голову не пришли бы.
Что дальше?
По-хорошему, после сдачи проекта жизнь сайта должна только начаться, а не закончиться. Совершенству нет предела, особенно когда технологии развиваются семимильными шагами. Нужно вносить какие-то новшества, следить за конкурентами и не отставать.
Разработчик передает клиенту все инструменты управления: пароли от панели администратора и личного кабинета у хостинг-провайдера. Проводит краткий, а может быть и подробный, инструктаж по технике использования сайта (как добавлять контент, как оплачивать хостинг, домен и пр.).
Сайт постепенно переходит в стадию наполнения и продвижения. Процесс поддержки сайта не заканчивается никогда, а кто именно будет это делать, вопрос уже финансовый. Ценность сайта обретается не столько в момент его первой публикации, сколько спустя годы систематической работы над ним. Сайт получает трафик, узнаваемость, постоянных клиентов, и все это приносит доход его владельцу.
Выше приведен приблизительный порядок разработки сайта. Это не означает, что ему нужно следовать без оглядки. Все индивидуально. Например, можно пойти путем предварительной подготовки контента, и наполнить сайт на стадии создания. Можно обойтись без чернового и дизайнерского макетирования, если заказчик готов положиться на мнение разработчика.
Самый первый этап тоже проходят не всегда, многое опускается, по факту решают все на словах. Но это в небольших проектах. В крупных все же рекомендуется придерживаться какой-то системы построения, иначе все может рухнуть, не успев воздвигнуться.
