LINUX.ORG.RU

Не могу выбрать как поступить правильно

 


0

1

Вообще это все веб, но читайте дальше и станет понятно что в контексте вопроса раздел девелопмент выбран верно.

У пользака есть форма с различными элементами для фильтрации результатов выборки. Эта форма различными комбинациями значений должна выдавать ЧЕТЫРЕ различных по структуре результата.

Каждый из четырех разных результатов выдает две таблицы: сводную таблицу и таблицу детализации. Разница результатов в том, что состав и кол-во ячеек в этих таблицах — разные.

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

Например для х = 1 в какой-то ячейке значение «х» это индекс из массива [Вася,Петя,Маша] и мы показываем в ячейке не «1» а «Петя». Или форматируем номер телефона из «71234567890» к виду «+7 (123) 456-78-90».

Сводная же таблица для какой-то там своей ячейки должна суммировать значения какого-то там конкретного ряда (реальных значений) из таблицы детализации. Или вычислить AVG, или показать кол-во уникальных значений. Ну и опять же форматировать к манагерскому виду.

И вот я вижу два варианта запила:

1) На каждый из четырех вариантов результатов пишем четыре отдельные захардкоженных окружения (вьюха, обработчики, каллбеки).

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

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

И хотя я сейчас могу сказать с 99% уверенностью «Ну вот эти четыре это уже все, больше других не будет». Но внутренний голос говорит мне: видимо это будет как и в тот раз когда кому-то сказали про существующие сейчас два ))

Так вот вопрос. Какой вариант правильный и почему?

ИМХО, правилен второй вариант. Хороший программист должен быть достаточно ленив, чтобы писать 4 раза код со схожей логикой, вместо этого он должен написать общую функцию.

В таком случае я всегда задаю себе вопрос «может ли возникнуть такое изменение, которое потребуется размножать на все версии функции?» (в твоём случае, например, что придётся сделать, если потребуется, скажем, добавить чередующуюся раскраску строк во всех таблицах). Если ответ положителен, то пишу общую функцию. Ибо самое сложное не написать эти 4 функции, а что-нибудь в них синхронно изменить (особенно когда уже забыл как они устроены).

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 5)
Ответ на: комментарий от KivApple

чтобы писать 4 раза код со схожей логикой

Тут есть нюанс что общая может стать слишком сложна. А это время. В результате я не сомневаюсь. Я сомневаюсь во времени и поддержке следующими поколениями. И меня действительно ломает между первым и вторым, т.к. первый хоть и тяп-ляп, но быстр и будет понятен любой обезьяне.

Ты своим ответом склоняешь меня ко второму. Я и сам к нему тяготею.

deep-purple ★★★★★
() автор топика
Последнее исправление: deep-purple (всего исправлений: 1)
Ответ на: комментарий от deep-purple

в идеальном случае второй вариант приводится к виду:

таблица это «sql запрос + описание столбца [title, type, formatter(formatter-param)] + описание параметров [тоже что и для столбца, expression]»

В итоге начальная форма - задает параметры главной таблицы, детализирующая строится по expression, которые в примитивном случае могут просто указывать на ячейки основной таблицы вида '$root.userId'

подерживается и расширяется элементарно

Deleted
()
Ответ на: комментарий от Deleted

Я не описывал нюансы. Иначе тут была бы целая поэма. В простом виде и отталкиваясь от моей инфы — ты прав, но не все так просто как хотелось бы. Все нюансы решаемы, но это время.

И все же вижу, снова — второй вариант. Ок.

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от deep-purple

Я не описывал нюансы.

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

У нас подобная схема успешно работала - скульщики могли накидать и выдать впродакшен отчет за час не рестартуя сервер. Иногда уже позже мы переносили это на java не меняя программный интерфейс отчета (т.е. не ломая выгрузку в docx например).

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

для самых забористых случаев кастомизации была возможность тупо загнать js который мог с клиента (не html, вам то проще) дергать сервер.

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

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)

Моё мнение – общую функцию делать не стоит. В будущем к тебе могут прийти с новыми вообще другими хотелками, и твои 4 куска кода, первоначально схожие, сильно диверсифицируются. В данном случае ценность кода выражается в том, насколько быстро ты сможешь его выбросить и написать новый под другие хотелки. А если в процессе выявятся повторяющиеся куски, которые достаточно абстрактные, чтобы не меняться по сиюминутным хотелкам, их и вынеси в общий модуль.

uuwaan ★★
()
Ответ на: комментарий от dzidzitop

С первого уже начали до меня. И там теперь 3.14дец, «если-что» уже наступило — надо переписывать. Что хорошего?

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от uuwaan

Это ридонли отчеты. Да, они обвешаны всякой мутью, но если откинуть перделки, то все так как понял сабвуфер.

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от makoven

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

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от deep-purple

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

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 1)

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

winlook38 ★★
()
Ответ на: комментарий от deep-purple

если напишешь абстрактное что-то - то вперёд. всё равно в каком коде ты там копаешься неизвестно. но если забуксуешь, то откатывайся к варианту 4 наборов кода.

dzidzitop ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.