OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Суббота, 14 Декабрь, 2019 03:53

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 65 ]  На страницу 1, 2, 3, 4  След.
Автор Сообщение
СообщениеДобавлено: Среда, 21 Сентябрь, 2011 10:40 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Тема отделена отсюда: viewtopic.php?f=86&t=3570

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 21 Сентябрь, 2011 12:18 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
igor писал(а):
alexus писал(а):
Текстом или образом... не принципиально, принципиальны внутренние связи, чтобы изменения в одной части/на одной стадии адекватно представлялись в других частях/на других стадиях и... в документации, конечно. Не менее важно поддерживать вариантность (управление изменениями).
При этом рефакторинг, как явление, необходимо предать массовому осуждению... жестче, чем пресловутый GoTo.
Не могу согласиться с последним утверждением, да ещё высказанным в такой категоричной форме.
Не соглашайтесь... Ваше право.
igor писал(а):
В процессе разработки, связи внутри системы могут изменяться.
Строго говоря... обязаны изменяться, потому их и называют... "слабыми". Только к рефакторингу такие изменения не приводят... если мы говорим о системе...
igor писал(а):
Причём решение о необходимости таких изменений принимаются на основании предыдущих результатов. То есть в самом начале работы над проектом, когда эти результаты ещё не были получены, не могло быть и окончательных решений относительно связей в системе. Таким образом, рефакторинг становится неизбежным. Не нужен он только в случае очень простых систем, когда для установления связей никакие предварительные результаты не нужны.
Связи устанавливаются и меняются... Меняется состав элементов... и всё это делается без рефакторинга. Рефакторинг нужен тогда, когда вместо системы создают большую программу и... сильно гордятся этим. :)
Вот для примера в одной из соседних веток обсуждений приводили фрагменты программы по начислению зарплаты... Очень показательно... и без рефакторинга (раз в полугодие, как минимум...) не живёт. А мыслили бы системно... меньше суеты... больше пользы и удовольствий. :)
(Но я понимаю, что перестраивать сознание... тяжкий труд... И не настаиваю.)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 21 Сентябрь, 2011 14:01 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
alexus писал(а):
igor писал(а):
В процессе разработки, связи внутри системы могут изменяться.
Строго говоря... обязаны изменяться, потому их и называют... "слабыми". Только к рефакторингу такие изменения не приводят... если мы говорим о системе...
Правильно ли я понял, что Ваш ( :) ) рефакторинг, в отличие от моего рефакторинга, не приводит к изменению внутренней структуры программы?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 21 Сентябрь, 2011 15:01 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
igor писал(а):
alexus писал(а):
igor писал(а):
В процессе разработки, связи внутри системы могут изменяться.
Строго говоря... обязаны изменяться, потому их и называют... "слабыми". Только к рефакторингу такие изменения не приводят... если мы говорим о системе...
Правильно ли я понял, что Ваш ( :) ) рефакторинг, в отличие от моего рефакторинга, не приводит к изменению внутренней структуры программы?
Моего рефакторинга просто нет (реально не существует). Поэтому остаётся только Ваш, он же... общепринятый, КОТОРЫЙ ПРИВОДИТ К ИЗМЕНЕНИЮ СТРУКТУРЫ И ЛОГИКИ ПРОГРАММЫ.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 21 Сентябрь, 2011 16:54 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
alexus писал(а):
Моего рефакторинга просто нет (реально не существует). Поэтому остаётся только Ваш, он же... общепринятый, КОТОРЫЙ ПРИВОДИТ К ИЗМЕНЕНИЮ СТРУКТУРЫ И ЛОГИКИ ПРОГРАММЫ.
Занятный разговор получается :D
Раз реально существует только тот рефакторинг, который приводит к изменению структуры и логики программы, значит этот рефакторинг необходим, потому что в ходе работы над проектом приходится изменять и структуру и логику программы.
Непонятно тогда какой-такой рефакторинг Вы предлагали "предать массовому осуждению"? Если Вы имели ввиду свой рефакторинг, так его "реально не существует" и осуждать нечего. :D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 21 Сентябрь, 2011 17:29 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
igor писал(а):
alexus писал(а):
Моего рефакторинга просто нет (реально не существует). Поэтому остаётся только Ваш, он же... общепринятый, КОТОРЫЙ ПРИВОДИТ К ИЗМЕНЕНИЮ СТРУКТУРЫ И ЛОГИКИ ПРОГРАММЫ.
Занятный разговор получается :D
Если читать через строчку, то... ещё занятнее получится... а через букву...
igor писал(а):
Раз реально существует только тот рефакторинг, который приводит к изменению структуры и логики программы, значит этот рефакторинг необходим, потому что в ходе работы над проектом приходится изменять и структуру и логику программы.
Непонятно тогда какой-такой рефакторинг Вы предлагали "предать массовому осуждению"? Если Вы имели ввиду свой рефакторинг, так его "реально не существует" и осуждать нечего. :D
Повторю ещё раз, то что было сказано несколькими сообщениями ранее:
Цитата:
Рефакторинг нужен тогда, когда вместо системы создают большую программу и... сильно гордятся этим.
Другими словами, рефакторинг является следствием ошибок моделирования и проектирования... ширмой, за которой прячут эти ошибки. И поэтому должен подвергаться осуждению.


Последний раз редактировалось alexus Четверг, 22 Сентябрь, 2011 04:55, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 21 Сентябрь, 2011 20:48 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2934
Откуда: г. Ярославль
alexus писал(а):
Другими словами, рефакторинг является следствием ошибок моделирования и проектирования... ширмой, за которой за которой прячут эти ошибки. И поэтому должен подвергаться осуждению.


Разрешите подписаться.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон и проектирование систем
СообщениеДобавлено: Среда, 21 Сентябрь, 2011 21:58 

Зарегистрирован: Пятница, 16 Октябрь, 2009 20:04
Сообщения: 68
А если первоначальные условия меняются? Как с зарплатой. Каждый год законодатели что-то новое придумывают. И предугадать их телодвижения невозможно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон и проектирование систем
СообщениеДобавлено: Среда, 21 Сентябрь, 2011 23:11 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Пишется один или несколько новых модулей. Они подключаются. Старые модули отключаются. Всё это время система как работала, так и продолжает работать. Остановок в работе не было. Повторного тестирование ранее написанного кода тоже не было.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 02:03 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8215
Откуда: Троицк, Москва
Иван Кузьмицкий писал(а):
alexus писал(а):
рефакторинг является следствием ошибок моделирования и проектирования... ширмой, за которой за которой прячут эти ошибки. И поэтому должен подвергаться осуждению.
Разрешите подписаться.
Как обычно, в дискуссии момент "каши в голове".

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон и проектирование систем
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 05:04 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Доровских Александр писал(а):
А если первоначальные условия меняются? Как с зарплатой. Каждый год законодатели что-то новое придумывают. И предугадать их телодвижения невозможно.
Конечно, невозможно и... ненужно. Из попыток алгоритмизовать то, что неалгоритмизируемо (по условию задачи)... ничего хорошего получиться не может. Может быть не надо алгоритмизировать?.. Может быть надо найти другой (неалгоритмический) способ решения своей задачи, основанный на принципиально иной модели?.. Способ, дающий несравнимо более качественные результаты... (добавил бы... и количественные результаты тоже, но не буду... пока).

PS. Повторю своё предложение: если желаете, могу прокомментировать сказанное ранее.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон и проектирование систем
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 05:09 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Valery Solovey писал(а):
Пишется один или несколько новых модулей. Они подключаются. Старые модули отключаются. Всё это время система как работала, так и продолжает работать. Остановок в работе не было. Повторного тестирование ранее написанного кода тоже не было.
Фактически, это всё тот же рефакторинг, поскольку
1. Необходимо поднять исходники;
2. Найти проблемное место;
3. Предложить решения;
4. Выбрать наиболее оптимальное;
5. Реализовать, протестировать и внедрить новую версию;
6. Тщательно документировать сделанные изменения.
И при каждом новом изменении... повторить шаги заново... Это не решение проблемы... это её усугубление, поскольку со временем изменений станет так много, что разобраться в документации будет нереально. Собственно, об этом писал ещё Ф. Брукс в своей книге "Мифический человеко-месяц...".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 06:21 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3124
Откуда: Астрахань
alexus писал(а):
igor писал(а):
Рефакторинг нужен тогда, когда вместо системы создают большую программу и... сильно гордятся этим.Другими словами, рефакторинг является следствием ошибок моделирования и проектирования... ширмой, за которой прячут эти ошибки. И поэтому должен подвергаться осуждению.

C этим не соглашусь.
Всякая система (и даже программа) проходит свой путь развития. Через это нельзя перешагнуть - этот путь можно только пройти. По мере развития рефакторинг и происходит.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 06:35 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
В итоге пост оказался целиком офтопик :) viewtopic.php?f=86&t=3606&p=66314#p66314; перенесён [url]сюда[/url].


Последний раз редактировалось Владислав Жаринов Суббота, 15 Октябрь, 2011 10:52, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон и проектирование систем
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 07:09 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 531
Откуда: Москва
alexus писал(а):
PS. Повторю своё предложение: если желаете, могу прокомментировать сказанное ранее.
Да желаем, ясное дело. Ждем с нетерпением.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 07:18 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Валерий Лаптев писал(а):
alexus писал(а):
igor писал(а):
Рефакторинг нужен тогда, когда вместо системы создают большую программу и... сильно гордятся этим.Другими словами, рефакторинг является следствием ошибок моделирования и проектирования... ширмой, за которой прячут эти ошибки. И поэтому должен подвергаться осуждению.
C этим не соглашусь.
Всякая система (и даже программа) проходит свой путь развития. Через это нельзя перешагнуть - этот путь можно только пройти. По мере развития рефакторинг и происходит.
Развитие бывает разным... Можно всё переделывать, можно развивать добавляя новое. Это разные пути.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 07:28 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2934
Откуда: г. Ярославль
Info21 писал(а):
Иван Кузьмицкий писал(а):
alexus писал(а):
рефакторинг является следствием ошибок моделирования и проектирования... ширмой, за которой за которой прячут эти ошибки. И поэтому должен подвергаться осуждению.
Разрешите подписаться.
Как обычно, в дискуссии момент "каши в голове".

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

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон и проектирование систем
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 07:51 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
С чисто экономических позиций - если Вы как специалист в работе с исходниками оцениваете затраты времени/сил/средств на сторонних "затратчиков" в случае перекройки как меньшие, чем в случае написания "додуманного" и "допроектированного" - то да, можно трактовать как "инвестиции". Это на "коротких временах" - в данном случае для периода поднятия единичного нового проекта. А на "длинных" - м.б. оказаться лучше "инвестировать" в архитектуру правильную, по-Вашему как специалиста уже в целом в своей отрасли... так ведь?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон и проектирование систем
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 08:00 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Peter Almazov писал(а):
alexus писал(а):
PS. Повторю своё предложение: если желаете, могу прокомментировать сказанное ранее.
Да желаем, ясное дело. Ждем с нетерпением.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон и проектирование систем
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 08:26 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Уже интересно... примерно о том же, что у Михайлова... токо он там всё сводит к работе с приложением и с "предметником"... не касаясь метода оптимального развития всей "человеко-машинной" системы... :)

Кстати, свой предыдущий пост дополнил кое-чем... по части вопросов в первую очередь.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 65 ]  На страницу 1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB