Comments 39
Обычно под рефакторингом подразумевают реорганизацию кода из соображений необходимости использовать данные по-новому.
"Обычно" под рефакторингом понимают то, что дано в определении:
Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
"Необходимость использовать данные по-новому" противоречит "без изменения внешнего поведения". Поэтому все, что вы описываете — не рефакторинг.
Во всех обработчиках и клиентских интерфейсах рекомендуется исходить из итерируемости каждого подмножества. При начальном производстве учитывать это очень дешево.
Нет, не дешево. Особенно это не дешево в UI.
Она сразу станет доступна через единый GraphQL/REST API, никак не повредив старым абстракциям и связям, а значит зависимому от них коду.
Это все прекрасно, но кто и как обеспечит трансляцию старых связей в новые и обратно все время, пока поддерживается обратная совместимость?
А какие там сложности в UI?
Ну так, если исходить из "итерируемости каждого подмножества", то у вас на форме заказа будет не один покупатель, а [0...n]. Это больно проектировать.
А боль-то в чём? Обычный мультиселект везде будет.
Покупатель на форме заказа — это не обязательно одно поле. Туда много всякой интересной информации подтягивается.
И когда пользователь там вместо одного набора видит таблицу, у пользователя возникает разумный WTF: это вообще как? Что значит "много покупателей"? А звонить кому? А платит кто? А отменить кто может?
А адреса доставки? Тоже много? А это как, если у нас заказ из ровно одного предмета?
И таким образом мы бесплатно получили фичу "покупка вскладчину". Платить может кто угодно, главное набрать нужную сумму. Звонить любому. Отменять может любой. Адрес выбирается по договорённости в зависимости от времени доставки и адреса отправки. Опа, ещё одна фича "доставка туда, где вы находитесь, а не туда, где вас в это время нет".
И таким образом мы бесплатно получили фичу "покупка вскладчину".
Нет, не получили. Для ее реализации еще надо много что сделать, кроме добавления множества покупателей.
Звонить любому.
… а он вообще не в курсе, что это, он только денег занес.
Отменять может любой.
Упс, нет, только организатор покупки.
Адрес выбирается по договорённости в зависимости от времени доставки и адреса отправки.
Ага, в этот момент у вас началась адская пляска со стоимостью доставки и налогами. Ой.
Опа, ещё одна фича "доставка туда, где вы находитесь, а не туда, где вас в это время нет".
Вот только это не бесплатная для разработки фича.
Все вот эти "фичи", которые вы предложили — они пользователю (продавцу, не покупателю) не нужны, они его процесс усложняют многократно, он не хочет с ними дело иметь.
Ну, если не хочет, то всегда может указать в параметрах свойства минимальное и максимальное число элементов.
… и при min=max=1 система должна себя вести, как обычная с одним покупателем. Прекрасная идея, да.
Только стоимость разработки этого не равна стоимости разработки системы, где покупатель всегда один. Надо нарисовать и заимплементить два UI, надо сделать разные формы отчетности, и так далее. Ничего невозможного, конечно же. Но не бесплатно, совсем.
Это делается 1 раз за пару часов на старте проекта и далее реиспользуется во всех формах.
Нет, не делается. Даже банально по временным затратам это дольше, и переиспользуемость не такая высокая, как вам кажется.
Вы, мне кажется, мыслите технологическим решением. А я говорю обо всем, что участвует в бизнес-процессе — дизайн, формы, отчеты, правила и так далее.
"Обычная" максима по поводу размерности данных говорит нам о том, что мы должны оперировать максимум тремя возможными состояниями: 0, 1, и N. Три их — вот ровно потому, что способ обработки каждого — различен, и эта разница продолжается во все стороны, от кода до UI и прочего I/O. Написать код так, чтоб эти три состояния всегда были закатаны в одно [0...N] конечно же вполне возможно, и вы даже сэкономите чуть-чуть (реально чуть-чуть) строк, если у вас и вправду все три состояния востребованы. Но когда у вас востребовано только состояние 1, а вы пишете код под [0...N] — вы напишете очень много лишнего.
Я не пишу лишнего, так как пишу всё это один раз, а далее переиспользую. Я ж не тупой 100500 форм руками реализовывать с кастомным дизайном для каждой из них.
И что же именно вы пишете "один раз"? Компонент-таблицу, способную обработать мощность [0...N] входящих данных (таблиц) уже написали, надеюсь?
В том числе. А в чём вы видите проблему с реализацией такой таблицы?
Как именно она выглядит?
В каждой ячейке от 0 до N значений, очевидно.
А почему не таблица с возможностью выбора текущего индекса?
Я не смог распарсить вашу фразу.
В этом, видимо, и вся проблема.
Потому что "таблица мощностью N" всегда распадается на компонент-итератор, и компонент-таблицу. И нет ни одной практической причины совмещать их в какой-то готовый для употребления пакет: все случаи использования подобных конструкций достаточно редки, и среди них нет явного лида и аутсайдеров (это вам не Файрфокс, который, как широко известно в узких кругах, "никто не использует").
Как конкретно будут взаимодействовать таблица и итератор, и получите ли вы в итоге таблицу + селектор, список таблиц, таблицу со списком содержимого в каждой ячейке, или еще какую-то комбинацию, которая всё же будет содержать в себе компонент-таблицу — зависит от конкретного кейса. Вы реализовали один из кейсов и пытаетесь это представить как "написал один раз и переиспользую", в то время как если вам потребуется другой кейс — всё ваше "написал и переиспользую" оказывается ненужным.
Вы специально используете специфичную для вашего проекта терминологию, чтобы ваш собеседник не понял о чём вы говорите?
Насколько я понял вы перечислили 3 варианта отображения одного и того же подграфа данных. Нет никакой проблемы 1 раз реализовать каждый из этих вариантов, и далее переключаться между ними переключая пару флагов.
Нет никакой проблемы 1 раз реализовать каждый из этих вариантов
Конечно нет. Речь о том, что реализовывать их заранее, до появления необходимости — довольно бессмысленная деятельность. Вы вот реализовали один из вариантов, и считаете, что у вас есть универсальное решение. А оно совершенно не универсальное.
Ну и в пределе ваш тезис — это "нет никакой проблемы 1 раз написать весь нужный вам код". Да нет, есть в этом проблема, особенно если спуститься с архитектурных орбит на землю.
Вы специально используете специфичную для вашего проекта терминологию, чтобы ваш собеседник не понял о чём вы говорите?
Термины (в приложении к веб UI) "таблица", "компонент", "селектор", "список" — для вас являются чуждыми и непонятными?
Не помню, чтобы я говорил что-то о "заранее". Я говорю, что разумных вариантов визуализации весьма ограниченное число и каждый реализуется лишь один раз, а потом переиспользуется. В том числе в разных комбинациях.
"компонент-итератор", "таблица мощностью N" - всё это не понятно что такое без пояснений.
Я говорю, что разумных вариантов визуализации весьма ограниченное число и каждый реализуется лишь один раз.
Я в курсе этой вашей точки зрения, про "весьма ограниченное число вариантов". Её беда в том, что она не бьется с реальностью. Как вот недавно с браузерами было.
"компонент-итератор", "таблица мощностью N" — всё это не понятно что такое без пояснений.
Но… первое это самый банальный реакт, который все видели, не? HOC, который рендерит список (итерируясь по входным данным)?
А про второе тут вся ветка. "Таблица мощностью N" — N таблиц.
Она прекрасно бьётся с реальностью. Для любого свойства обычно есть не более 5 осмысленных вариантов отображения, основные из которых: список, таблица, галерея. Если вы не согласны - можете привести ещё хотя бы 3.
Итерирование через НОС я ещё не встречал, да и смысла в этом не вижу. Речь я вёл про более высокоуровневые компоненты типа "Сущность", "Свойство" и тп.
Я ж не тупой 100500 форм руками реализовывать с кастомным дизайном для каждой из них.
А, это все объясняет.
Наши заказчики хотят формы с кастомным дизайном.
Пока что совершенно непонятно, как это все будет в реальности. Если у вас есть реальный код, использующий эту технологии -- например, исходники этого вашего Shake, было бы интереснее.
Или хотя бы куски кода, иллюстрирующие данную статью. Без них -- очень много обещаний, хороший замах, но что в результате получается -- вообще неясно.
Прочитал, ощущение что окунулся в какие-то влажные мечты frontend разработчиков об избавлении от backend разработчиков. Путанный набор мыслей, никакой конкретики, не понятно позиционирование и целевая аудитория. Открыл discord, там рассуждение про проект Венера и всеобщее благо. Дальше можно не продолжать...
Мы рассматривали как ЦА только бекендеров и фулстеков. Такое восприятие фронтендеров мы еще не видели... Это очень ценно. Спасибо. Кажется у нас есть теперь новая ЦА...
Так и есть, там даже выделено:
больше не нужен backend developer.
Ребята-веганы хотят сделать "мир лучше" без backend developer-ов!
да не описана самая большая проблема когда разделяешь при высокой нагрузки - это атомарность без транзакций и локов.
Например Видео хранит теперь только кол-во лайков , а кто лайкнул в отдельной таблице (или бд).
и теперь твой код превращается в две строки....
[перемещено]
Фактор рефакторинга