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