Status

Цена разработки.

Общая часть

 

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

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

Серверная часть (back-end) — в общем случае содержит в себе всю бизнес-логику, занимается получением, отправкой, хранением и обработкой данных. Это — ядро приложения. Сюда же относятся базы данных и, в некоторых случаях, панели администратора.

Клиентская часть (front-end) — занимается представлением данных и взаимодействием пользователя с системой, но никогда не хранит и не обрабатывает данные. Клиент постоянно обменивается с сервером данными — отображает полученное от сервера и отсылает ему то, что сделал пользователь. Именно от клиентской части приложения зависит удобство и положительный опыт взаимодействия пользователя с приложением.

Классическим примером является браузер — в нем отображается пользовательский интерфейс (сам сайт) — это и есть клиент. Однако, для понимания сути вопроса, лучшим примером будет мобильное приложение (например, Instagram). Приложение, установленное на смартфоне позволяет взаимодействовать с сервисом, однако, не хранит в себе никаких данных, а получает их с сервера.

В первые десятилетия существования интернета (в частности, в России), сложилась достаточно плохая практика разработки — клиентская и серверная части оказались перемешаны между собой. Фактически, сервер стал «отдавать» браузеру сгенерированную им же самим [сервером] статичную страницу, большинство функций, которые в норме возлагаются на клиент были переданы серверу, а представление и содержание оказались перемешаны. Все это привело к низкому качеству продукта, сложности разработки, отвратительному опыту взаимодействия пользователя с продуктом (в браузере), низкой скорости загрузки и необходимости постоянно перезагружать страницы ради каждого действия, либо попыткам обойти это неправильным способом.

Одним из самых отвратительных последствий использования подобной практики стало возникновение процесса «натяжки» — это когда дизайнер рисует, верстальщик превращает шаблон в статичный HTML и CSS (который не может ничего), а этот шаблон уже передается программисту (иногда его называют технологом), который «натягивает» верстку на «движок» (например, 1С-Битрикс), разрезая шаблон на части, вставляя переменные и т.д.

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

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

К сожалению, именно так устроен 1С-Битрикс, широко критикуемый сообществом разработчиков за подходы к работе и качество кода, хотя и имеющий свои преимущества (например, готовую интеграцию с 1С).

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

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

Варианты реализации

Есть 3 (три) варианта реализации проекта:

Вариант №1: 1С-Битрикс, стандартный процесс
Ориентировочная стоимость разработки: 250-500 т.р.

Разработка ведется как обычно, тем самым «классическим» способом с «натяжкой», описанным выше.
В этом случае проект получается обычным, стандартным, ничем не примечательным, скорость работы будет достаточно стандартная (не высокая), взаимодействие с пользователем и качество продукта посредственным (т.к. работа будет зажата в рамках Битрикса).
Мы не рекомендуем этот вариант для нашего проекта, т.к. Интернет-магазин должен быть максимально удобен пользователю (чтобы сервисом хотелось пользоваться повторно). Такой проект требуется сделать хорошо, качественно и современно.

Вариант №2: 1С-Битрикс в качестве сервера (back-end) и React-приложение в качестве клиента (front-end)
Ориентировочная стоимость разработки: 600-950 т.р.

Это комплексная разработка продукта с разделением на back- и front-end части. В этом случае сохраняются все преимущества от использования 1С-Битрикс (интеграция с 1С, привычность работы с панелью администратора, многие готовые функции), а практически все недостатки аннигилируются за счет того, что он перестает управлять клиентской частью, а эта задача возлагается на клиентское веб-приложение на основе React.js.

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

Вариант №3: Изоморфное приложение на Node.js с использованием React.js
Ориентировочная стоимость разработки: от 1 миллиона рублей и далее…
В этом случае 1С-Битрикс не используется вообще, равно как и язык программирования PHP, на котором он написан.

Как серверная часть используется Node.js (серверный JavaScript), разработка ведется практически с нуля, все функции являются кастомными, полностью заточенными под требования проекта, реализованными именно так, как требуется (а не в тех рамках, что задает Битрикс).

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

Однако, платой за это становится необходимость самостоятельно писать все, что в Битриксе есть «из коробки» (что увеличивает стоимость и время разработки): функции интернет-магазина, интеграция с 1С, панель администратора и т.д.

Подход к разработке
Использование правильных подходов к разработке ПО позволяет использовать и правильный менеджмент проекта.

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

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

Нет комментариев
Написать комментарий

2006-2024 Status-club. Все права защищены.