Все знают, что повторные участки кода лучше выделить в отдельную единицу (переменную, функцию, класс, whatever...). Но вот такой вопрос: когда мы хотим доработать эту выделенную единицу, то как определить, нам лучше ввести параметр и этот код будет работать в двух режимах, или лучше нам сделать копипасту этой единицы и все, кто её используют пусть продолжают её использовать, а мы новую единицу допилим под новые требования и её будут юзать новые потребители. В чем может быть критерий для такого выбора?

Вот по аналогии, есть правило трех Фаулера: код можно копипастить, но только один раз, и если ты создаешь третью копию, тогда лучше выдели общий функционал в отдельную единицу. Тут криетрий классный и ясный - две копии (три экземпляра). А какой может быть критерий превращения общей отдельной единицы обратно в две разные копии с целью переделки одной из них, вместо дополнительной параметризации одной из них?

ПрограмёрЯ это обычно интуитивно понимаю.

А у меня психологический затык происходит вот в какой ситуации. Есть такая шняга как форма справочника. Это обычная форма, в ней таблица, заголовок, элементы управления: добавить, обновить, сохранить, фильтры... ну короче формочка-диалог-виджет. Эта формочка собирается из более мелких функций. Таблица, каждый контрол - все это отдельные функции. Колонки таблицы тоже функциями собираются. Ну источник данных - тоже функция.

Так вот почему же у меня идет жесточайшее внутреннее сопротивление создания единого общего компонента для этой формочки, чтобы на входе можно было задавать параметры, которыми эти формочки отличаются: источник данных, список колонок какие выводить, порядок и т.п. Почему же мы продолжаем на каком-то безотчетном чувстве создавать новые формы именно за счет копипасты? Почему даже когда мы создали этот общий компонент, то у нас возникает страх, что это ошибочный путь? Может потому что параметризация такого компонента составляет по объему кода 40% от самого компонента? Или может быть потому что сам общий компонент получился такой сложный, что всем проще копипастой, потому что этот копипастный компонент так легко читается с листа!

Может быть если объем параметризации становится слишком большим, то это признак вернуться обратно к копипасте?

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

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

egorychИли вот другой критерий, на выбор: если для введения параметра требуются слишком большие изменения в программном объекте, а времени/сил/желания на это нет - то проще сделать копипаст, но тут уже ССЗБ.

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

Попадалово с копипастами - это если в них во все что-то надо сразу внести новое одновременное. Тогда будет много ручной работы. Но я сейчас думаю может эту проблему как-то исхитриться решить за счет плагинов-хуков, потому что ведь эти копипастные компоненты все собираются из других компонентов, которые уже являются абстракциями. Например, кнопка обновить или кнопка добавить. Используются renderButtonAdd(), renderButtonUpdate(), а вот их расположение уже задается в каждой копипасте отдельно, что позволяет в одном справочнике add, up, а в другом up, add, в а третьем up, add, close и т.д.

Опять же знаете, во многих программных продуктах например модели для данных генерят с помощью скелетов на основе схемы данных. А это ведь копипаста, хоть и автоматная. Значит копипаста не всегда вне закона. Вот где критерий только?

egorychЕсли код важный, лучше не лениться, а выделять общий код в отдельную единицу. За вторым режимом частенько следует третий, четвёртый, etc, и это тоже стоит учитывать при принятии решения.

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

egorychLumixМожет потому что параметризация такого компонента составляет по объему кода 40% от самого компонента?что-то вы там у себя не до параметризовали.


Знаете есть такой подход, параметризация объектом.

new A(new AConf())

Так вот тут речь о ситуации, когда у AConf такой интерфейс, то понимание как работает код внутри А - это просто смерть! И когда ты сидишь и заполняешь параметризатор для очередной формы, ты вдруг думаешь: ёпрст, проще руками. То есть из-за того, что происходит существенный попил частей алгоритма между двумя сторонами: условно половина алгоритма в абстракции, а другая часть в конкретике, то попытка отладить работу этой конструкции превращается в ад и младшие кодеры просто уходят в прокрастинацию и страх. При этом копипастные алгоритмы, где ту же саму параметризацию приходится делать тупо за счет обычной замены например было companyId а заменили на lobbyId и т.д. то есть параметризация отрывает глаз от контекста и заполняя параметры младшие кодеры перестают видеть а что именно делает этот параметр, тогда как в копипасте они видят весь процесс целиком.

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

user()->get(id);

Тут мне похер как оно будет доставаться, поэтому это может быть абстрактный компонент.

user()->get(id, fatFilter, frameLimit, isUsedOnce)

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

Как идейка?

Dima TПочитал и не понял почему наследование не используется? По хорошему должна быть целая иерархия классов.
Сделал класс "Стандартный справочник" а для извращенных случаев создал на его основе класс "Справочник с извращениями" и в нем дописал подсвечивание и т.п.

Отличный пример.

Вопрос звучит так: зачем для "создания справочника с извращениями" наследоваться от "стандартный справочник". Наша практика показывает, что для того, чтобы подготовить класс "стандартный справочник" к форме, пригодной для наследования, код этого "стандартного справочника" становится извращенным и когда от него ещё и извращенческий справочник наследуется, то тогда вообще жопа полная наступает. Особенно когда это ещё этот код открывает младший кодер.

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

Но если "прищуриться", то можно заметить, что справочник с извращениями является копипастой со стандартного справочника.

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

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

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

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

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

Я вот ещё что сегодня понаблюдал на эту тему.

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

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

например




то же самое на общем компоненте




то есть внешний компонент основан на той же самой точке изменения.

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

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

Dima Tмы говорим про справочники или обо всем на свете?

Мы обсуждаем общетеоретическую концепцию копипаст vs абстракция, но на примере справочников.

Dima TЧто можно дописывать например в коде кнопки "Добавить" ? Там вызов формы правки новой записи. Это никак ни от чего не зависит, и никогда не поменяется.

Какой вы наивный! Даже в таком малюсеньком элементе может дохера что поменяться. Не говоря уже о расположении и показа этой кнопки в зависимости от тех или иных условий. Кнопка может стать иконкой, а может на Ctrl повешают дополнительный функционал, ещё к ней можно прикрутить контекстное меню с опциями создания. Там можно такой зоопарк устроить, то мама не горюй 2: первая кровь.

Dima TЗачем этот код копипастить ?

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

Dima TА код может быть не простым. Например у меня все формы правки независимы, т.е. можно добавлять одновременно сколько угодно записей, поэтому код не одна строчка, и операция сохранения не тривиальна, т.к. по закрытию форма правки должна вызвать родительскую форму (с гридом), вывести ее на первый план, отрефрешить чтоб новый элемент появился и встать на него. Это тоже прописывать в каждую форму?

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

Dima TМожно конечно сказать если изначально все правильно сделано то оно скопипастится и не потребует доработок.

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

Я пока только не знаю как это теоретически обосновать. Пока это чистая эмпирика.

Dima TНо кто сказал что изначально все правильно сделано?

У нас нет термина правильно / неправильно, мы пользуемся термином "вероятность, что потребуется изменение".

Dima TПонимание того "как правильно" приходит после окончания разработки, а при копипасте исправлять такие косяки проблематично.

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

Dima TНапример у меня есть свой класс грида, все остальные производные от него, изначально я заложил туда весь полезный (как я считал на тот момент) функционал сверх стандартного, но через пять лет понял что классная фича скопировать все содержимое грида в буфер обмена чтоб потом вставить в эксель например, час работы, перекомпиляция и все мои гриды по правой кнопке копируют свое содержимое в буфер обмена. А с копипастом я бы перелопачивал все написанное за пять лет.

Пример тухлый, потому что у нас бы за 5 лет накопилось 186 видов разных гридов, а если бы мы спихали бы их один грид и это все управлялось бы параметрами, то потом в этом гриде вообще ни один человек не смог бы разобраться, не уронив все остальные.

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

Dima TНа мой взгляд главный принцип ООП это повторное использование кода (не путать с созданием нескольких однотипных объектов во время работы программы), вот к этому и надо стремится, чтоб одинаковый код был написан в одном месте, а не размножен копипастом.

Код предназначенный для реюза в условиях высокой степени волатильности становится непонятным даже для автора этого кода. Когда непараметризированная версия грида 67 варианта занимает 80 строчек, а абстрактный грид на 183 вида с 340 параметрами состоит из 2800 строчек. Вот в чем жопа.

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


Dima TИ не надо бросаться в другую крайность в попытке один раз написать код на все случаи жизни.

А это и не получится. Ума не хватит. Крыша съедет, прежде чем закончишь. А если и закончишь, обслуживать этого монстра будет некому.

Ещё набрел на такое интересное явление - называется сниппет (snippets). Судя по описанию это как раз некие участки кода, типа шаблонов, которые предназначены для размножения именно копипастой.

То есть похоже, что программный код "легализованный" для копипасты официально не просто приемлим, а даже имеет свое название - сниппеты.