{
    "version": "https:\/\/jsonfeed.org\/version\/1",
    "title": "Блог Сергея Копылова: заметки с тегом разработка",
    "_rss_description": "Блог Сергея Копылова",
    "_rss_language": "ru",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": "",
    "_itunes_explicit": "",
    "home_page_url": "https:\/\/www.blog.sergeykopylov.ru\/tags\/razrabotka\/",
    "feed_url": "https:\/\/www.blog.sergeykopylov.ru\/tags\/razrabotka\/json\/",
    "icon": "https:\/\/www.blog.sergeykopylov.ru\/user\/userpic@2x.jpg?1574324497",
    "author": {
        "name": "Сергей Копылов",
        "url": "https:\/\/www.blog.sergeykopylov.ru\/",
        "avatar": "https:\/\/www.blog.sergeykopylov.ru\/user\/userpic@2x.jpg?1574324497"
    },
    "items": [
        {
            "id": "122",
            "url": "https:\/\/www.blog.sergeykopylov.ru\/all\/uusi-karjalainen-musiikki\/",
            "title": "Uusi karjalainen musiikki",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/www.blog.sergeykopylov.ru\/pictures\/favicon3.png\" width=\"512\" height=\"512\" alt=\"\" \/>\n<\/div>\n<p>Короче, сам я из Петрозаводска, и знал дофига местных рок-групп. Они играли крутую музыку, записывали альбомы, ну и мы тоже. Но большинство альбомов не дошло до стримингов, а затерялось где-то в пучинах вк или на дисках и кассетах.<\/p>\n<p>Я, короче, нашёл 230 альбомов (и ещё найду) и сделал нашу бесплатную карельскую яндекс-музыку. Вся музыка огонь, внизу надо нажать включить всё и добавлять, что нравится, в избранное.<\/p>\n<p><a href=\"https:\/\/karmusic.ru\">https:\/\/karmusic.ru<\/a><\/p>\n<p>Ну или по фотке тоже можно выбирать )<\/p>\n",
            "date_published": "2026-09-30T23:17:55+03:00",
            "date_modified": "2026-09-30T23:18:26+03:00",
            "image": "https:\/\/www.blog.sergeykopylov.ru\/pictures\/favicon3.png",
            "_date_published_rfc2822": "Wed, 30 Sep 2026 23:17:55 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "122",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/www.blog.sergeykopylov.ru\/pictures\/favicon3.png"
                ]
            }
        },
        {
            "id": "44",
            "url": "https:\/\/www.blog.sergeykopylov.ru\/all\/arhitektura-frontenda-konfiguracii\/",
            "title": "Архитектура фронтенда: конфигурации",
            "content_html": "<p>Я долго работал над большими проектами для администирования, когда в системе есть очень много данных, и много страниц, для управления ими. Много — это, например, 500 страниц. И я использовал довольно естественный подход, когда каждая страница конфигурируется, а не программируется. Что-то вроде такого:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">import ...\r\n...\r\n\r\nexport default {\r\n    url: &quot;orders\/:id&quot;, \/\/ Адрес страницы с подстановкой данных\r\n    template: &quot;formPage&quot;, \/\/ Какой шаблон страницы использовать\r\n    data: { \/\/ Данные и обработчики данных\r\n        value: (id) =&gt; Data.get(Orders, {id: id}, \/\/ Набор значений полей заказа с сервера\r\n        fields: fields, \/\/ Набор полей по порядку с их параметрами, подключаемый из другого файла,\r\n        onSave: (id) =&gt; Data.save(Orders,  {id: id})\r\n    }\r\n}<\/code><\/pre><p>Это, конечно, псевдокод, но он показывает сам принцип:<\/p>\n<ul>\n<li>Существует сервис <b>Data<\/b>, который умеет получать данные с сервера и отправлять их обратно. Вообще говоря, неважно, хранит ли он их на сервере, или в локалсторадж, к примеру, странице-то это неважно;<\/li>\n<li>Существует <b>Orders<\/b> — описание того, как именно сохранять или получать заказы, внутри — просто JSON с параметрами, которые переиспользуются на разных страницах;<\/li>\n<li><b>fields<\/b> — это JSON-описание набора полей: в каком они порядке, как взаимосвязаны друг с другом, в каком из них какое поле из data отображается, какого они типа и так далее.<\/li>\n<\/ul>\n<p>Получается, что новому разработчику вообще не нужно уметь программировать, а нужно только описать два JSON-файла:<\/p>\n<ul>\n<li>Набор полей<\/li>\n<li>По какому адресу и с какими дополнительными параметрами можно получить и записать данные о заказе на сервере.<\/li>\n<\/ul>\n<p>Если к этому есть документация, или, хотя бы много примеров (а когда страниц 500, то и примеров в избытке) — это несложно, и, что важнее, очень быстро для исправления или переработки.<\/p>\n<p>Всё. Как именно сохранять данные и когда отправлять их на сервер и в каком виде знает сервис <b>Data<\/b>; компоненты на странице знают, как именно отрисовывать поля ввода. Разработчику ненужно парится об отступах и расположении элементов, об отображении индикатора загрузки при сохранении и вообще о том, как устроен конкретный шаблон, достаточно просто его сконфигурировать.<\/p>\n<p>Но оказалось, что этот способ используется очень редко потому, что дизайнеры рисуют разные макеты, потому, что кажется, что существующим шаблоном не решить задачу и так далее. Все эти проблемы надуманы — нужно стараться решить задачу существующими средствами, точечно дорабатывая их, когда не получается. Но это тема другой статьи<\/p>\n",
            "date_published": "2020-02-24T20:24:20+03:00",
            "date_modified": "2020-02-24T20:24:14+03:00",
            "_date_published_rfc2822": "Mon, 24 Feb 2020 20:24:20 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "44",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css",
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": []
            }
        },
        {
            "id": "24",
            "url": "https:\/\/www.blog.sergeykopylov.ru\/all\/programmisty-saytov-ne-znayut-kak-rabotaet-veb-chast-2\/",
            "title": "Программисты сайтов не знают, как работает веб, часть 2",
            "content_html": "<p>Вторая распространнёнейшая ошибка — переходить на новую страницу с помощью JavaScript. Это встречается повсеместно даже на самых популярных сайтах.<\/p>\n<p>Проблема здесь в первую очередь в том, что ты не можешь открыть сразу несколько ссылок с одной страницы в разных вкладках. Сломали веб на пустом месте: помешаю-ка пользователям использовать привычный механизм и ничего не предложу взамен.<\/p>\n",
            "date_published": "2020-02-23T20:01:08+03:00",
            "date_modified": "2020-10-12T22:14:37+03:00",
            "_date_published_rfc2822": "Sun, 23 Feb 2020 20:01:08 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "24",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "22",
            "url": "https:\/\/www.blog.sergeykopylov.ru\/all\/kogda-ne-hochetsya-peredelyvat\/",
            "title": "Когда не хочется переделывать",
            "content_html": "<p>Часто я видел такую картину: приходит новая задача на разработку нескольких страниц, программист с желанием и усердием тратит неделю или даже месяц, и разрабатывает страницы как надо. Раздел попадает к неравнодушному тестировщику и тот возвращает работу с вопросом: а как выполнить такой-то сценарий. Это обсуждается с постановщиком задачи, с разработчиком и оказывается, что никак, а сценарий важный и нужно всё переделать. Или даже раздел презентуется заказчику, а тот: ой, мы забыли о нужном сценарии, похоже, что нужно всё переделать.<\/p>\n<p>Когда так происходит раз за разом, разработчику легко взбеситься. Он со знанием дела и с вниманием всё реализовал, а теперь это нужно выкинуть и начать по новой, обидно же! И разговоры начинают сводиться к тому, что необходимо хорошо продумать задачу с самого начала, поставить строгое техническое задание и всё такое. В итоге, этам постановки технического задания может затягиваться на месяцы, а в итоге всё одно — что-то забыли и нужно переделывать. И это нормально.<\/p>\n<p>К сожалению, когда мы разрабатываем не космический корабль с очень чёткими требованиями и многолетним сроком разработки, невозможно учесть всё на этапе проектирования. И заказчик, и менеджер, и аналитик могут пропустить важные сценарии использования. И никакого способа надёжно измерить, все ли сценарии учтены, нет.<\/p>\n<p>Кроме этого нужно действовать с другой стороны: разработчик и архитектор должны продумать, как сделать так, чтобы на подобную задачу и на её переделку тратилось мало времени. Как сделать, чтобы разработка велась не недели и месяцы, а дни и недели? Тогда первые версии будут представляться пробными, а к последующим разработчики не потеряют энтузиазма.<\/p>\n<p>Короче, разработать общие правила, шаблоны страниц, поведение отдельных блоков, разработку конфигурированием, а не программированием, не рисовать макет каждой страницы; ограничить по времени как этап проектирования, так и этап разработки.<\/p>\n",
            "date_published": "2020-02-23T18:29:26+03:00",
            "date_modified": "2020-02-23T18:29:22+03:00",
            "_date_published_rfc2822": "Sun, 23 Feb 2020 18:29:26 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "22",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        }
    ],
    "_e2_version": 3559,
    "_e2_ua_string": "E2 (v3559; Aegea)"
}