Топ-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. Важно просто принимать во внимание все факторы, а не просто прожимать свои требования на проекте.

{ "author_name": "Руслан Раянов", "author_type": "self", "tags": [], "comments": 8, "likes": 5, "favorites": 19, "is_advertisement": false, "subsite_label": "dev", "id": 109829, "is_wide": true, "is_ugc": true, "date": "Sat, 29 Feb 2020 14:33:40 +0300", "is_special": false }
IPQuorum
Развитие технологических стартапов в России: барьеры и возможности
Внедрение решений Индустрии 4.0 в крупных промышленных предприятиях тормозят не только кризис и условия пандемии…
Объявление на vc.ru
0
8 комментариев
Популярные
По порядку
Написать комментарий...
2

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

Ответить
0

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

Или нет?

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

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

Ответить
0

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

Ответить

Прямой эфир