OberonCore
https://forum.oberoncore.ru/

Рефакторинг: есть ли ему место в разработке систем?
https://forum.oberoncore.ru/viewtopic.php?f=86&t=3573		 Страница 1 из 4
Автор:  igor [ Среда, 21 Сентябрь, 2011 10:40 ]
Заголовок сообщения:  Рефакторинг: есть ли ему место в разработке систем?
Тема отделена отсюда: viewtopic.php?f=86&t=3570

alexus писал(а):
Текстом или образом... не принципиально, принципиальны внутренние связи, чтобы изменения в одной части/на одной стадии адекватно представлялись в других частях/на других стадиях и... в документации, конечно. Не менее важно поддерживать вариантность (управление изменениями).
При этом рефакторинг, как явление, необходимо предать массовому осуждению... жестче, чем пресловутый GoTo.
Не могу согласиться с последним утверждением, да ещё высказанным в такой категоричной форме.
В процессе разработки, связи внутри системы могут изменяться. Причём решение о необходимости таких изменений принимаются на основании предыдущих результатов. То есть в самом начале работы над проектом, когда эти результаты ещё не были получены, не могло быть и окончательных решений относительно связей в системе. Таким образом, рефакторинг становится неизбежным. Не нужен он только в случае очень простых систем, когда для установления связей никакие предварительные результаты не нужны.
Автор:  alexus [ Среда, 21 Сентябрь, 2011 12:18 ]
Заголовок сообщения:  Re: Оберон, ДРАКОН и проектирование систем
igor писал(а):
alexus писал(а):
Текстом или образом... не принципиально, принципиальны внутренние связи, чтобы изменения в одной части/на одной стадии адекватно представлялись в других частях/на других стадиях и... в документации, конечно. Не менее важно поддерживать вариантность (управление изменениями).
При этом рефакторинг, как явление, необходимо предать массовому осуждению... жестче, чем пресловутый GoTo.
Не могу согласиться с последним утверждением, да ещё высказанным в такой категоричной форме.
Не соглашайтесь... Ваше право.
igor писал(а):
В процессе разработки, связи внутри системы могут изменяться.
Строго говоря... обязаны изменяться, потому их и называют... "слабыми". Только к рефакторингу такие изменения не приводят... если мы говорим о системе...
igor писал(а):
Причём решение о необходимости таких изменений принимаются на основании предыдущих результатов. То есть в самом начале работы над проектом, когда эти результаты ещё не были получены, не могло быть и окончательных решений относительно связей в системе. Таким образом, рефакторинг становится неизбежным. Не нужен он только в случае очень простых систем, когда для установления связей никакие предварительные результаты не нужны.
Связи устанавливаются и меняются... Меняется состав элементов... и всё это делается без рефакторинга. Рефакторинг нужен тогда, когда вместо системы создают большую программу и... сильно гордятся этим. :)
Вот для примера в одной из соседних веток обсуждений приводили фрагменты программы по начислению зарплаты... Очень показательно... и без рефакторинга (раз в полугодие, как минимум...) не живёт. А мыслили бы системно... меньше суеты... больше пользы и удовольствий. :)
(Но я понимаю, что перестраивать сознание... тяжкий труд... И не настаиваю.)
Автор:  igor [ Среда, 21 Сентябрь, 2011 14:01 ]
Заголовок сообщения:  Re: Оберон, ДРАКОН и проектирование систем
alexus писал(а):
igor писал(а):
В процессе разработки, связи внутри системы могут изменяться.
Строго говоря... обязаны изменяться, потому их и называют... "слабыми". Только к рефакторингу такие изменения не приводят... если мы говорим о системе...
Правильно ли я понял, что Ваш ( :) ) рефакторинг, в отличие от моего рефакторинга, не приводит к изменению внутренней структуры программы?
Автор:  alexus [ Среда, 21 Сентябрь, 2011 15:01 ]
Заголовок сообщения:  Re: Оберон, ДРАКОН и проектирование систем
igor писал(а):
alexus писал(а):
igor писал(а):
В процессе разработки, связи внутри системы могут изменяться.
Строго говоря... обязаны изменяться, потому их и называют... "слабыми". Только к рефакторингу такие изменения не приводят... если мы говорим о системе...
Правильно ли я понял, что Ваш ( :) ) рефакторинг, в отличие от моего рефакторинга, не приводит к изменению внутренней структуры программы?
Моего рефакторинга просто нет (реально не существует). Поэтому остаётся только Ваш, он же... общепринятый, КОТОРЫЙ ПРИВОДИТ К ИЗМЕНЕНИЮ СТРУКТУРЫ И ЛОГИКИ ПРОГРАММЫ.
Автор:  igor [ Среда, 21 Сентябрь, 2011 16:54 ]
Заголовок сообщения:  Re: Оберон, ДРАКОН и проектирование систем
alexus писал(а):
Моего рефакторинга просто нет (реально не существует). Поэтому остаётся только Ваш, он же... общепринятый, КОТОРЫЙ ПРИВОДИТ К ИЗМЕНЕНИЮ СТРУКТУРЫ И ЛОГИКИ ПРОГРАММЫ.
Занятный разговор получается :D
Раз реально существует только тот рефакторинг, который приводит к изменению структуры и логики программы, значит этот рефакторинг необходим, потому что в ходе работы над проектом приходится изменять и структуру и логику программы.
Непонятно тогда какой-такой рефакторинг Вы предлагали "предать массовому осуждению"? Если Вы имели ввиду свой рефакторинг, так его "реально не существует" и осуждать нечего. :D
Автор:  alexus [ Среда, 21 Сентябрь, 2011 17:29 ]
Заголовок сообщения:  Re: Оберон, ДРАКОН и проектирование систем
igor писал(а):
alexus писал(а):
Моего рефакторинга просто нет (реально не существует). Поэтому остаётся только Ваш, он же... общепринятый, КОТОРЫЙ ПРИВОДИТ К ИЗМЕНЕНИЮ СТРУКТУРЫ И ЛОГИКИ ПРОГРАММЫ.
Занятный разговор получается :D
Если читать через строчку, то... ещё занятнее получится... а через букву...
igor писал(а):
Раз реально существует только тот рефакторинг, который приводит к изменению структуры и логики программы, значит этот рефакторинг необходим, потому что в ходе работы над проектом приходится изменять и структуру и логику программы.
Непонятно тогда какой-такой рефакторинг Вы предлагали "предать массовому осуждению"? Если Вы имели ввиду свой рефакторинг, так его "реально не существует" и осуждать нечего. :D
Повторю ещё раз, то что было сказано несколькими сообщениями ранее:
Цитата:
Рефакторинг нужен тогда, когда вместо системы создают большую программу и... сильно гордятся этим.
Другими словами, рефакторинг является следствием ошибок моделирования и проектирования... ширмой, за которой прячут эти ошибки. И поэтому должен подвергаться осуждению.
Автор:  Иван Кузьмицкий [ Среда, 21 Сентябрь, 2011 20:48 ]
Заголовок сообщения:  Re: Оберон, ДРАКОН и проектирование систем
alexus писал(а):
Другими словами, рефакторинг является следствием ошибок моделирования и проектирования... ширмой, за которой за которой прячут эти ошибки. И поэтому должен подвергаться осуждению.


Разрешите подписаться.
Автор:  Доровских Александр [ Среда, 21 Сентябрь, 2011 21:58 ]
Заголовок сообщения:  Re: Оберон и проектирование систем
А если первоначальные условия меняются? Как с зарплатой. Каждый год законодатели что-то новое придумывают. И предугадать их телодвижения невозможно.
Автор:  Valery Solovey [ Среда, 21 Сентябрь, 2011 23:11 ]
Заголовок сообщения:  Re: Оберон и проектирование систем
Пишется один или несколько новых модулей. Они подключаются. Старые модули отключаются. Всё это время система как работала, так и продолжает работать. Остановок в работе не было. Повторного тестирование ранее написанного кода тоже не было.
Автор:  Info21 [ Четверг, 22 Сентябрь, 2011 02:03 ]
Заголовок сообщения:  Re: Оберон, ДРАКОН и проектирование систем
Иван Кузьмицкий писал(а):
alexus писал(а):
рефакторинг является следствием ошибок моделирования и проектирования... ширмой, за которой за которой прячут эти ошибки. И поэтому должен подвергаться осуждению.
Разрешите подписаться.
Как обычно, в дискуссии момент "каши в голове".

Рефакторинг -- просто инструмент (или инструментальная процедура).
Как-то странно его осуждать.
И странно называть его "ширмой".

Осуждать имеет смысл спешку и, как следствие, недообдуманность (но это бывает обусловлено экстерналиями). Или недообученность.
Но осуждать бедный рефакторинг?
Это как осуждать кнопку Backspace.
Автор:  alexus [ Четверг, 22 Сентябрь, 2011 05:04 ]
Заголовок сообщения:  Re: Оберон и проектирование систем
Доровских Александр писал(а):
А если первоначальные условия меняются? Как с зарплатой. Каждый год законодатели что-то новое придумывают. И предугадать их телодвижения невозможно.
Конечно, невозможно и... ненужно. Из попыток алгоритмизовать то, что неалгоритмизируемо (по условию задачи)... ничего хорошего получиться не может. Может быть не надо алгоритмизировать?.. Может быть надо найти другой (неалгоритмический) способ решения своей задачи, основанный на принципиально иной модели?.. Способ, дающий несравнимо более качественные результаты... (добавил бы... и количественные результаты тоже, но не буду... пока).

PS. Повторю своё предложение: если желаете, могу прокомментировать сказанное ранее.
Автор:  alexus [ Четверг, 22 Сентябрь, 2011 05:09 ]
Заголовок сообщения:  Re: Оберон и проектирование систем
Valery Solovey писал(а):
Пишется один или несколько новых модулей. Они подключаются. Старые модули отключаются. Всё это время система как работала, так и продолжает работать. Остановок в работе не было. Повторного тестирование ранее написанного кода тоже не было.
Фактически, это всё тот же рефакторинг, поскольку
1. Необходимо поднять исходники;
2. Найти проблемное место;
3. Предложить решения;
4. Выбрать наиболее оптимальное;
5. Реализовать, протестировать и внедрить новую версию;
6. Тщательно документировать сделанные изменения.
И при каждом новом изменении... повторить шаги заново... Это не решение проблемы... это её усугубление, поскольку со временем изменений станет так много, что разобраться в документации будет нереально. Собственно, об этом писал ещё Ф. Брукс в своей книге "Мифический человеко-месяц...".
Автор:  Валерий Лаптев [ Четверг, 22 Сентябрь, 2011 06:21 ]
Заголовок сообщения:  Re: Оберон, ДРАКОН и проектирование систем
alexus писал(а):
igor писал(а):
Рефакторинг нужен тогда, когда вместо системы создают большую программу и... сильно гордятся этим.Другими словами, рефакторинг является следствием ошибок моделирования и проектирования... ширмой, за которой прячут эти ошибки. И поэтому должен подвергаться осуждению.

C этим не соглашусь.
Всякая система (и даже программа) проходит свой путь развития. Через это нельзя перешагнуть - этот путь можно только пройти. По мере развития рефакторинг и происходит.
Автор:  Владислав Жаринов [ Четверг, 22 Сентябрь, 2011 06:35 ]
Заголовок сообщения:  Re: Оберон, ДРАКОН и проектирование систем
В итоге пост оказался целиком офтопик :) viewtopic.php?f=86&t=3606&p=66314#p66314; перенесён [url]сюда[/url].
Автор:  Peter Almazov [ Четверг, 22 Сентябрь, 2011 07:09 ]
Заголовок сообщения:  Re: Оберон и проектирование систем
alexus писал(а):
PS. Повторю своё предложение: если желаете, могу прокомментировать сказанное ранее.
Да желаем, ясное дело. Ждем с нетерпением.
Автор:  alexus [ Четверг, 22 Сентябрь, 2011 07:18 ]
Заголовок сообщения:  Re: Оберон, ДРАКОН и проектирование систем
Валерий Лаптев писал(а):
alexus писал(а):
igor писал(а):
Рефакторинг нужен тогда, когда вместо системы создают большую программу и... сильно гордятся этим.Другими словами, рефакторинг является следствием ошибок моделирования и проектирования... ширмой, за которой прячут эти ошибки. И поэтому должен подвергаться осуждению.
C этим не соглашусь.
Всякая система (и даже программа) проходит свой путь развития. Через это нельзя перешагнуть - этот путь можно только пройти. По мере развития рефакторинг и происходит.
Развитие бывает разным... Можно всё переделывать, можно развивать добавляя новое. Это разные пути.
Автор:  Иван Кузьмицкий [ Четверг, 22 Сентябрь, 2011 07:28 ]
Заголовок сообщения:  Re: Оберон, ДРАКОН и проектирование систем
Info21 писал(а):
Иван Кузьмицкий писал(а):
alexus писал(а):
рефакторинг является следствием ошибок моделирования и проектирования... ширмой, за которой за которой прячут эти ошибки. И поэтому должен подвергаться осуждению.
Разрешите подписаться.
Как обычно, в дискуссии момент "каши в голове".

Рефакторинг -- просто инструмент (или инструментальная процедура).
Как-то странно его осуждать.
И странно называть его "ширмой".

Осуждать имеет смысл спешку и, как следствие, недообдуманность (но это бывает обусловлено экстерналиями). Или недообученность.
Но осуждать бедный рефакторинг?
Это как осуждать кнопку Backspace.


Я понимаю осуждение рефакторинга как средства, стоящего наравне с проектированием и моделированием. Вот, мы позавчера начали перекраивать стартовые механизмы системы. Да, недопроектирование. Да, недодуманность. Да, были причины сделать так, а не лучше. Но всё же - время, потраченное на рабочие исходники можно рассматривать как инвестиции, а перекройку как упущенное время. Поэтому рефакторинг надо рассматривать как крайнее средство (когда наука и медицина бессильны), а не рутину, или там, пункт меню вижуал студии.
Автор:  Владислав Жаринов [ Четверг, 22 Сентябрь, 2011 07:51 ]
Заголовок сообщения:  Re: Оберон и проектирование систем
С чисто экономических позиций - если Вы как специалист в работе с исходниками оцениваете затраты времени/сил/средств на сторонних "затратчиков" в случае перекройки как меньшие, чем в случае написания "додуманного" и "допроектированного" - то да, можно трактовать как "инвестиции". Это на "коротких временах" - в данном случае для периода поднятия единичного нового проекта. А на "длинных" - м.б. оказаться лучше "инвестировать" в архитектуру правильную, по-Вашему как специалиста уже в целом в своей отрасли... так ведь?..
Автор:  alexus [ Четверг, 22 Сентябрь, 2011 08:00 ]
Заголовок сообщения:  Re: Оберон и проектирование систем
Peter Almazov писал(а):
alexus писал(а):
PS. Повторю своё предложение: если желаете, могу прокомментировать сказанное ранее.
Да желаем, ясное дело. Ждем с нетерпением.

Хорошо, попробую...
Когда-то мне тоже приходилось заниматься написанием зарплатной программы. Предприятие - самый большой (по обороту) гастроном (супермаркет) того времени в нашем городе, примерно тогда он начал превращаться в сеть магазинов, разбросанных, как по городу, так и области. Более сотни различных видов оплаты труда (оклады, повременные, сдельные, сдельно/повременно-премиальные, % с продаж, контрактные ("черные", "серые", в крапинку...). В общем, те кто прошёл через это, понимает о чём идёт речь. Времена были смутные и виды начислений, алгоритмы, структура исходных данных менялись очень часто, фактически, ежемесячно вносились те или иные изменения. Плюс к этому нервы... на то, чтобы успокоить и тех, кто платит, и тех, кто получает. А чтобы не "порвали на куски", каждый шаг, каждое совещание, каждое предложение и каждое решение строго фиксировались, отражались на ТЗ, подписывались и пр. Это отнимало много времени. Таков контекст, и вряд ли он сильно изменился с тех пор (хотя, наверное, есть более спокойные организации и... времена).
Первое, что было сделано, - проект БД, связанной с базой данных "отдела кадров" и "орг. структуры предприятия". Худо-бедно, но учёт рабочего времени был как-то налажен, объёмы продаж по магазинам/отделам тоже в деньгах и количестве (относительно ассортимента) собирались. Но многих данных, необходимых для расчётов, не существовало. Структура данных для разных видов начислений сильно отличается друг от друга и... часто изменяется, как, впрочем, и алгоритмы начислений. Чтобы справиться с этим пришлось хорошо подумать над структурой таблиц БД. Ну, да, ладно... сейчас не об этом.
Программа расчёта была в конечном итоге написана и началась её бесконечная переделка... Вначале это как-то ещё увлекает, но через полгода хочется всё бросить... Как происходил процесс внесения корректив?.. Это важный момент. Руководители служб, отделов, бюро подавали заявки в ОТЗ (отдел труда и заработной платы) с примечаниями. С другой стороны, руководство в лице директоров на совещаниях давали указания ОТЗ, кому и как начислять, перечисляли штрафные санкции и премиальные. Всё это переваривалось ОТЗ, где пытались фонд заработной платы свести с постоянно растущими требованиями. Как правило, результат никого не устраивал, начинался процесс поиска компромиссов, который неизбежно приводил к... корректировке схем начисления для отдельных категорий работников. Было понятно, что процесс корректировок является перманентным и... непредсказуемым. Далее приглашались программисты, перед ними ставилась задача внести требуемые изменения... задним числом... чтобы не позднее, чем за два дня до выплаты зарплаты были сделаны все расчёты и распечатаны все ведомости.
Поэтому наряду с сопровождением программы (это было поставлено на поток...) началось формирование принципиально иного проекта... по личной инициативе, без извещения руководства.
Автор:  Владислав Жаринов [ Четверг, 22 Сентябрь, 2011 08:26 ]
Заголовок сообщения:  Re: Оберон и проектирование систем
Уже интересно... примерно о том же, что у Михайлова... токо он там всё сводит к работе с приложением и с "предметником"... не касаясь метода оптимального развития всей "человеко-машинной" системы... :)

Кстати, свой предыдущий пост дополнил кое-чем... по части вопросов в первую очередь.
Страница 1 из 4 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/