Здравствуйте, LaptevVV, Вы писали:
LVV>Обычно приходится по мере развития проекта пересматривать. LVV>Вопрос: когда, в какой момент?
Обычно, "когда на эту активность удалось выбить время". Потому как в промышленной разработке понимание того, что с кодовой базой гора проблем придет куда раньше, чем возможность действительно что-то изменить
LVV>Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить. LVV>А у народа с этим как дело обстоит?
Но вообще студент не прав, либо путает небольшой рефакторинг с пересмотром архитектуры. Если возникло желание что-то скопиастить, то в большенство случаев это означает что появилась потребность в библиотеке "common" или чем-то типа того. Если же говорить о пересмотре архитектуры, то это куда больший пласт работ, который подразумевает довольно низкоуровневые и кардинальные изменения в проекте. Это могут быть изменения протоколов или базовых библиотек, выделение дополнительных слоев или независимых модулей и т.п.
Здравствуйте, LaptevVV, Вы писали:
LVV>Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить. LVV>А у народа с этим как дело обстоит?
Это скорее рефакторинг. Изменение архитектуры — это что-то более глобальное.
LVV>А у народа с этим как дело обстоит?
К копи-пасте отношусь просто — если код объёмом до одного класса/файла то один раз не копи-паста, один раз это даже хорошо — это же повторное использование кода , вот если возникло желание сделать в проекте ещё и 3-ю версию копи-пасты — значит пора рефакторить, чтоб больше такой фигни никогда не было. Одно исключение — если понадобилось вносить в две версии синхронные изменения — пора выделять общее и выносить разное не дожидаясь рождения 3-ей.
К архитектуре и её изменениям тоже отношусь просто — главное чтоб не мешала. Но если на борьбу с архитектурой ушло времени больше чем на собственно решение задачи — пора рефакторить.
LVV>Вопрос: когда, в какой момент? LVV>Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить. LVV>А у народа с этим как дело обстоит?
это только одна грань из многих.
Есть ситуации, когда дублирование кода лучше оставить, потому что попытки его исправить могут увеличивать связность и вводить плохо определенные абстракции и слои.
Код может быть замечательным с точки зрения отсутствия дублирования, но он может быть жутко связным.
Твой критерий ничего не говорит о таком коде.
Здравствуйте, LaptevVV, Вы писали:
LVV>Один мой студент-выпускник-аспирант недавно сформулировал. LVV>Архитектура исследовательских проектов редко бывает удачной с первого раза. LVV>Обычно приходится по мере развития проекта пересматривать. LVV>Вопрос: когда, в какой момент? LVV>Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить. LVV>А у народа с этим как дело обстоит?
Копипаста на исследовательском этапе — это даже гут. Чем "тоньше" архитектура, чем меньше зависимостей, тем удобнее развивать отдельно взятую сущность/область/тему в проекте. Идеально — её нет вообще (архитектуры), бо практически все алгоритмы можно разрабатывать и анализировать вообще без каких-либо архитектур.
Архитектуру лучше громоздить когда участники модели и правила их взаимодействия оформятся естественным образом по мере накопления разработчиками понимания принципов работы собственного детища.
В этом смысле архитектура часто может начинаться от "хелперов", которые обычно могут пережить мильон "переделок архитектуры" без заметного изменения самих "хелперов", бо везде полезны.
Собсно, вся "архитектура" из хелперов может и состоять, тогда "архитектура" будет представлять из себя некий АПИ для соединения "хелперов" м/у собой. Например, в случае языка С++ — архитектура может представлять из себя вербальный набор требований, как набор требований к произвольным итераторам для алгоритмов STL.
Здравствуйте, LaptevVV, Вы писали:
LVV>А у народа с этим как дело обстоит?
я для себя такой критерий хорошей архитектуры вывел: если архитектура хорошая, то сделать какую-нить новую несложную фичу можно очень быстро, не напрягаясь и не извращаясь. а вот если добавление даже тривиальной фичи требует плясок с бубнами — пора менять в консерватории
Здравствуйте, LaptevVV, Вы писали:
LVV>Один мой студент-выпускник-аспирант недавно сформулировал. LVV>Архитектура исследовательских проектов редко бывает удачной с первого раза. LVV>Обычно приходится по мере развития проекта пересматривать. LVV>Вопрос: когда, в какой момент? LVV>Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить. LVV>А у народа с этим как дело обстоит?
Глобальное исследование больших библиотек алгоритмов с попыткой их объединения сильно меняет представление об архитектурах. Если возникает потребность использовать и объединить десятки тысяч методов с невозможностью копипаста по причине связности кода. И я подчёркиваю, речь именно об исследованиях, вряд ли такое могут позволить себе люди занимающиеся коммерческой разработкой у которых время как известно сильно ограничено, отсюда и иной стиль мышления.
Ну, а студент молодец, наконец-то обнаружил, что куски кода не желательно просто копипастить и допиливать.
Re[3]: Эмпирическое правило пересмотра архитектуры
У меня есть сомнения в том что студенты что то в этом понимают, все таки эта часть программирования требует намного больше опыта, которого у них нет.
И вообще желание копипастнуть не всегда есть зло. Есть куча моментов когда в начале все похоже и решается копипастом а потом допиливается и просто удобнее с чего то написать.
Зло копипасты максимум в генерации ошибок, не преувеличивайте.
Самый просто пример: когда вы начинаете реализовывать большой интерфейс(а у вас есть уже 100500 его реализаций для парсинга файлов например) хотите вы этого или нет то часто работа начинается с копипасты а потом переименовыванием и переделкой некоторых вещей. И вынос этого дохлого небольшого куска с виду общего кода в промежуточный класс приведет только к большим неудобствам.
Здравствуйте, LaptevVV, Вы писали:
LVV>Архитектура исследовательских проектов редко бывает удачной с первого раза.
Архитектура любых проектов редко бывает удачной с первого раза.
LVV>Обычно приходится по мере развития проекта пересматривать. LVV>Вопрос: когда, в какой момент?
Непрерывно. Если же речь о серьезном перетрясании, то в тот момент, когда стоимость изменений ощутимо возрастает.
P.S. По поводу копипасты практически слово в слово подобное здесь лет 10-12 назад писал IT. В принципе мысль верная, но слишком уж реальность упрощает.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Один мой студент-выпускник-аспирант недавно сформулировал.
Архитектура исследовательских проектов редко бывает удачной с первого раза.
Обычно приходится по мере развития проекта пересматривать.
Вопрос: когда, в какой момент?
Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить.
А у народа с этим как дело обстоит?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Эмпирическое правило пересмотра архитектуры
LVV>>Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить. LVV>>А у народа с этим как дело обстоит?
A>Это скорее рефакторинг. Изменение архитектуры — это что-то более глобальное.
Не. Вот именно пересмотр всей базовой части.
Если рефакторинг, то большой, затрагивающий много классов и их отношения.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Эмпирическое правило пересмотра архитектуры
Здравствуйте, hi_octane, Вы писали:
LVV>>А у народа с этим как дело обстоит? _>К копи-пасте отношусь просто — если код объёмом до одного класса/файла то один раз не копи-паста, один раз это даже хорошо — это же повторное использование кода , вот если возникло желание сделать в проекте ещё и 3-ю версию копи-пасты — значит пора рефакторить, чтоб больше такой фигни никогда не было. Одно исключение — если понадобилось вносить в две версии синхронные изменения — пора выделять общее и выносить разное не дожидаясь рождения 3-ей.
Абсолютно теми же словами мой студент-аспирант об этом рассказывает.
Вот просто как будто по одной бумажке читаете...
_>К архитектуре и её изменениям тоже отношусь просто — главное чтоб не мешала. Но если на борьбу с архитектурой ушло времени больше чем на собственно решение задачи — пора рефакторить.
То есть, рефакторить архитектуру...
Именно так он и говорит.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Эмпирическое правило пересмотра архитектуры
Здравствуйте, Trrrrr, Вы писали:
T>У меня есть сомнения в том что студенты что то в этом понимают, все таки эта часть программирования требует намного больше опыта, которого у них нет.
Опыт у этого конкретно товарища как раз есть.
ШЕСТЬ лет работы над одной системой.
6 раз переделывалась именно архитектура — в первые 3 года.
И сейчас развитие отдельных подсистем иногда подвигает на пересмотр базовых основ... T>И вообще желание копипастнуть не всегда есть зло. Есть куча моментов когда в начале все похоже и решается копипастом а потом допиливается и просто удобнее с чего то написать.
Именно! После 4 подряд копипасты в одной подсистеме он взял себя в руки и переписал подсистему нафиг...
После чего и сформулировал... T>Зло копипасты максимум в генерации ошибок, не преувеличивайте.
1. Разбухание кода.
2. Тиражирование ошибок, не выявленных в первоначальной копии.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить.
Можно ли использовать коэффициент сжатия словарными алгоритмами как метрику для пересмотра архитектуры?
Походит ли "антиплагиат" как метрика пересмотра архитектуры?
Re[2]: Эмпирическое правило пересмотра архитектуры
LVV>>Он это сформулировал так: в тот момент, когда ручки потянулись скопипастить кусок кода — ибо он почти решает возникшую проблему и его просто надо немного допилить.
_>Можно ли использовать коэффициент сжатия словарными алгоритмами как метрику для пересмотра архитектуры? _>Походит ли "антиплагиат" как метрика пересмотра архитектуры?
Мне сложно понять ход ваших мыслей. Поясните, пожалуйста.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Эмпирическое правило пересмотра архитектуры
Здравствуйте, LaptevVV, Вы писали:
LVV>То есть, рефакторить архитектуру... LVV>Именно так он и говорит.
Вот словосочетание понятное, но ИМХО не правильное. Если понимать архитектуру как набор компонент и контрактов взаимодействия то рефакторинг по определению не может применяться к слову архитектура.
А если проект маленький и компоненты можно только из пальца высосать, чтобы почесать ЧСВ, то и понятие архитектура к нему не сильно применима.
Рефакторить можно компоненту, сохраняя ее контракт. Можно класс, или набор классов.
Но это все буквоедство, в принципе.
Re[5]: Эмпирическое правило пересмотра архитектуры
T>>У меня есть сомнения в том что студенты что то в этом понимают, все таки эта часть программирования требует намного больше опыта, которого у них нет. LVV>Опыт у этого конкретно товарища как раз есть. LVV>ШЕСТЬ лет работы над одной системой.
ОДНОЙ, ИССЛЕДОВАТЕЛЬСКОЙ. LVV>6 раз переделывалась именно архитектура — в первые 3 года.
Типа круто? LVV>И сейчас развитие отдельных подсистем иногда подвигает на пересмотр базовых основ...
Т.е. изначально полный угар. T>>И вообще желание копипастнуть не всегда есть зло. Есть куча моментов когда в начале все похоже и решается копипастом а потом допиливается и просто удобнее с чего то написать. LVV>Именно! После 4 подряд копипасты в одной подсистеме он взял себя в руки и переписал подсистему нафиг...
Браво, достиг уровня миддла. LVV>После чего и сформулировал... T>>Зло копипасты максимум в генерации ошибок, не преувеличивайте. LVV>1. Разбухание кода.
сомнительно, что переписанное будет меньше. LVV>2. Тиражирование ошибок, не выявленных в первоначальной копии.
уже было озвучено
Re[6]: Эмпирическое правило пересмотра архитектуры
Я второй год в качестве хобби делаю проект игровой направленности. Задумка была такова, что никаких аналогов я не видел даже близко. Не на кого было ориентироваться, негде было поучиться. Я даже понятия не имел, как будет выглядеть конечный результат трудов, да и сейчас ещё не до конца понимаю.
Эдакий домашний исследовательский проект, в котором по мере развития постоянно сплывают всевозможные ограничения, которые было трудно предвидеть заранее и которые приходится обходить. Если бы был какой-то образец для подражания, делать его клон было бы в 20 раз проще.
LVV>>6 раз переделывалась именно архитектура — в первые 3 года. DA>Типа круто?
Типа такое запросто может быть по объективным причинам.
LVV>>И сейчас развитие отдельных подсистем иногда подвигает на пересмотр базовых основ... DA>Т.е. изначально полный угар.
Это как если бы заказчик менял ТЗ раз в месяц, только заказчик в этом случае ты сам. И перестать менять ТЗ ты не можешь, потому что старое в связи с вновь открывшимися обстоятельствами перестаёт иметь смысл и тогда проект можно сворачивать.
T>>>Зло копипасты максимум в генерации ошибок, не преувеличивайте. LVV>>1. Разбухание кода. LVV>>2. Тиражирование ошибок, не выявленных в первоначальной копии.
2. Скорее, тиражирование ошибок, уже выявленных и исправленных в первоначальной копии.
3. У меня копипаста периодически ещё приводила к ситуациям, когда у тебя есть несколько вариантов примерно одинакового кода, который решает примерно одинаковую задачу, но немного по-разному с немного разными результатами. И через некоторое время я уже переставал понимать какой именно вариант мне нужен в конкретном случае.
Здравствуйте, vdimas, Вы писали:
V>Архитектуру лучше громоздить когда участники модели и правила их взаимодействия оформятся естественным образом по мере накопления разработчиками понимания принципов работы собственного детища.
В принципе со всем согласен, но можно добавить, что архитектуру рождает не только лишь количество хелперов и их сложность, но и другие факторы. Например:
1. Скорее рано, чем поздно понадобятся дополнительные средства внутренней отладки типа логов и/или визуализации промежуточных результатов. Тогда понадобится некая гибкая система, которую удобно включать/выключать в любых местах. Появление такой системы внутренней отладки само по себе призывает к созданию зачатков архитектуры в виде унификации API.
2. Часто набор абстрактных хелперов начинает банально тормозить. Кроме обычной низкоуровневой оптимизации кода внутри хелперов, они могут:
— либо объединяться в единую сущность, в которой можно переиспользовать результаты вычислений и исключить копирование памяти — зачаток архитертуры в виде класса;
— либо из них выделяется новый хелпер с общими вычислениями/хранением результатов — зачаток архитектуры в виде общего API.
3. Алгоритмы надо тестировать, лучше раньше, чем позже.