Главная проблема всей идеи в том, что подобрать функцию скрещивания оказалось весьма и весьма проблематично.
Думаю, проблема в неправильном выборе представления слоя. Стоит попробовать представить интерфейс в виде quadtree, размещая нужные элементы в его узлах.
Для такого представления данных, можно вводить адекватные операторы мутации и скрещивания. В сети много информации по эволюции сетевых структур, так что проект ещё можно довести до ума.
Основной тезис, который я хотел донести: мы не можем нормально формализовать понятие качества кода и архитектуры.
Согласен. Также согласен с проблемой «негативных определений». Но отсутствие нормальной формализации не означает её полное отсутствие — другие области знаний тоже не в одним момент формализовали.
Учитывая «негативное определение», можно метрики качества превратить в метрики-антонимы. Пусть они измеряют уровень «брака» — тоже полезный параметр.
Какой алгоритм качественнее: со вычислительной сложностью O(N) и памятью O(1) или наоборот?
В этом случаем мы имеет дело с частично упорядоченных множеством, и данные алгоритмы, соответственно, несравнимы. Но это не отменяет того факта, что другие алгоритмы будут сравнимыми.
Если же вернуться к менее абстрактным вещам, то в рамках конкретного ТЗ вполне можно сравнить даже эти алгоритмы. Достаточно ввести суммарную метрику, основанную на ограничении ресурсов в ТЗ.
Которые показывают погоду на Марсе. То, что эти метрики стабильны не означает, что они объективно характеризуют качество.
Каким свойством должна обладать метрика, чтобы объективно что-то характеризовать?
Серебряной пули даже в физике нет. Законы Ньютона тоже не всегда работают, но позволяют делать достаточно точные предположения о положении тел в пространстве при определённых допущениях. Так же и приведённые мной метрики позволяют делать предположения (конечно, менее точные чем физические законы) о качестве кода.
Если у нас есть два проекта, выполняющих одну задачу (или один проект в разных версиях), то ориентируясь на изменение этих метрик мы можем объективно сказать, что качество стало лучше или хуже. Более того, на основе этих метрик, мы может строить прогнозы того, как изменится качество кода при исследуемых изменениях.
Это вообще не про код и архитектуру, но про алгоритмы.
Раз уж пошло, то это и про то и про другое. Хорошая характеристика и архитектуры и кода, т.к. итоговая вычислительная сложность конкретного куска кода зависит и от первого и от второго. Вполне можно написать пузырьковую сортировку в которой под капотом будет логарифмическая сложность получения элемента из контейнера. О сложностях при взаимодействии между разными компонентами, я надеюсь, говорить не стоит. Поэтому вычислительная сложность (в купе с её аналогом для используемой памяти) — это именно показатель качества.
Объективные характеристики качества?!
НФ — объективный показатель качества модели данных.
Давайте не будем забывать, что аспектов у программного проекта множество и они часто имеют взаимоисключающие свойства. Нормальная форма — это (как и большинство других метрик) показатель качества для конкретной части проекта (используемой модели данных), а не его всего.
Если необходим показатель качества проекта целиком, то его нужно считать из соотношения частных показателей с учётом специфики самого проекта.
Смешиваете понятия. Выдача таких инструментов вполне объективна, они считают ровно те формализованные метрики, которые их просили. SLOC, например. Или SLOC/method. Эти параметры при сильных отклонениях от средних позволяют предположить «code smell». С некоторой долей вероятности.
То есть они позволяют построить некий прогноз, что нам и требуется.
Отсутствие универсальной метрики (или там закона) ни в коем случае не отменяет наличие объектиных частных метрик.
Если метриками никто не пользуется, это не значит, что их нет.
Качество кода: цикломатическая сложность, покрытие кода тестами.
Архитектура: степень связанности, её считают по-разному, но как не считай, а это отличная характеристика способности системы расти и изменяться.
Не будем забывать о таких вещах как вычислительная сложность и нормальные формы реляционных баз данных — это уж точно объективные характеристики.
Если немного отойти в сторону от идеальной объективности, то многие утилиты для анализа кода умеют считать кучу метрик вместе с некоторой суммарной характеристикой. Учитывая, что многие из них поддерживаются большими группами профессионалов, их выдачу можно считать объективной.
Хорошим показателем качества кода, например, можно считать компиляцию проекта gcc с флагами -Wall и -Werror.
Даже выдающиеся программисты не возьмут на себя смелость утверждать об архитектуре новой программной системы то, что она будет успешной.
Возьмутся, ещё как — это их прямая должностная обязанность — разрабатывать успешные архитектуры.
По поводу отсутствия законов я бы тоже поспорил. Как минимум, некоторые области достаточно хорошо проработаны (например, реляционные БД), существует куча метрик, которые позволяют достаточно объективно оценивать (или сравнивать) качество кода и архитектуры. Если начать копаться, то есть такие области как системотехника, кибернетика и прочие, с которыми любому будет полезно ознакомиться.
Область, конечно, молодая, но не настолько, чтобы не были выработаны базовые принципы и ограничения.
Соответственно, программирование — это никак не ремесло. Программирование — это молодая инженерная дисциплина (с соответствующими «детскими» болячками).
Если говорим о переопределении, то и пример надо бы с переопределением.
Если говорим перегрузке функций в зависимости от типов, то у нас для этого PEP 443 есть.
А вообще, ковыряться во внутренностях того, с чем надо взаимодействовать как с «чёрным ящиком» — плохая идея.
Думаю, проблема в неправильном выборе представления слоя. Стоит попробовать представить интерфейс в виде quadtree, размещая нужные элементы в его узлах.
Для такого представления данных, можно вводить адекватные операторы мутации и скрещивания. В сети много информации по эволюции сетевых структур, так что проект ещё можно довести до ума.
Согласен. Также согласен с проблемой «негативных определений». Но отсутствие нормальной формализации не означает её полное отсутствие — другие области знаний тоже не в одним момент формализовали.
Учитывая «негативное определение», можно метрики качества превратить в метрики-антонимы. Пусть они измеряют уровень «брака» — тоже полезный параметр.
В этом случаем мы имеет дело с частично упорядоченных множеством, и данные алгоритмы, соответственно, несравнимы. Но это не отменяет того факта, что другие алгоритмы будут сравнимыми.
Если же вернуться к менее абстрактным вещам, то в рамках конкретного ТЗ вполне можно сравнить даже эти алгоритмы. Достаточно ввести суммарную метрику, основанную на ограничении ресурсов в ТЗ.
Каким свойством должна обладать метрика, чтобы объективно что-то характеризовать?
Если у нас есть два проекта, выполняющих одну задачу (или один проект в разных версиях), то ориентируясь на изменение этих метрик мы можем объективно сказать, что качество стало лучше или хуже. Более того, на основе этих метрик, мы может строить прогнозы того, как изменится качество кода при исследуемых изменениях.
Раз уж пошло, то это и про то и про другое. Хорошая характеристика и архитектуры и кода, т.к. итоговая вычислительная сложность конкретного куска кода зависит и от первого и от второго. Вполне можно написать пузырьковую сортировку в которой под капотом будет логарифмическая сложность получения элемента из контейнера. О сложностях при взаимодействии между разными компонентами, я надеюсь, говорить не стоит. Поэтому вычислительная сложность (в купе с её аналогом для используемой памяти) — это именно показатель качества.
НФ — объективный показатель качества модели данных.
Давайте не будем забывать, что аспектов у программного проекта множество и они часто имеют взаимоисключающие свойства. Нормальная форма — это (как и большинство других метрик) показатель качества для конкретной части проекта (используемой модели данных), а не его всего.
Если необходим показатель качества проекта целиком, то его нужно считать из соотношения частных показателей с учётом специфики самого проекта.
То есть они позволяют построить некий прогноз, что нам и требуется.
Отсутствие универсальной метрики (или там закона) ни в коем случае не отменяет наличие объектиных частных метрик.
Если метриками никто не пользуется, это не значит, что их нет.
Качество кода: цикломатическая сложность, покрытие кода тестами.
Архитектура: степень связанности, её считают по-разному, но как не считай, а это отличная характеристика способности системы расти и изменяться.
Не будем забывать о таких вещах как вычислительная сложность и нормальные формы реляционных баз данных — это уж точно объективные характеристики.
Если немного отойти в сторону от идеальной объективности, то многие утилиты для анализа кода умеют считать кучу метрик вместе с некоторой суммарной характеристикой. Учитывая, что многие из них поддерживаются большими группами профессионалов, их выдачу можно считать объективной.
Хорошим показателем качества кода, например, можно считать компиляцию проекта gcc с флагами -Wall и -Werror.
Возьмутся, ещё как — это их прямая должностная обязанность — разрабатывать успешные архитектуры.
По поводу отсутствия законов я бы тоже поспорил. Как минимум, некоторые области достаточно хорошо проработаны (например, реляционные БД), существует куча метрик, которые позволяют достаточно объективно оценивать (или сравнивать) качество кода и архитектуры. Если начать копаться, то есть такие области как системотехника, кибернетика и прочие, с которыми любому будет полезно ознакомиться.
Область, конечно, молодая, но не настолько, чтобы не были выработаны базовые принципы и ограничения.
Соответственно, программирование — это никак не ремесло. Программирование — это молодая инженерная дисциплина (с соответствующими «детскими» болячками).