Вопрос такой – не является ли придумывание и фиксация
Архитектуры приложения – разновидностью преждевременной оптимизации?
Тезисы такие.
Существует процедура рефакторинга.
Довольно монстрообразные программы при помощи последовательного применения довольно очевидных рефакторингов приводятся к благообразному виду.
С дргугой стороны, как правило, задуманная первоначально структура программы со временем размывается и довольно быстро перестает быть актуальной.
Напрашивается мысль, что рефакторинги можно было бы применять автоматически при комитах изменений.
Искать повторно используемый код – выделять функции и переменные.
Инлайнить функции и переменные.
Группировать функции с данными, с которыми они наиболее плотно используются.
Превращать аргументы функций в члены классов и обратно.
Ну и множество других довольно тупых действий.
При этом считать различные метрики графа кода и добиваться их оптимизации.
Еще раз повторюсь, в каждом шаге рефакторинга ничего особо интеллектуального нет, можно и машину научить его применять, а вот результаты систематического применения дают весьма сносный и логичный код.
Напрашивается аналогия с алгоритмом балансируемого дерева.
Вы добавляете элементы к дереву, они встраиваются в соответствующие узлы.
Когда большое число новых элементов нарушает баланс дерева, оно автоматически перестраивается.
Предлагается то же самое для дерева кода программы.
C>Напрашивается мысль, что рефакторинги можно было бы применять автоматически при комитах изменений.
ИМХО, это из той же оперы что научить компьютер писать программу по заданномму человеком описанию в произвольной форме. Компьютер видет текст программы, синтаксис, что написано — но он понятия не имеет о логике, стоящей за этим кодом. Тоесть зачем это написано. Рефакторинг это не только тривиальные модификации — но и выделение кусков кода, объединенной общей логикой — композиция и декомпозиция. Не думаю, что компьютер можно этому научить для сколь нибудь общего случая. Ну а для частного случая всегда есть DSL .
C>Искать повторно используемый код – выделять функции и переменные. C>Инлайнить функции и переменные. C>Группировать функции с данными, с которыми они наиболее плотно используются. C>Превращать аргументы функций в члены классов и обратно. C>Ну и множество других довольно тупых действий. C>При этом считать различные метрики графа кода и добиваться их оптимизации. C>Еще раз повторюсь, в каждом шаге рефакторинга ничего особо интеллектуального нет, можно и машину научить его применять, а вот результаты систематического применения дают весьма сносный и логичный код.
Увы, то что вы написали — это не архитектура программы — это всего лишь стиль кодирования. С тем же успехом можно применять policy при коммитах — последние несколько лет это достаточно популярно, есть автоматизированные решения которые приводят код к нужному виду, препятствуют коммиту кода не уклдывающегося в метрики и так далее.
C>Напрашивается аналогия с алгоритмом балансируемого дерева. C>Вы добавляете элементы к дереву, они встраиваются в соответствующие узлы. C>Когда большое число новых элементов нарушает баланс дерева, оно автоматически перестраивается. C>Предлагается то же самое для дерева кода программы.
Увы, код программы — это не древовидная структура с весами, которую можно сбалансировать. Разве что только функции по длине рассортировать
Здравствуйте, Chrome, Вы писали:
C>Существует процедура рефакторинга.
Лучше бы ее не существовало.
C>Довольно монстрообразные программы при помощи последовательного применения довольно очевидных рефакторингов приводятся к благообразному виду. С>С дргугой стороны, как правило, задуманная первоначально структура программы со временем размывается и довольно быстро перестает быть актуальной.
Спорные сентенции. Последовательное применение реf**ckторингов (тем более — автоматических) ничего ни к чему не приводит, а мало-мальски вдумчиво спроектированная система "размывается", как вы отметили, так долго, что этим "размыванием" можно смело пренебречь.
C>Напрашивается мысль, что рефакторинги можно было бы применять автоматически при комитах изменений.
Не напрашивается.
C>Ну и множество других довольно тупых действий.
Вся соль — в порядке применения этих действий.
С>При этом считать различные метрики графа кода и добиваться их оптимизации. С>Предлагается то же самое для дерева кода программы.
Так для дерева или графа?
Здравствуйте, Chrome, Вы писали:
C>Вопрос такой – не является ли придумывание и фиксация C>Архитектуры приложения – разновидностью преждевременной оптимизации?
C>Напрашивается аналогия с алгоритмом балансируемого дерева. C>Вы добавляете элементы к дереву, они встраиваются в соответствующие узлы. C>Когда большое число новых элементов нарушает баланс дерева, оно автоматически перестраивается. C>Предлагается то же самое для дерева кода программы.
Надо математически доказать сходимость процесса. В отличии от дерева, система рефакторингов может образовывать граф с циклами. Следовательно архитектура и код могут начать перестраиваться бесконечно. И думается мне, что задача эта не разрешима. Посему автоматом можно лишь править форматирование.
Здравствуйте, Eye of Hell, Вы писали:
EOH>ИМХО, это из той же оперы что научить компьютер писать программу по заданномму человеком описанию в произвольной форме. Компьютер видет текст программы, синтаксис, что написано — но он понятия не имеет о логике, стоящей за этим кодом. Тоесть зачем это написано. Рефакторинг это не только тривиальные модификации — но и выделение кусков кода, объединенной общей логикой — композиция и декомпозиция. Не думаю, что компьютер можно этому научить для сколь нибудь общего случая. Ну а для частного случая всегда есть DSL .
А на что может существенно повлиять ЗНАНИЕ логики, стоящей за кодом, при выполнении рефакторинга?
Ведь логика в коде содержится и при рефакторинге никуда не девается(сохраняется).
То есть представляет собой своеобразный инвариант.
При этом существует бесконечное множество возможных деревьев кода, реализующих одну и ту же логику. Однако для человека эти деревья не однозначны.
Человеческое восприятие накладывает на них некую метрику, в диапазоне от ГОВНОКОД до ИДЕАЛЬНЙ КОД.
Предлагается эту метрику формализовать и использовать для автоматической оптимизации дерева кода.
EOH>Увы, то что вы написали — это не архитектура программы — это всего лишь стиль кодирования.
Я предлагаю анализировать и оптимизировать следующие вещи
Группировка полей данных по классам
Группировка предложений кода в функции
Распределение функций по классам.
Может это и не вся архитектура, но значительная часть того, что под ней понимается.
Я не планирую трогать следующие вещи:
Используемые алгоритмы ( потоки преобразования данных )
Здравствуйте, _Obelisk_, Вы писали:
_O_>Надо математически доказать сходимость процесса. В отличии от дерева, система рефакторингов может образовывать граф с циклами. Следовательно архитектура и код могут начать перестраиваться бесконечно. И думается мне, что задача эта не разрешима. Посему автоматом можно лишь править форматирование.
Если сопоставить программе "метрику оптимальности", и применять только рефакторинги, улучшающие эту метрику, то никаких циклов не будет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
C>Человеческое восприятие накладывает на них некую метрику, в диапазоне от ГОВНОКОД до ИДЕАЛЬНЙ КОД. C>Предлагается эту метрику формализовать и использовать для автоматической оптимизации дерева кода.
Еще раз повторю — это попытка создать программу, которая будет сама рисовать красивые картины. Или писать интересные книги. Или сочинять музыку. На данном этапе развития IT мы так не умеем.
Здравствуйте, Chrome, Вы писали:
C>Вопрос такой – не является ли придумывание и фиксация C>Архитектуры приложения – разновидностью преждевременной оптимизации?
Является, потому во всяких аджилах избегают городить и фиксировать архитектуру на ранних стадиях.
C>Вопрос такой – не является ли придумывание и фиксация C>Архитектуры приложения – разновидностью преждевременной оптимизации?
Придумывание материализуется в виде архитектуры, и если трогать придуманную архитектуру, то вы отдалитесь от модели,
и затрудните дальнейшее развитие.
C>Довольно монстрообразные программы при помощи последовательного применения довольно очевидных рефакторингов приводятся к благообразному виду.
Если в голове каша, и на выходе получаются монстры, то надо менять голову, потому как такой архитектор даже в благооборазном коде не разберется.
C>С дргугой стороны, как правило, задуманная первоначально структура программы со временем размывается и довольно быстро перестает быть актуальной.
пока архитектура существует только на одном уровне — уровень кода, ничего с этим не сделаешь. А если будет можно разбить модель на слои с разной детализацией, UML например, то можно будет управлять гораздо большей сложностью моделей.
C>Искать повторно используемый код – выделять функции и переменные.
Мне кажется, пока код не будет изначально структурированным, то рефакторинг мало поможет.
Просто следующий шаг в замене имени переменной не в одном файле а во всем проекте.
C>При этом считать различные метрики графа кода и добиваться их оптимизации.
Оптимизации для чего ? Для последующего управления или для исполнения ?
C>Когда большое число новых элементов нарушает баланс дерева, оно автоматически перестраивается.
Только вот модель дерева разрабатывалась для быстрого доступа к элементам или для хранения.
Главное в любой архитектуре это связи элементов, и если их трогать то это только усложнит понимание.
C>Предлагается то же самое для дерева кода программы.
Код сразу верстать в дереве, на элементы навесить тэги, и сделать фильтры выборки по тэгам — это относится к модели, это к интерфейсу, это к управлению.
Здравствуйте, Chrome, Вы писали:
C>Вопрос такой – не является ли придумывание и фиксация C>Архитектуры приложения – разновидностью преждевременной оптимизации?
Кроме преждевременной оптимизации бывает еще преждевременное обобщение. Здесь этот термин уместнее, ИМХО.
.
