Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>И ещё: что у вас по оси ординат?

Сложность системы: количество модулей, классов и т.п.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, ZevS, Вы писали:

ZS>>Ну конечно я слукавил, и всё взаимосвязано. Чем больше сложность системы (но все же не размер), тем больше вероятность ошибок.
ZS>>Однако, каждый может привести множество примеров, когда увеличение размеров кода снижает сложнось.

ГВ>А что такое "сложность"?

Есть довольно много вполне количественных метрик — здесь

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>>>На основе анализа ряда примеров. Один из них приведен здесь. Но есть и другие.

ГВ>>Сколько их было всего? И ещё: что у вас по оси ординат?

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

Отсюда

Автор: Кирилл Лебедев
Дата: 20.04.07

ГВ>>И ещё: что у вас по оси ординат?
КЛ>Сложность системы: количество модулей, классов и т.п.

Хорошо, с этим ясно — всё таки, какие-то более или менее измеримые характеристики и выборка, судя по всему, репрезентативная.

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

ГВ>>А что тогда является этим самым "ключевым параметром"?

КЛ>Каждое из этих действий. Иными словами, нужно проектировать структуры данных под конкретные операции.

Вы сами запутываете своих читателей. Если само действие является ключевым параметром, который, вроде как, должен быть только одним из атрибутов (на то он и "параметр"), то получается какая-то нелепица. Я так понимаю, что если речь пошла о параметрах, то: а) они выделяются как сущность в каждом из рассматриваемых объектов и б) вводится отношение порядка между значениями этого параметра. А у вас не совсем понятно — почему действия упорядочены именно так, а не иначе. Короче говоря — где в этих действиях тот самый пресловутый ключевой параметр?

ГВ>>Мда. Понятно.

КЛ>Если Вам непонятен какой-нибудь термин, спросите, я постараюсь пояснить.

Здесь тот самый случай, когда "узнал все буквы, не смог прочесть слово". Термины-то все понятны, просто их употребление вызывает оторопь. Уж поверьте, я знаком с семантикой "точки зрения" и "контекста". А вот их отождествление — это уже даже не смешно.

КЛ>Про зловредное определительство написано здесь.
КЛ>Яркий клинический случай описан здесь.

Спасибо, любопытно. Но об этом позже.

Здравствуйте, ZevS, Вы писали:

ZS>>>Ну конечно я слукавил, и всё взаимосвязано. Чем больше сложность системы (но все же не размер), тем больше вероятность ошибок.
ZS>>>Однако, каждый может привести множество примеров, когда увеличение размеров кода снижает сложнось.

ГВ>>А что такое "сложность"?

ZS>Есть довольно много вполне количественных метрик — здесь

Про метрики я знаю. А можно уточнить, в каком случае увеличение размера программы привело к снижению измеримой сложности? И как эту сложность меряли? Какая конкретно метрика использована?

Здравствуйте, Кирилл Лебедев, Вы писали:

ГВ>>Сколько их было всего?

КЛ>На текущий момент, несколько десятков.

Тогда вам, вероятно, не составит труда дать агрегированные характеристики проектов. Например, такие:

— средний размер (в строках, классах);
— языки программирования (распределение);
— продолжительность проектов;
— численность и квалификация команд.

И, соответственно, сводку по эволюции проектов:

— Как изменились характеристики проектов после модификации (размеры до и после, сложности, соотношения в разрезе проектов и языков программирования);
— Продолжительность циклов модификации;
— Корреляция характеристик модификаций с усреднённым опытом команд.

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

Хочу заметить, что таки да, "они все вокруг — плохиши". Я в курсе.

Здравствуйте, Геннадий Васильев, Вы писали:

...

ГВ>Про метрики я знаю. А можно уточнить, в каком случае увеличение размера программы привело к снижению измеримой сложности? И как эту сложность меряли? Какая конкретно метрика использована?

Из личного опыта. Надо было внести иименения в код, довольно небольшой (всего ~500 строк), но со сложной логикой. Кем и когда этот код был написал — не известно. Так вот, изменения удалось внести только после рефакторинга (а по сути написания заново), увеличившего размер кода чуть ли не в два раза. В данном конкретном случае сложность измерялась субъективным критерием наиболее близким к понятности.
Безусловно между размером кода и сложностью есть связь, но ставить знак равенства...

Здравствуйте, ZevS, Вы писали:

ГВ>>Про метрики я знаю. А можно уточнить, в каком случае увеличение размера программы привело к снижению измеримой сложности? И как эту сложность меряли? Какая конкретно метрика использована?

ZS>Из личного опыта. Надо было внести иименения в код, довольно небольшой (всего ~500 строк), но со сложной логикой. Кем и когда этот код был написал — не известно. Так вот, изменения удалось внести только после рефакторинга (а по сути написания заново), увеличившего размер кода чуть ли не в два раза. В данном конкретном случае сложность измерялась субъективным критерием наиболее близким к понятности.

О! Молодец!

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

ZS>Безусловно между размером кода и сложностью есть связь, но ставить знак равенства...

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

Здравствуйте, Геннадий Васильев, Вы писали:

...

ГВ>Вот в том-то и дело, что сложность и трудность для понимания — это совсем-совсем не одно и то же.

В общем случае — да, но они сильно скоррелированы. А вот путать сложность системы и сложность кода уж точно не следует.

Первая величина — объективная, вторая — субъективная. И их ни в коем случае нельзя путать. Код одинаковой сложности может быть понятен одному и совершенно не понятен другому. В то же время — да, объективно более сложная программа может быть более простой для восприятия. Справедливо и обратное — простая программа может быть очень трудной для понимания.

Ну не так все плохо... Все же в отрасли уже выработаны рекомендации и паттерны, понятные всем.

ZS>>Безусловно между размером кода и сложностью есть связь, но ставить знак равенства...

ГВ>Ну как тебе сказать, если метрики зачастую как раз и являются производными от объёма исходного кода... За исключением разных там усредняемых показателй, типа средней цикломатической сложности методов класса.

Поэтому я больше доверяю визуальным оценкам. ) Оценки таких количественных показателей как сoupling & cohesion от размера кода зависят слабо, однако именно они довольно сильно влияют на субъективную понятность.

Здравствуйте, ZevS, Вы писали:

ZS>Ну не так все плохо... Все же в отрасли уже выработаны рекомендации и паттерны, понятные всем.

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

ZS>Поэтому я больше доверяю визуальным оценкам. ) Оценки таких количественных показателей как сoupling & cohesion от размера кода зависят слабо, однако именно они довольно сильно влияют на субъективную понятность.

Согласен. Потому что эти показатели отражают возможность сконцентрироваться при анализе на отдельно взятом модуле.

Здравствуйте, ZevS, Вы писали:

IT>>Увеличение размеров кода снижает сложность только, если этот код обобщается и переносится из бизнес логики в библиотеки и фреймворки. Т.е. общую сложность можно снизить только её перераспределением.

ZS>+ опускаясь ниже, более лаконичный код не всегда более понятный.

ZS>А вообще, мой изначальный посыл был о том, что борьба с размером кода имхо борьба не с тем чем надо. Снижение сложности и уменьшение числа ошибок — вот настоящие проблемы. А то получается, что идеальная программа — workaround.

В теории? возможно? это так, с теоретиками не буду спорить. Но на практике же оказывается, что в 99% связь между лаконичностью и простотой кода практически прямая. А в случае кода безнес логики это справедливо на 120%.

Здравствуйте, ZevS, Вы писали:

ZS>Из личного опыта. Надо было внести иименения в код, довольно небольшой (всего ~500 строк), но со сложной логикой. Кем и когда этот код был написал — не известно. Так вот, изменения удалось внести только после рефакторинга (а по сути написания заново), увеличившего размер кода чуть ли не в два раза. В данном конкретном случае сложность измерялась субъективным критерием наиболее близким к понятности.

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

ZS>Безусловно между размером кода и сложностью есть связь, но ставить знак равенства...

При прочих равных связь практически всегда однозначная.

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Яркий клинический случай описан здесь.

Видимо здесь при подаче материала ты руководствовался именно этой статьёй.

Здравствуйте, IT, Вы писали:

...

IT>Способность кода к модификации — это ещё одна характеристика, напрямую относящаяся к качеству. В своём примере ты сравниваешь компактный, но некачественный код с качественным. Сравнение не корректное. Так, например, для достижения лучшей сопровождаемости код может быть разбит на логические слои, что сразу увеличивает количество строк кода в несколько раз.

В своем первом сообщении я как раз и сказал о том, что надо бороться за качество, а не размер. Уменьшение размера — побочный положительный эффект.

Здравствуйте, IT, Вы писали:

...

IT>В теории? возможно? это так, с теоретиками не буду спорить. Но на практике же оказывается, что в 99% связь между лаконичностью и простотой кода практически прямая. А в случае кода безнес логики это справедливо на 120%.

Короткие лаконичные программы на Perl просто ужасны.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Про метрики я знаю. А можно уточнить, в каком случае увеличение размера программы привело к снижению измеримой сложности? И как эту сложность меряли? Какая конкретно метрика использована?

Имхо, тут присутствует некорректное понимание сложности. Мое мнение таково, что сложность невозможно адекватно измерить простыми метриками. Сложность — это количество реализованных идей. Как именно эти идеи реализованы: в виде классов, шаблонов, или еще как — не суть важно. Таким образом, возможны ситуации, когда компактный код более сложен, чем код раздутый. Например, у нас может быть очень компактный код в стиле "аля Александреску", в котором в нескольких строчках кода сосредоточено большое количество идей, из-за чего код является сложным и при этом компактным. Теперь другой пример: код имеет регулярную структуру, но при этом объем кода большой. Ну, например, ручной DB мэппинг. Или реализация в отдельном классе каждой типизированной колекции. Во всех этих случаях, мы имеем тонны кода, который при этом очень простой.

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

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вы сами запутываете своих читателей. Если само действие является ключевым параметром, который, вроде как, должен быть только одним из атрибутов (на то он и "параметр"), то получается какая-то нелепица. Я так понимаю, что если речь пошла о параметрах, то: а) они выделяются как сущность в каждом из рассматриваемых объектов и б) вводится отношение порядка между значениями этого параметра. А у вас не совсем понятно — почему действия упорядочены именно так, а не иначе. Короче говоря — где в этих действиях тот самый пресловутый ключевой параметр?

Ок. Попробую пояснить. При проектировании системы важно задать нечто, вокруг чего можно дальше строить классификацию. Например, в ООП под этим нечто предлагается понимать объекты предметной области. Какие-то из них впоследствии отсеиваются, но часть — по утверждения классиков ООП — остается.

Я же предлагаю ориентироваться не на объекты, а на действия. И проектировать структуры данных, модули под эти действия. Т.е. операция, функция (пользовательская) — первична, а объект — вторичен.

ГВ>Здесь тот самый случай, когда "узнал все буквы, не смог прочесть слово". Термины-то все понятны, просто их употребление вызывает оторопь. Уж поверьте, я знаком с семантикой "точки зрения" и "контекста". А вот их отождествление — это уже даже не смешно.

И что тут смешного?

Здравствуйте, IT, Вы писали:


IT>В теории? возможно? это так, с теоретиками не буду спорить. Но на практике же оказывается, что в 99% связь между лаконичностью и простотой кода практически прямая.

Поковыряй какой-нибудь boost. Там код весьма лаконичен, но вот простой ли он?

Здравствуйте, Кирилл Лебедев, Вы писали:


КЛ>Я же предлагаю ориентироваться не на объекты, а на действия. И проектировать структуры данных, модули под эти действия. Т.е. операция, функция (пользовательская) — первична, а объект — вторичен.

Поздравляю, вы открыли для себя структурное программирование

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Тогда вам, вероятно, не составит труда дать агрегированные характеристики проектов. Например, такие:

ГВ>- средний размер (в строках, классах);
ГВ>- языки программирования (распределение);
ГВ>- продолжительность проектов;
ГВ>- численность и квалификация команд.

В основном, мне приходилось работать с проектами, размером от сотен клибайт до нескольких мегабайт. Языки программирования: Си, Си++, Паскаль (Дельфи), C#. Количество классов не считал. В небольших проектах (сотня-другая килобайт) их количество измеряется десятками (20 — 30). В больших, конечно, поболее.

Продолжительность тоже разная. От месяца до года и т.д. Квалификация команд тоже разная. Но, в основном, 2-3 ведущих программиста и столько же (или даже больше) вчерашних студентов.

ГВ>И, соответственно, сводку по эволюции проектов:

ГВ>- Как изменились характеристики проектов после модификации (размеры до и после, сложности, соотношения в разрезе проектов и языков программирования);
ГВ>- Продолжительность циклов модификации;
ГВ>- Корреляция характеристик модификаций с усреднённым опытом команд.

Обычно подобная статистика собирается после обкатки методики. Т.е. я ее не собирал. Во-первых, считаю, что рано. Во-вторых, и без того еще много задач, которые необходимо решить.

Однако, если судить по эволюции проектов, которые правильно спроектированы (пусть даже и небольших), то можно увидеть следующее:

1) Очень маленькое количество багов. Измеряется штуками: от 2 до 5. Практически все баги находятся на этапе тестирования.
2) К коду обязательно прилагается документация с описанием дизайна. На более-менее значительные изменения в коде тоже есть документация.
3) Впоследствии код под давлением новых требований изменяется, но очень незначительно. Архитектура не разрушается и остается цельной. Т.е. изменения укладываются в существующую модель.

Здравствуйте, prVovik, Вы писали:

V>Здравствуйте, Кирилл Лебедев, Вы писали:


КЛ>>Я же предлагаю ориентироваться не на объекты, а на действия. И проектировать структуры данных, модули под эти действия. Т.е. операция, функция (пользовательская) — первична, а объект — вторичен.

V>Поздравляю, вы открыли для себя структурное программирование

Не смешивайте два разных понятия: бизнес-функция и функция языка программирования. Я говорю о первой.