Автоматическая генерация архитектуры ПО.
От: Chrome  
Дата: 26.07.11 11:33
Оценка: 8 (3) +1 :))) :))
Вопрос такой – не является ли придумывание и фиксация
Архитектуры приложения – разновидностью преждевременной оптимизации?

Тезисы такие.

Существует процедура рефакторинга.

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

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

Напрашивается мысль, что рефакторинги можно было бы применять автоматически при комитах изменений.

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

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

Напрашивается аналогия с алгоритмом балансируемого дерева.
Вы добавляете элементы к дереву, они встраиваются в соответствующие узлы.
Когда большое число новых элементов нарушает баланс дерева, оно автоматически перестраивается.
Предлагается то же самое для дерева кода программы.
Re: Автоматическая генерация архитектуры ПО.
От: Eye of Hell Россия eyeofhell.habr.ru
Дата: 26.07.11 16:13
Оценка:
C>Напрашивается мысль, что рефакторинги можно было бы применять автоматически при комитах изменений.

ИМХО, это из той же оперы что научить компьютер писать программу по заданномму человеком описанию в произвольной форме. Компьютер видет текст программы, синтаксис, что написано — но он понятия не имеет о логике, стоящей за этим кодом. Тоесть зачем это написано. Рефакторинг это не только тривиальные модификации — но и выделение кусков кода, объединенной общей логикой — композиция и декомпозиция. Не думаю, что компьютер можно этому научить для сколь нибудь общего случая. Ну а для частного случая всегда есть DSL .

C>Искать повторно используемый код – выделять функции и переменные.

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

Увы, то что вы написали — это не архитектура программы — это всего лишь стиль кодирования. С тем же успехом можно применять policy при коммитах — последние несколько лет это достаточно популярно, есть автоматизированные решения которые приводят код к нужному виду, препятствуют коммиту кода не уклдывающегося в метрики и так далее.

C>Напрашивается аналогия с алгоритмом балансируемого дерева.

C>Вы добавляете элементы к дереву, они встраиваются в соответствующие узлы.
C>Когда большое число новых элементов нарушает баланс дерева, оно автоматически перестраивается.
C>Предлагается то же самое для дерева кода программы.

Увы, код программы — это не древовидная структура с весами, которую можно сбалансировать. Разве что только функции по длине рассортировать
Re: Автоматическая генерация архитектуры ПО.
От: Wolverrum Ниоткуда  
Дата: 26.07.11 17:34
Оценка:
Здравствуйте, Chrome, Вы писали:

C>Существует процедура рефакторинга.


Лучше бы ее не существовало.

C>Довольно монстрообразные программы при помощи последовательного применения довольно очевидных рефакторингов приводятся к благообразному виду.

С>С дргугой стороны, как правило, задуманная первоначально структура программы со временем размывается и довольно быстро перестает быть актуальной.
Спорные сентенции. Последовательное применение реf**ckторингов (тем более — автоматических) ничего ни к чему не приводит, а мало-мальски вдумчиво спроектированная система "размывается", как вы отметили, так долго, что этим "размыванием" можно смело пренебречь.

C>Напрашивается мысль, что рефакторинги можно было бы применять автоматически при комитах изменений.

Не напрашивается.

C>Ну и множество других довольно тупых действий.

Вся соль — в порядке применения этих действий.

С>При этом считать различные метрики графа кода и добиваться их оптимизации.

С>Предлагается то же самое для дерева кода программы.
Так для дерева или графа?


ЗЫ Имхо Вы переоткрыли суперкомпиляцию.
Re: Автоматическая генерация архитектуры ПО.
От: _Obelisk_ Россия http://www.ibm.com
Дата: 26.07.11 17:58
Оценка:
Здравствуйте, Chrome, Вы писали:

C>Вопрос такой – не является ли придумывание и фиксация

C>Архитектуры приложения – разновидностью преждевременной оптимизации?

C>Напрашивается аналогия с алгоритмом балансируемого дерева.

C>Вы добавляете элементы к дереву, они встраиваются в соответствующие узлы.
C>Когда большое число новых элементов нарушает баланс дерева, оно автоматически перестраивается.
C>Предлагается то же самое для дерева кода программы.

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


http://www.rsdn.org:80/File/18435/5278.png
Душа обязана трудиться! (с) Н.Заболоцкий.
Re[2]: Автоматическая генерация архитектуры ПО.
От: Chrome  
Дата: 27.07.11 10:18
Оценка:
Здравствуйте, Eye of Hell, Вы писали:

EOH>ИМХО, это из той же оперы что научить компьютер писать программу по заданномму человеком описанию в произвольной форме. Компьютер видет текст программы, синтаксис, что написано — но он понятия не имеет о логике, стоящей за этим кодом. Тоесть зачем это написано. Рефакторинг это не только тривиальные модификации — но и выделение кусков кода, объединенной общей логикой — композиция и декомпозиция. Не думаю, что компьютер можно этому научить для сколь нибудь общего случая. Ну а для частного случая всегда есть DSL .


А на что может существенно повлиять ЗНАНИЕ логики, стоящей за кодом, при выполнении рефакторинга?
Ведь логика в коде содержится и при рефакторинге никуда не девается(сохраняется).
То есть представляет собой своеобразный инвариант.
При этом существует бесконечное множество возможных деревьев кода, реализующих одну и ту же логику. Однако для человека эти деревья не однозначны.
Человеческое восприятие накладывает на них некую метрику, в диапазоне от ГОВНОКОД до ИДЕАЛЬНЙ КОД.
Предлагается эту метрику формализовать и использовать для автоматической оптимизации дерева кода.



EOH>Увы, то что вы написали — это не архитектура программы — это всего лишь стиль кодирования.


Я предлагаю анализировать и оптимизировать следующие вещи

Группировка полей данных по классам
Группировка предложений кода в функции
Распределение функций по классам.

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

Я не планирую трогать следующие вещи:
Используемые алгоритмы ( потоки преобразования данных )

Что еще можно понимать под архитектурой?
Re[2]: Автоматическая генерация архитектуры ПО.
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 27.07.11 15:22
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>Надо математически доказать сходимость процесса. В отличии от дерева, система рефакторингов может образовывать граф с циклами. Следовательно архитектура и код могут начать перестраиваться бесконечно. И думается мне, что задача эта не разрешима. Посему автоматом можно лишь править форматирование.

Если сопоставить программе "метрику оптимальности", и применять только рефакторинги, улучшающие эту метрику, то никаких циклов не будет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[3]: Автоматическая генерация архитектуры ПО.
От: Eye of Hell Россия eyeofhell.habr.ru
Дата: 03.08.11 04:50
Оценка: 1 (1)
C>Человеческое восприятие накладывает на них некую метрику, в диапазоне от ГОВНОКОД до ИДЕАЛЬНЙ КОД.
C>Предлагается эту метрику формализовать и использовать для автоматической оптимизации дерева кода.

Еще раз повторю — это попытка создать программу, которая будет сама рисовать красивые картины. Или писать интересные книги. Или сочинять музыку. На данном этапе развития IT мы так не умеем.
Re: Автоматическая генерация архитектуры ПО.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.08.11 09:00
Оценка:
Здравствуйте, Chrome, Вы писали:

C>Вопрос такой – не является ли придумывание и фиксация

C>Архитектуры приложения – разновидностью преждевременной оптимизации?

Является, потому во всяких аджилах избегают городить и фиксировать архитектуру на ранних стадиях.
Re: Автоматическая генерация архитектуры ПО.
От: lseder lseder.livejournal.com
Дата: 03.08.11 16:22
Оценка:
C>Вопрос такой – не является ли придумывание и фиксация
C>Архитектуры приложения – разновидностью преждевременной оптимизации?
Придумывание материализуется в виде архитектуры, и если трогать придуманную архитектуру, то вы отдалитесь от модели,
и затрудните дальнейшее развитие.

C>Довольно монстрообразные программы при помощи последовательного применения довольно очевидных рефакторингов приводятся к благообразному виду.

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

C>С дргугой стороны, как правило, задуманная первоначально структура программы со временем размывается и довольно быстро перестает быть актуальной.

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

C>Искать повторно используемый код – выделять функции и переменные.

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

C>При этом считать различные метрики графа кода и добиваться их оптимизации.

Оптимизации для чего ? Для последующего управления или для исполнения ?

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

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

C>Предлагается то же самое для дерева кода программы.

Код сразу верстать в дереве, на элементы навесить тэги, и сделать фильтры выборки по тэгам — это относится к модели, это к интерфейсу, это к управлению.
Re: Автоматическая генерация архитектуры ПО.
От: Kerk Россия  
Дата: 12.08.11 20:48
Оценка:
Здравствуйте, Chrome, Вы писали:

C>Вопрос такой – не является ли придумывание и фиксация

C>Архитектуры приложения – разновидностью преждевременной оптимизации?

Кроме преждевременной оптимизации бывает еще преждевременное обобщение. Здесь этот термин уместнее, ИМХО.

Но в автоматический рефакторинг я не верю
No taxation without representation
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.