Блог Сергея Копылова: заметки с тегом разработка

Uusi karjalainen musiikki

Сергей Копылов — Wed, 30 Sep 2026 23:17:55 +0300

Короче, сам я из Петрозаводска, и знал дофига местных рок-групп. Они играли крутую музыку, записывали альбомы, ну и мы тоже. Но большинство альбомов не дошло до стримингов, а затерялось где-то в пучинах вк или на дисках и кассетах.

Я, короче, нашёл 230 альбомов (и ещё найду) и сделал нашу бесплатную карельскую яндекс-музыку. Вся музыка огонь, внизу надо нажать включить всё и добавлять, что нравится, в избранное.

https://karmusic.ru

Ну или по фотке тоже можно выбирать )

Архитектура фронтенда: конфигурации

Сергей Копылов — Mon, 24 Feb 2020 20:24:20 +0300

Я долго работал над большими проектами для администирования, когда в системе есть очень много данных, и много страниц, для управления ими. Много — это, например, 500 страниц. И я использовал довольно естественный подход, когда каждая страница конфигурируется, а не программируется. Что-то вроде такого:

import ...
...

export default {
    url: "orders/:id", // Адрес страницы с подстановкой данных
    template: "formPage", // Какой шаблон страницы использовать
    data: { // Данные и обработчики данных
        value: (id) => Data.get(Orders, {id: id}, // Набор значений полей заказа с сервера
        fields: fields, // Набор полей по порядку с их параметрами, подключаемый из другого файла,
        onSave: (id) => Data.save(Orders,  {id: id})
    }
}

Это, конечно, псевдокод, но он показывает сам принцип:

Существует сервис Data, который умеет получать данные с сервера и отправлять их обратно. Вообще говоря, неважно, хранит ли он их на сервере, или в локалсторадж, к примеру, странице-то это неважно;
Существует Orders — описание того, как именно сохранять или получать заказы, внутри — просто JSON с параметрами, которые переиспользуются на разных страницах;
fields — это JSON-описание набора полей: в каком они порядке, как взаимосвязаны друг с другом, в каком из них какое поле из data отображается, какого они типа и так далее.

Получается, что новому разработчику вообще не нужно уметь программировать, а нужно только описать два JSON-файла:

Набор полей
По какому адресу и с какими дополнительными параметрами можно получить и записать данные о заказе на сервере.

Если к этому есть документация, или, хотя бы много примеров (а когда страниц 500, то и примеров в избытке) — это несложно, и, что важнее, очень быстро для исправления или переработки.

Всё. Как именно сохранять данные и когда отправлять их на сервер и в каком виде знает сервис Data; компоненты на странице знают, как именно отрисовывать поля ввода. Разработчику ненужно парится об отступах и расположении элементов, об отображении индикатора загрузки при сохранении и вообще о том, как устроен конкретный шаблон, достаточно просто его сконфигурировать.

Но оказалось, что этот способ используется очень редко потому, что дизайнеры рисуют разные макеты, потому, что кажется, что существующим шаблоном не решить задачу и так далее. Все эти проблемы надуманы — нужно стараться решить задачу существующими средствами, точечно дорабатывая их, когда не получается. Но это тема другой статьи

Программисты сайтов не знают, как работает веб, часть 2

Сергей Копылов — Sun, 23 Feb 2020 20:01:08 +0300

Вторая распространнёнейшая ошибка — переходить на новую страницу с помощью JavaScript. Это встречается повсеместно даже на самых популярных сайтах.

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

Когда не хочется переделывать

Сергей Копылов — Sun, 23 Feb 2020 18:29:26 +0300

Часто я видел такую картину: приходит новая задача на разработку нескольких страниц, программист с желанием и усердием тратит неделю или даже месяц, и разрабатывает страницы как надо. Раздел попадает к неравнодушному тестировщику и тот возвращает работу с вопросом: а как выполнить такой-то сценарий. Это обсуждается с постановщиком задачи, с разработчиком и оказывается, что никак, а сценарий важный и нужно всё переделать. Или даже раздел презентуется заказчику, а тот: ой, мы забыли о нужном сценарии, похоже, что нужно всё переделать.

Когда так происходит раз за разом, разработчику легко взбеситься. Он со знанием дела и с вниманием всё реализовал, а теперь это нужно выкинуть и начать по новой, обидно же! И разговоры начинают сводиться к тому, что необходимо хорошо продумать задачу с самого начала, поставить строгое техническое задание и всё такое. В итоге, этам постановки технического задания может затягиваться на месяцы, а в итоге всё одно — что-то забыли и нужно переделывать. И это нормально.

К сожалению, когда мы разрабатываем не космический корабль с очень чёткими требованиями и многолетним сроком разработки, невозможно учесть всё на этапе проектирования. И заказчик, и менеджер, и аналитик могут пропустить важные сценарии использования. И никакого способа надёжно измерить, все ли сценарии учтены, нет.

Кроме этого нужно действовать с другой стороны: разработчик и архитектор должны продумать, как сделать так, чтобы на подобную задачу и на её переделку тратилось мало времени. Как сделать, чтобы разработка велась не недели и месяцы, а дни и недели? Тогда первые версии будут представляться пробными, а к последующим разработчики не потеряют энтузиазма.

Короче, разработать общие правила, шаблоны страниц, поведение отдельных блоков, разработку конфигурированием, а не программированием, не рисовать макет каждой страницы; ограничить по времени как этап проектирования, так и этап разработки.