Один мой студент-выпускник-аспирант недавно сформулировал.
Архитектура исследовательских проектов редко бывает удачной с первого раза.
Обычно приходится по мере развития проекта пересматривать.
Вопрос: когда, в какой момент?
Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить.
А у народа с этим как дело обстоит?

Здравствуйте, LaptevVV, Вы писали:

LVV>Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить.
LVV>А у народа с этим как дело обстоит?

Это скорее рефакторинг. Изменение архитектуры — это что-то более глобальное.

LVV>>Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить.
LVV>>А у народа с этим как дело обстоит?

A>Это скорее рефакторинг. Изменение архитектуры — это что-то более глобальное.
Не. Вот именно пересмотр всей базовой части.
Если рефакторинг, то большой, затрагивающий много классов и их отношения.

Здравствуйте, LaptevVV, Вы писали:

LVV>Обычно приходится по мере развития проекта пересматривать.
LVV>Вопрос: когда, в какой момент?

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

LVV>Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить.
LVV>А у народа с этим как дело обстоит?

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

LVV>А у народа с этим как дело обстоит?
К копи-пасте отношусь просто — если код объёмом до одного класса/файла то один раз не копи-паста, один раз это даже хорошо — это же повторное использование кода , вот если возникло желание сделать в проекте ещё и 3-ю версию копи-пасты — значит пора рефакторить, чтоб больше такой фигни никогда не было. Одно исключение — если понадобилось вносить в две версии синхронные изменения — пора выделять общее и выносить разное не дожидаясь рождения 3-ей.

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

Здравствуйте, hi_octane, Вы писали:

LVV>>А у народа с этим как дело обстоит?
_>К копи-пасте отношусь просто — если код объёмом до одного класса/файла то один раз не копи-паста, один раз это даже хорошо — это же повторное использование кода , вот если возникло желание сделать в проекте ещё и 3-ю версию копи-пасты — значит пора рефакторить, чтоб больше такой фигни никогда не было. Одно исключение — если понадобилось вносить в две версии синхронные изменения — пора выделять общее и выносить разное не дожидаясь рождения 3-ей.
Абсолютно теми же словами мой студент-аспирант об этом рассказывает.
Вот просто как будто по одной бумажке читаете...

_>К архитектуре и её изменениям тоже отношусь просто — главное чтоб не мешала. Но если на борьбу с архитектурой ушло времени больше чем на собственно решение задачи — пора рефакторить.
То есть, рефакторить архитектуру...
Именно так он и говорит.

Здравствуйте, LaptevVV, Вы писали:

LVV>Один мой студент-выпускник-аспирант недавно сформулировал.
LVV>Архитектура исследовательских проектов редко бывает удачной с первого раза.
LVV>Обычно приходится по мере развития проекта пересматривать.
LVV>Вопрос: когда, в какой момент?
LVV>Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить.
LVV>А у народа с этим как дело обстоит?

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

Ну, а студент молодец, наконец-то обнаружил, что куски кода не желательно просто копипастить и допиливать.

Один раз — случайность, два — совпадение, три — закономерность.

Известная народная мудрость.
Если вовремя структурировать выявленные закономерности, то получим следование принципу DRY.

У меня есть сомнения в том что студенты что то в этом понимают, все таки эта часть программирования требует намного больше опыта, которого у них нет.
И вообще желание копипастнуть не всегда есть зло. Есть куча моментов когда в начале все похоже и решается копипастом а потом допиливается и просто удобнее с чего то написать.
Зло копипасты максимум в генерации ошибок, не преувеличивайте.
Самый просто пример: когда вы начинаете реализовывать большой интерфейс(а у вас есть уже 100500 его реализаций для парсинга файлов например) хотите вы этого или нет то часто работа начинается с копипасты а потом переименовыванием и переделкой некоторых вещей. И вынос этого дохлого небольшого куска с виду общего кода в промежуточный класс приведет только к большим неудобствам.

Здравствуйте, Trrrrr, Вы писали:

T>У меня есть сомнения в том что студенты что то в этом понимают, все таки эта часть программирования требует намного больше опыта, которого у них нет.
Опыт у этого конкретно товарища как раз есть.
ШЕСТЬ лет работы над одной системой.
6 раз переделывалась именно архитектура — в первые 3 года.
И сейчас развитие отдельных подсистем иногда подвигает на пересмотр базовых основ...
T>И вообще желание копипастнуть не всегда есть зло. Есть куча моментов когда в начале все похоже и решается копипастом а потом допиливается и просто удобнее с чего то написать.
Именно! После 4 подряд копипасты в одной подсистеме он взял себя в руки и переписал подсистему нафиг...
После чего и сформулировал...
T>Зло копипасты максимум в генерации ошибок, не преувеличивайте.
1. Разбухание кода.
2. Тиражирование ошибок, не выявленных в первоначальной копии.

Здравствуйте, LaptevVV, Вы писали:

LVV>Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить.

Можно ли использовать коэффициент сжатия словарными алгоритмами как метрику для пересмотра архитектуры?
Походит ли "антиплагиат" как метрика пересмотра архитектуры?

LVV>>Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить.

_>Можно ли использовать коэффициент сжатия словарными алгоритмами как метрику для пересмотра архитектуры?
_>Походит ли "антиплагиат" как метрика пересмотра архитектуры?
Мне сложно понять ход ваших мыслей. Поясните, пожалуйста.

LVV>Вопрос: когда, в какой момент?
LVV>Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить.
LVV>А у народа с этим как дело обстоит?

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

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

Здравствуйте, LaptevVV, Вы писали:

LVV>То есть, рефакторить архитектуру...
LVV>Именно так он и говорит.

Вот словосочетание понятное, но ИМХО не правильное. Если понимать архитектуру как набор компонент и контрактов взаимодействия то рефакторинг по определению не может применяться к слову архитектура.
А если проект маленький и компоненты можно только из пальца высосать, чтобы почесать ЧСВ, то и понятие архитектура к нему не сильно применима.

Рефакторить можно компоненту, сохраняя ее контракт. Можно класс, или набор классов.

Но это все буквоедство, в принципе.

Здравствуйте, LaptevVV, Вы писали:

LVV>А у народа с этим как дело обстоит?

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

Здравствуйте, LaptevVV, Вы писали:

LVV>Один мой студент-выпускник-аспирант недавно сформулировал.
LVV>Архитектура исследовательских проектов редко бывает удачной с первого раза.
LVV>Обычно приходится по мере развития проекта пересматривать.
LVV>Вопрос: когда, в какой момент?
LVV>Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить.
LVV>А у народа с этим как дело обстоит?

Копипаста на исследовательском этапе — это даже гут. Чем "тоньше" архитектура, чем меньше зависимостей, тем удобнее развивать отдельно взятую сущность/область/тему в проекте. Идеально — её нет вообще (архитектуры), бо практически все алгоритмы можно разрабатывать и анализировать вообще без каких-либо архитектур.

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

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

Собсно, вся "архитектура" из хелперов может и состоять, тогда "архитектура" будет представлять из себя некий АПИ для соединения "хелперов" м/у собой. Например, в случае языка С++ — архитектура может представлять из себя вербальный набор требований, как набор требований к произвольным итераторам для алгоритмов STL.

T>>У меня есть сомнения в том что студенты что то в этом понимают, все таки эта часть программирования требует намного больше опыта, которого у них нет.
LVV>Опыт у этого конкретно товарища как раз есть.
LVV>ШЕСТЬ лет работы над одной системой.
ОДНОЙ, ИССЛЕДОВАТЕЛЬСКОЙ.
LVV>6 раз переделывалась именно архитектура — в первые 3 года.
Типа круто?
LVV>И сейчас развитие отдельных подсистем иногда подвигает на пересмотр базовых основ...
Т.е. изначально полный угар.
T>>И вообще желание копипастнуть не всегда есть зло. Есть куча моментов когда в начале все похоже и решается копипастом а потом допиливается и просто удобнее с чего то написать.
LVV>Именно! После 4 подряд копипасты в одной подсистеме он взял себя в руки и переписал подсистему нафиг...
Браво, достиг уровня миддла.
LVV>После чего и сформулировал...
T>>Зло копипасты максимум в генерации ошибок, не преувеличивайте.
LVV>1. Разбухание кода.
сомнительно, что переписанное будет меньше.
LVV>2. Тиражирование ошибок, не выявленных в первоначальной копии.
уже было озвучено

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

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

LVV>>6 раз переделывалась именно архитектура — в первые 3 года.
DA>Типа круто?

Типа такое запросто может быть по объективным причинам.

LVV>>И сейчас развитие отдельных подсистем иногда подвигает на пересмотр базовых основ...
DA>Т.е. изначально полный угар.

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

T>>>Зло копипасты максимум в генерации ошибок, не преувеличивайте.
LVV>>1. Разбухание кода.
LVV>>2. Тиражирование ошибок, не выявленных в первоначальной копии.
2. Скорее, тиражирование ошибок, уже выявленных и исправленных в первоначальной копии.

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

Здравствуйте, vdimas, Вы писали:

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

В принципе со всем согласен, но можно добавить, что архитектуру рождает не только лишь количество хелперов и их сложность, но и другие факторы. Например:

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

2. Часто набор абстрактных хелперов начинает банально тормозить. Кроме обычной низкоуровневой оптимизации кода внутри хелперов, они могут:
— либо объединяться в единую сущность, в которой можно переиспользовать результаты вычислений и исключить копирование памяти — зачаток архитертуры в виде класса;
— либо из них выделяется новый хелпер с общими вычислениями/хранением результатов — зачаток архитектуры в виде общего API.

3. Алгоритмы надо тестировать, лучше раньше, чем позже.

Здравствуйте, LaptevVV, Вы писали:

LVV>Архитектура исследовательских проектов редко бывает удачной с первого раза.

Архитектура любых проектов редко бывает удачной с первого раза.

LVV>Обычно приходится по мере развития проекта пересматривать.
LVV>Вопрос: когда, в какой момент?

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

P.S. По поводу копипасты практически слово в слово подобное здесь лет 10-12 назад писал IT. В принципе мысль верная, но слишком уж реальность упрощает.