Меня, бывает, спрашивают о том, как что-то реализовать, когда элементов очень много.<\/p>\n
Например:<\/p>\n
\nНа странице отображены 100 000 товаров и у каждого есть кнопки действий. Как указать обработчик событий для этих кнопок так, чтобы не множить функции? Постраничного листания нет, подгрузки при прокрутке тоже.<\/p>\n<\/blockquote>\n
или<\/p>\n
\nНа странице отображаются 5 000 товаров с партиями, остатками, необходимо изменять эти данные. Что бы вы стали делать, если бы страница стала тормозить? Как бы вы искали источник проблемы?<\/p>\n<\/blockquote>\n
Да никак бы я не искал источник проблемы. Потому, что источник уже найден — это вывод на экран тысяч экземпляров данных.<\/p>\n
В этом нет никакой необходимости. Никакой человек не может управлять данными, когда их тысячи. Нашему мозгу уже и 30 штук — довольно много. Правильное решение: сделать так, чтобы на фронтенде не отображались, не хранились, и не обрабатывались тысячи элементов. Тогда и не нужно будет решать эти надуманные задачи.<\/p>\n", "date_published": "2020-04-01T09:02:31+03:00", "date_modified": "2020-04-02T07:07:14+03:00", "_date_published_rfc2822": "Wed, 01 Apr 2020 09:02:31 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "83", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "81", "url": "https:\/\/www.blog.sergeykopylov.ru\/all\/horosho-postavlennaya-zadacha\/", "title": "Хорошо поставленная задача", "content_html": "
Разберём случай, когда до дизайнера или разработчика доходит какая-то задача, сформированная цепочкой менеджеров и аналитиков по чаяниям заказчика на конкретном примере.<\/p>\n
Возьму пример из области медицины, в которой проработал несколько лет. В общем смысле задача обычно звучит как-то так: «Отобразить список свидетельств о рождении, которые регулярно приходят из медицинских организаций.»<\/p>\n
Обычно до разработчика доходит какая-то такая задача:<\/p>\n
«Необходимо создать страницу с отображением всего списка свидетельств, с возможностью изменения набора столбцов и фильтров. Изначальные наборы столбцов такие-то, наборы фильтров такие-то. Обеспечить разный уровень доступа для разных пользователей, возможность создания и подписания новых документов, выгрузки в EXCEL, XML, CSV, PDF, Word сохранения истории изменений. Ктопку такую-то разместить здесь, такую-то здесь, вот эту сделать зелёной. Набор полей документа формируется с учётом ФЗ № такой-то такой-то, ...»<\/p>\n
И так ещё 10 страниц. Это совершенно ужасная постановка задачи, которая одновременно подразумевает, что дизайнер или разработчик тупой, как дрова, и может действовать только по алгоритму. И с другой стороны, она перекладывает на разработчика самые ресурорсоёмкие операции, как, например, поиск набора полей в каком-нибудь приложении к федеральному закону.<\/p>\n
Разработчику говорят, что делать, но не говорят, почему. Нет ответов на следующие вопросы:<\/p>\n
\n
- Почему мы вообще это делаем? Какую проблему заказчика мы решаем?<\/li>\n
- Зачем нужна возможность изменения набора столбцов и фильтров?<\/li>\n
- Что значит разный уровень доступа? Кто вообще будет этим пользоваться и в каком случае?<\/li>\n
- Каким образом должна быть реализована подпись? Физическим ключом в USB? Паролем? Электронной подписью?<\/li>\n
- Что значит «отображение всего списка свидетельств»? Сколько их всего? А если несколько миллионов? Вы уверены, что кому-то нужно сразу видеть миллион свидетельств за несколько лет?<\/li>\n
- Выгрузка миллионов записей из БД с внешними ключами и данными из других таблиц и форматированием в каком-то формате займёт очень много времени и сильно нагрузит базу. Существует ли реальный сценарий использования этой функции?<\/li>\n<\/ul>\n
Ну и так далее. Зато есть ненужные подробности о расположении кнопок и перечисления «как бы» форматов файлов выгрузки. Конечно, здесь очевидно, что менеджеры не смогли узнать реальную проблему заказчика и как решить именно её имеющимися средствами.<\/p>\n
Неопытный разрабочик просто возьмёт это в реализацию не думая и начнёт программировать шаг за шагом. Задача окажется трудновыполнимой даже за несколько месяцев (что его тоже не побеспокоит), всё будет тормозить потому, что для такого общего решения недостаточно просто добавить индексы в БД, чтобы всё работало быстро, и в конце концов, когда задачу покажут заказчику, у него полезут глаза на лоб и он удивится, как такую неповоротливую махину можно было делать несколько месяцев, когда она всё равно не работает, потому, что оттестировать все варианты поведения и отображения такой махины невозможно.<\/p>\n
Если же пообщаться с заказчиком, слушая не только предложенное решение, а ещё его проблемы, то всё станет на свои места. Окажется, что с этим списком должны работать такие-то врачи и работники загса. Что права на изменение и добавление такие-то. Что любые поля нужно отображать, чтобы было видно, отфильтровалось или нет (конечно, здесь нужно придумать другое решение), что вывод всех документов сразу не нужен, а нужен в разрезе по медицинской организации.<\/p>\n
Такую задачу уже можно сделать за неделю, и, даже если какие-то из требований были описаны неверно, у нас есть ещё много времени, чтобы это исправить.<\/p>\n
А может оказаться, что сегодняшнего списка документов любых типов с фильтрацией по типу уже достаточно для решения этой задачи и нам не нужно делать ничего, кроме настройки шлюза для получения этих документов от медицинских организаций. Вот и экономия месяцев труда команды на пустом месте.<\/p>\n", "date_published": "2020-03-24T09:37:32+03:00", "date_modified": "2020-06-09T15:23:09+03:00", "_date_published_rfc2822": "Tue, 24 Mar 2020 09:37:32 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "81", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } } ], "_e2_version": 3559, "_e2_ua_string": "E2 (v3559; Aegea)" }