Позднее Ctrl + ↑

Архитектура фронтенда: смена фреймворка

В предыдущей части я рассказал, почему хорошо создавать конфигурации — JSON-описания поведения страниц без программирования.

У этого подхода есть ещё один прекрасный плюс: смена фреймворка перестаёт быть невыполнимой задачей.

Если вы используете конфигурации, то компоненты страницы внутри шаблона могут быть написаны на любом фреймворке: AngualrJS 1.x, Angular, Vue.js, React, Svelte и так далее. Вы даже можете их смешивать, и переписывать пошагово, когда часть компонентов использует один фреймворк, а часть — другой.

Таким образом, продукт и компания перестают быть связаны устаревшими технологиями, и если фреймворк перестанет поддерживаться, работа не остановится. Конечно, переезд не станет лёгким делом и займёт несколько месяцев, но без конфигураций страниц переехать будет просто невозможно без переписывания каждой страницы вручную. Именно так и получаются ситуации, когда в одном проекте есть Бекбон, Джейквери, Реакт разных версий и только избранные разработчики могут без страха менять что-то в легаси-модулях.

Как начинать решать задачи

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

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

Скорее всего это бьётся с ТРИЗ, где есть Идеальный конечный результат:

  • «Система сама выполняет данную функцию»;
  • «Системы нет, а функции ее выполняются (с помощью ресурсов)»;
  • «Функция не нужна».

Но близко с ТРИЗ я не знаком, поэтому предлагаю ознакомиться самостоятельно.

Про терминологию

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

Но на деле к этому примешивается другое:

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

Из своего опыта могу вспомнить, когда люди говорили мне: «о, ну нет, это же плохо, у нас нет Третьей нормальной формы в БД!» или «А это точно MVC?». На поверку оказывалось, что ребята сами плохо понимали, что же это такое, когда я просил объяснить своими словами. Хотя, конечно, MVC и Третья нормальная форма — это крутые идеи сами по себе.

Так и с речью вообще. Например, документация к AngularJS 1 написана сухим техническим языком, а к Vue.js — для всех в стили «ну смотри, здесь как-то так работает». И пытаясь научиться чему-то с первым ангуларом, ты чувствуешь себя самозванцем постоянно, а пытаясь сделать что-то на вью — исследователем. И когда я после вью вернулся на первый ангулар, я обнаружил, что там всё так же просто, хотя документация пытается убедить в обратном. Да вы и сами сравните, статью из документации об одном и том же (по смыслу и предназначению) механизме:

Слоты во Vue.js
ngTransclude в AngualarJS 1.x

Да там даже одна и таже штука называется простым словом Слот и сложным Трансклюд!

У вас нет энтерпрайза

Программисты знают, что есть как бы настоящие языки программирования C++, Go, программы на которых компилируются и выполняются очень быстро, и ненастоящие Python, PHP, JavaScript, программы на которых интерпретируются и выполняются медленно. Ну ещё особняком стоит Java, которая вроде и интерпретируемая, но и не совсем.

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

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

Подробнее об этом в статье «Когда не хочется переделывать».

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

Переключись на то, что рядом

Бывает, когда что-нибудь изучаешь или чем-нибудь занимаешься, упираешься в стенку и дальше нет роста. Что делать? Переключиться на смежную деятельность. Изучали английский? Начните изучать французский. Играли в волейбол? Начните в баскетбол. Играли на гитаре? Попробуйте фортепьяно. Программировали на фронтенде? Попробуйте бекэнд.

Я не знаю точно, как это работает, но ассоциативные цепочки в голове укладываются по-другому и ты начинаешь замечать то, на что раньше не обращал внимание, а сложные для понимания вещи вдруг становятся простыми.

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

Я долго работал над большими проектами для администирования, когда в системе есть очень много данных, и много страниц, для управления ими. Много — это, например, 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; компоненты на странице знают, как именно отрисовывать поля ввода. Разработчику ненужно парится об отступах и расположении элементов, об отображении индикатора загрузки при сохранении и вообще о том, как устроен конкретный шаблон, достаточно просто его сконфигурировать.

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

Fedora — ей вполне можно пользоваться

Короче, я решил установить линукс на компьютер потому, что лицензия Виндоус стоит слишком дорого (от 8000 рублей), связываться со взломом мне не хотелось, и было интересно, как обстоят дела с линуксом на десктопе сегодня.

Я пользовался линуксом с 2006 года, чаще всего это была Убунту. Сейчас я решил поставить Федору потому, что в ней из коробки используется интерфейс Гном 3, а он супернепривычный и суперкрасивый. Посмотрите:

Короче, в Федоре всё оказалось хорошо, если ты не занимаешься созданием видео, музыки и тебе не нужны 3D-редакторы.

Здесь есть Стим, в котором запускаются половина игр, есть Скайп, Телеграм, VS Code, Firefox. Суть Федоры в том, что несмотря на свою отрытость тебя не заставляют пользоваться только свободными программами, можно и обычными.

Скачать

Выбор региона на сайте: внутреннее устройство филиалов

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

Карелии-то и нет! И поиска нет, поэтому нужно глазами перепроверять. И нету ни на К, ни на Р, ни на П. Но я точно знаю, что банк-то в городе работает.

Звоню на горячую линию, жду 10 минут, рассказываю об этом, и мне отвечают, что это же крайне логично: это выбор филиалов, у нас Карелию Вологду и Мурманск обслуживает Санкт-Петербургский филиал. К сожалению, догадаться об этом не звоня в поддержку невозможно.

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

Проблема в том, что это только внутри банка есть какие-то филиалы, регионы обслуживания и так далее. Для клиента есть банк, и город, где он живёт. Поэтому заставлять пользователя выбирать филиалы не нужно, а нужно дать выбрать свой регион и перенаправить на нужный филиал автоматически.

Это называется «быть в мире клиента, а не компании».

Максим Ильяхов, к примеру, пишет о том, как придумывать тексты в мире читателя

Другие части про выбор региона:
Проблема с республиками
Остальной мир

Выбор региона на сайте: республики

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

Естественно, я хочу найти свою республику в любом списке на букву К. Как и тувинцы на букву Т, а дагестанцы — на Д. Но почти на всех сайтах при выборе региона республики на букву Р. Вот, например, у Билайна:

Как так, что за бред? Нужно просто написать: «Карелия», «Калмыкия», «Марий Эл» и всё. Ну если начальство требует, чтобы всё было официально, можно написать «Карелия, республика».

У Билайна-то вообще издевательство: в списке есть и Республика Карелия и Петрозаводск, но они отдельно. Выбрать Карелию, и понять потом, что нужно было выбирать Петрозаводск решительно невозможно.

Другие части про выбор региона:
Регионы и филиалы
Остальной мир

Выбор региона на сайте: остальной мир

Бывает, заходишь на сайт, а там: выберите свой город из этих десяти. И ты кликаешь в любой, лишь бы дальше перейти. Это глупость.

Нужно добавить выбор «остальной мир» и внимательно следить за айпи-адресами тех, кто заходит, чтобы открывать новые филиалы в их городах.

Ещё круче сделано на сайте Re-store, хотя они раньше тоже тупили. Теперь там можно выбрать из городов их присутствия или ввести свой город:

Там, конечно, всё равно большие города, но кто живёт в маленьких всё равно привыкли в большие гонять за покупками.

Другие части про выбор региона:
Регионы и филиалы
Проблема с республиками

Ранее Ctrl + ↓