Топ-5 самых спорных идей от клиентов в заказной веб-разработке

Это эмоциональный отклик нашего разработчика по заказной фуллстек-разработке, и вместо слова «спорных» было изначально немного более жесткое слово.

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

1. Кроппер для фоток, вообще идея обработки фото каким-то образом на сайте это уже тупость. Закладывать на это нужно как на полноценный плагин, 30-40 часов. Клиент потом захочет докрутить плюшки типа, а давайте повернем, а давайте размер изменим, а давайте фон поменяем. А давайте множественное фото добавим, а давайте отредактируем.Поддерживать это тяжело, потому что свои 5 копеек приносят смартфоны, которые сохраняют картинку с атрибутами поворотов и вам повезло если вы об этом знаете.Мой комментарий: Желательно сразу по максимуму выявлять все нюансы как будут обрабатываться фотографии и ограничивать аппетиты по улучшениям этого механизма. Здесь действительно можно бесконечно улучшать обрезку и обработку фотографий.

2. Tinymce. Кривота, кривота, кривота. Для админских нужд - это ок, для статичных страниц тоже, но если клиент хочет встроить тинимсе внутрь сверстанного блока с поддержкой адаптива - готовьтесь к потерянным часам на багах. Мой комментарий: В целом плохая идея отдавать клиенту на откуп работу с тегами. Лучше вводить псевдотеги вида [b][/b]. Использование тегов клиентом создает 2 проблемы: кривая разметка и возможность атаки XSS. Ну а в большинстве случаев лучше совсем обойтись без доп стилизации от клиента, в этом случае будет унифицированный интерфейс (посмотрите опыт соц сетей).

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

Мой комментарий. Согласен - это усложняет страницу, делает ее более тяжелой. Вы поменяете товар 1 раз, а смотреть его будет 10000 раз. Зачем для 1 единственной сессии редактирования грузить все это на фронт?

4. Умный импорт. Давайте сделаем гибкий формат. Сразу пресекайте эту дичь. Все CRM и агрегаторы имеют строгий формат, ты либо нам даешь в таком виде либо иди в свой двор импортируй.
Мой комментарий: подобный универсализм нужен только в проектах с широким использованием в неясных условиях. Универсальность требует затрат - не только денежных. Это и более сложное решение, возможные проблемы производительности, будущие костыли в системе и т.д. Если нет обоснования универсальности - то лучше делать под конкретные текущие потребности, но при этом учитывать, что в будущем они могут все же измениться.

5. Давайте на страницу выведем 17 блоков со слайдерами и 25 блоков с картинками и 35 блоков с текстом. А че оно так медленно работает? А че в яндексе быстро? Платить за CDN клиентне захочет, потому что это плата за провайдер + плата за нашу настройку. Картинки и прочие стат штуки - это самое тяжелое при загрузке на сайт, из-за этого все будет тормозить, этоесли вы на back все забираете 1 запросом. Мой комментарий: изначально ожидания и запросы клиента часто не соответствуют ресурсам. У клиента возможностей как у стартапера с лендингом, а амбиции как у Facebook. Исходите из простоты и доступных возможностей. Все замедляющие элементы попросту проще выкинуть из системы. Не усложняйте без необходимости интерфейс. Все в угоду простоты, скорости и здравого смысла.

P.S. Делай все намного проще, принцип KISS применяйте везде где можно. Даже сложную задачу можно разбить на кучу простых. Простая задача - это максимум времени и минимум багов и геморроя Мой комментарий: Здесь нечего особо добавить. Действительно в большинстве проектов есть масса усложнений без особых на то оснований. Даже в этой статье) Можно было бы написать все от 1 лица без внутренних комментариев.

Мой P.S. Все это конечно субъективно, и где-то действительно не обойтись без crop или TinyMCE. Важно просто принимать во внимание все факторы, а не просто прожимать свои требования на проекте.

0
8 комментариев
Написать комментарий...
Борис Моренко

Мои 5 копеек: заказчик имеет обычное вэб приложение, а пожеланий по интерфейсу как будто у него SPA на React

Ответить
Развернуть ветку
Dmitry Egorov

Ммм... Так классно же.  Все будут в плюсах. Типичный win-win:
1. клиенты получат удобный и отзывчивый интерфейс, будут счастливее
2. заказчик будет доволен, что его заказчики более счастливы
3. вы денежку заработаете

Или нет?

Ответить
Развернуть ветку
Борис Моренко

Осталось переписать пол сайта)

Ответить
Развернуть ветку
Руслан Раянов
Автор

эти те самые вторые 90% проекта после выполнения первых 90%) 

Ответить
Развернуть ветку
Артем Летюшев

О, KISS, за это респект,

Ответить
Развернуть ветку
Руслан Раянов
Автор

Если бы еще заказчики думали в таком ключе...

Ответить
Развернуть ветку
Rustambek

#3 зачем js админа/менеджера грузить юзеру?

#5 про слайдеры верно, а про cdn это во многих случаях работа 5 минут, и в рамках описанных клиентов рублей 200 в год будет уходить на cdn.

Ответить
Развернуть ветку
Руслан Раянов
Автор

3 - в целом верно (не нужно грузить эти скрипты изначально для неадмина). Основная суть пункта - в усложнении UI, работающего в 2 режимах - просмотра и редактирования. 

Ответить
Развернуть ветку
Читать все 8 комментариев
null