Заказчик редко покупает «код». Он покупает работающий сайт или систему, которую можно развивать несколько лет, не переписывая с нуля. Всё, что происходит между постановкой задачи и запуском, — выбор языка и фреймворка, вёрстка, работа с базой, тестирование, сборка, выкладка — влияет на то, во сколько обойдётся это развитие. Ниже мы собрали в одном месте то, что обычно объясняем клиентам по частям: из чего состоит веб-проект, как мы выбираем инструменты, зачем нужно тестирование и какие вопросы стоит задать подрядчику до начала работ.
Из чего состоит веб-проект
Любой сайт сложнее визитки делится на три слоя. Разделение не формальное: почти все спорные ситуации на проектах возникают на стыках между слоями, поэтому полезно понимать, кто за что отвечает.
| Слой | За что отвечает | Что происходит, если сделан плохо |
|---|---|---|
| Клиентская часть (frontend) | Всё, что видит и нажимает посетитель: вёрстка, интерактив, адаптивность | Сайт «едет» на телефонах, формы не отправляются, страница долго не отвечает на действия |
| Серверная часть (backend) | Логика, расчёты, права доступа, обмен с другими системами | Дубли заказов, потерянные заявки, дыры в безопасности |
| Хранилище данных | База данных и файлы: товары, заказы, статьи, пользователи | Каталог тормозит при росте, данные противоречат друг другу |
Отдельно стоит инфраструктура: сервер, домен, почта, резервные копии, сертификат. Её часто вспоминают в последний момент, а именно она определяет, переживёт ли проект переезд, всплеск посещаемости или уход подрядчика. Эту часть мы обычно берём на себя: настраиваем и администрируем серверы, чтобы проект не зависел от случайной площадки.
Вёрстка: с чего начинается интерфейс
Вёрстка — это перевод макета в HTML и CSS так, чтобы страница одинаково выглядела на разных экранах и браузерах. Работа выглядит простой только со стороны: дизайнер рисует один кадр, а верстальщик отвечает за все промежуточные состояния — длинное название товара, отсутствующая картинка, три строки вместо одной, экран шириной 320 пикселей и экран шириной два метра.
Что мы считаем признаками добротной вёрстки:
- Семантика. Заголовки — заголовками, списки — списками, кнопка — кнопкой. От этого зависят и доступность, и понимание страницы поисковыми роботами.
- Адаптивность без отдельной мобильной версии. Один набор шаблонов, который перестраивается под ширину экрана, дешевле в поддержке, чем два сайта.
- Работа с клавиатуры. По интерфейсу можно пройти табуляцией, фокус видно, поля подписаны.
- Устойчивость к содержимому. Блок не разваливается от длинного слова, пустого поля или отсутствующего изображения.
- Отсутствие «магии» в стилях. Правила читаются, у классов есть система именования, новый разработчик находит нужное место за минуты.
Как мы выбираем язык и платформу
Универсального лучшего языка нет — есть подходящий под задачу, срок и команду. Спор о языках чаще всего сводится к вопросу, кто будет поддерживать проект через два года.
На что мы смотрим при выборе:
- Тип задачи. Контентный сайт, интернет-магазин, внутренняя система учёта и высоконагруженный сервис требуют разного.
- Наличие готовых решений. Если девяносто процентов задачи закрывает существующая платформа, писать своё дорого и рискованно.
- Доступность специалистов. Экзотический стек означает, что заказчик привязан к одной команде.
- Интеграции. Если системе предстоит обмениваться данными с учётной системой или оборудованием, важна готовность библиотек.
- Стоимость владения. Требования к серверу, лицензии, обновления, скорость внесения правок.
На практике для сайтов и корпоративных систем мы чаще всего работаем с PHP и JavaScript: под них есть зрелые фреймворки, большое сообщество и предсказуемый рынок специалистов. Для отдельных задач — обработка данных, интеграции, вспомогательные сервисы — используем Python и Node.js. Выбор объясняем клиенту до начала работ, а не после. Тем же стеком делаем CRM, ERP и системы документооборота.
Фреймворки и библиотеки: что они дают и чем за это платят
Фреймворк — это заготовка приложения: в нём уже решены маршрутизация, работа с базой, авторизация, шаблоны, защита от типовых атак. Библиотека решает одну задачу, фреймворк задаёт структуру всего проекта.
Что фреймворк даёт:
- Скорость старта: типовые вещи не пишутся заново.
- Единый стиль кода, из-за которого проект понятен новому разработчику.
- Проверенные решения по безопасности, а не самодельные.
- Обновления и исправления от сообщества.
Чем приходится платить:
- Порогом входа: специалисту нужно знать не только язык, но и фреймворк.
- Избыточностью: для небольшой задачи каркас может оказаться тяжелее самой задачи.
- Зависимостью от версий: устаревший фреймворк рано или поздно требует миграции.
Во фронтенде выбор обычно идёт между React, Vue, Angular и Svelte. Для сайта с обычными страницами и формами интерфейсный фреймворк часто не нужен вовсе: он усложняет вёрстку, увеличивает вес страницы и мешает индексации, если не настроен серверный рендеринг. Мы применяем его там, где на странице есть настоящее приложение — конфигуратор, личный кабинет, сложная фильтрация, интерактивные отчёты. Например, так сделан личный кабинет с историей заказов для стекольной компании.
База данных и скорость
Когда сайт начинает тормозить при росте каталога или числа заказов, причина чаще всего в запросах к базе, а не в «слабом сервере». Хорошая новость: узкое место обычно одно или два, и находится оно быстро — по журналу медленных запросов.
| Причина | Как выглядит | Что делаем |
|---|---|---|
| Нет индекса | Полный перебор таблицы при каждом открытии страницы | Добавляем индекс по полям фильтрации и сортировки |
| Запросы в цикле | Сто запросов там, где хватило бы одного | Собираем данные одним запросом с объединением |
| Выборка всех полей | Из таблицы тянется всё подряд, включая тексты | Запрашиваем только нужные колонки |
| Нет кэширования | Страница собирается заново при каждом заходе | Кэш готовых блоков и результатов запросов |
| Тяжёлые изображения | Страница весит десятки мегабайт | Сжатие, современные форматы, правильные размеры |
Оптимизировать наугад бессмысленно: сначала измерение, потом правка, потом повторное измерение. Иначе легко потратить неделю на то, что даёт выигрыш в сотые доли секунды. В таком порядке мы разбирали каталог коммерческой недвижимости на 5 498 объектов, где часть данных терялась при выгрузке.
Система контроля версий: порядок вместо надежды
Git — распределённая система контроля версий, в которой хранится вся история изменений проекта. Для заказчика это звучит как внутренняя кухня, но именно от неё зависит несколько важных вещей: можно ли откатить неудачную правку, видно ли, кто и когда что менял, и получится ли передать проект другой команде.
Правила, которых мы придерживаемся:
- Работа ведётся в отдельных ветках, а не прямо в рабочей версии сайта.
- Каждое изменение сопровождается описанием, по которому понятно, что и зачем сделано.
- Правки на «живом» сервере руками — исключение, а не норма: иначе история расходится с реальностью и следующая выкладка затирает чужую работу.
- Репозиторий передаётся заказчику вместе с проектом. Код принадлежит ему, а не студии.
Отдельный вопрос — где размещать репозиторий. Кроме зарубежных площадок есть российские хостинги кода и возможность поднять сервер репозиториев внутри компании. Для проектов с требованиями к размещению данных это единственный рабочий вариант, и закладывать его нужно на старте.
Тестирование: не «поиск багов», а снижение риска
Самое живучее заблуждение о тестировании звучит так: тестировщик нужен, чтобы ловить ошибки программиста. На деле его работа начинается раньше — с требований. Хороший специалист по качеству первым замечает, что в постановке задачи не описано, что делать с отменённым заказом или как система ведёт себя при потере связи. Ошибка, найденная на этапе требований, стоит несопоставимо дешевле той же ошибки, найденной после запуска.
Уровни проверки, которые мы применяем в разном сочетании в зависимости от проекта:
| Вид проверки | Что проверяет | Когда оправдана |
|---|---|---|
| Модульные тесты (unit) | Отдельную функцию или класс в изоляции | Расчёты, скидки, права доступа, обмен данными |
| Интеграционные | Совместную работу нескольких частей и обмен с внешними системами | Связка с учётной системой, платежами, службой доставки |
| Сквозные сценарии | Путь пользователя целиком: от карточки до оплаченного заказа | Магазины и личные кабинеты |
| Ручное исследование | Нестандартные ситуации, удобство, здравый смысл | Любой проект перед запуском |
| Регрессионная проверка | Что новая правка не сломала работавшее раньше | Проекты, которые развиваются постоянно |
Подход TDD, при котором тест пишется до кода, звучит непривычно, но решает одну конкретную проблему: заставляет сформулировать ожидаемое поведение до того, как начнётся программирование. Мы применяем его выборочно — на сложной бизнес-логике, где цена ошибки высока, а поведение можно описать точно. Верстать интерфейс «от тестов» смысла нет.
Полное покрытие тестами нужно не всегда, и обещать его на любом бюджете — лукавство. Разумный ориентир: автотесты закрывают то, что дорого сломать и трудно проверить руками, остальное проверяется по чек-листу перед выкладкой.
Инструменты, которые экономят часы
Про инструменты разработчика обычно пишут списками из десяти пунктов. Полезнее назвать не названия, а привычки, которые действительно ускоряют работу.
- Вкладка «Сеть» в браузере вместо догадок. Она сразу показывает, какой файл весит больше всех, какой запрос отвечает дольше всех и что грузится дважды.
- Вкладка «Производительность» при жалобах на «тормозит». Часто виноват не сервер, а сторонний скрипт виджета.
- Условные точки останова в отладчике вместо вывода отладочной информации на экран. Особенно на цикле в тысячу итераций.
- Эмуляция медленной сети и слабого устройства. Проект, который летает на рабочем ноутбуке, может быть неработоспособен на телефоне в метро.
- История изменений строки в редакторе. Вопрос «зачем здесь это условие» решается за секунды, если у правки есть внятное описание.
- Журналы сервера, которые кто-то читает. Логи, которые никто не открывает, не отличаются от отсутствующих.
Low-code, no-code и генерация кода моделью
Платформы визуальной сборки приложений и генерация кода языковой моделью решают одну и ту же задачу — сократить путь от идеи до работающего прототипа. Обе технологии полезны и обе имеют границу применимости.
Что действительно ускоряется:
- Прототип и проверка гипотезы: рабочий макет вместо описания на словах.
- Внутренние инструменты: простая форма сбора данных, справочник, отчёт для отдела.
- Разовая рутина: конвертация данных, вспомогательные скрипты, заготовки тестов.
- Разбор незнакомого кода: объяснение чужого модуля своими словами.
Где начинаются проблемы:
| Область | В чём сложность |
|---|---|
| Нетиповая логика | Как только правила отличаются от стандартных, конструктор упирается в потолок, а сгенерированный код требует ручной переработки |
| Производительность | Решение, работавшее на сотне записей, встаёт на сотне тысяч |
| Безопасность и права | Проверки доступа выглядят правдоподобно и при этом могут отсутствовать по сути |
| Поддержка | Код, который никто не прочитал, невозможно осмысленно дорабатывать |
| Перенос | Платформа диктует формат данных, уход с неё оказывается отдельным проектом |
Наш принцип простой: то, что попадает в продуктивную среду, читает и понимает человек. Сгенерированный фрагмент проходит тот же путь, что и написанный вручную, — ревью, тесты, выкладка.
Когда сайту нужны возможности приложения
Прогрессивное веб-приложение (PWA) — это обычный сайт, который умеет вести себя как приложение: устанавливается значком на экран, открывает ранее просмотренные страницы без сети и может присылать уведомления. Технология давно не новая, вопрос всегда один: нужны ли проекту эти возможности.
PWA оправдан, когда посетители возвращаются регулярно, работают в условиях нестабильной связи или пользуются сайтом как рабочим инструментом. Для сайта услуг, куда человек заходит один раз перед звонком, выгоды почти нет.
Отдельно про push-уведомления. Технически их несложно подключить, но подписка на них — это разрешение, которое посетитель даёт один раз, и потерять его можно тоже один раз. Что мы советуем:
- Не спрашивать разрешение на первой секунде первого визита. Запрос уместен после действия, которое показывает интерес.
- Объяснять, о чём будут сообщения, до системного окна браузера, а не после.
- Присылать то, чего человек ждёт: статус заказа, ответ на обращение, изменение по его заявке. Рассылка акций расходует доверие быстро.
- Оставлять понятный способ отписаться внутри сайта, а не только в настройках устройства.
Два списка: перед запуском и перед стартом
Что мы проверяем перед выкладкой
Перед выкладкой проходим один и тот же список. Он скучный, и именно поэтому работает.
- Все ключевые сценарии пройдены руками: заявка, заказ, оплата, восстановление пароля, письма приходят.
- Проверка на реальных устройствах, а не только в уменьшенном окне браузера.
- Скорость измерена на типовых страницах, тяжёлые изображения приведены в порядок.
- Настроены резервные копии базы и файлов, проверено восстановление из копии.
- Сайт целиком доступен по https, служебные и тестовые разделы закрыты.
- Формы соответствуют требованиям к обработке персональных данных, согласие не проставлено заранее.
- Аналитика установлена и цели проверены до запуска рекламы, а не после.
- Доступы к серверу, домену и репозиторию переданы заказчику под запись.
Что спросить у подрядчика до начала работ
Эти вопросы стоит задавать любой студии, включая нашу. Ответы на них показывают, придётся ли переписывать проект через год.
- На чём будет сделан проект и почему выбран именно этот стек.
- Кому принадлежит код и где будет храниться репозиторий.
- Как организовано тестирование и что именно проверяется перед выкладкой.
- Что входит в поддержку после запуска и как передаются доработки.
- Что произойдёт с проектом, если команда сменится: есть ли документация и понятная структура.
- Как устроены резервные копии и кто отвечает за их восстановление.
Учиться в этой профессии приходится постоянно: инструменты меняются, требования браузеров тоже. Мы стараемся делать это под задачу, а не про запас, — знание, которое не применили в ближайшие недели, всё равно забывается. Именно поэтому в статьях мы описываем то, что применяем в работе, а не то, о чём прочитали.
Так устроена разработка и у нас: стек подбирается под задачу, а не под моду. С какими технологиями мы работаем и какие проекты делаем — на странице веб-студии «Вебтую».
Если нужен взгляд со стороны
Мы разбираем существующие проекты и делаем новые: от корпоративного сайта до внутренней системы учёта. Если непонятно, во что упирается ваш проект — в архитектуру, в базу или в отсутствие регулярного тестирования, — покажем это на конкретных страницах и цифрах замеров. Наше направление — разработка сайтов и систем: расскажите задачу, и мы предложим решение с объяснением, почему именно такое.
