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

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

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

В термодинамике закон возрастания энтропии сформулирован для замкнутых систем

IT>Всегда и не нужно. Лично мне достаточно того, что я понимаю одну простую вещь — любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот. На практике это означает критическое отношение к любому (абсолютно) паттерну или принципу. Даже к полюбившимся в этой ветке упорядочиванию и абстрагированию, т.к. упорядочивание и абстрагирование всегда в 100% случаях автоматически ведёт к усложнению, а вот для достижения упрощения ещё нужно попотеть.

Аналогия суждения: "использование автомобиля всегда ведёт к дополнительным затратам, потому что в соседний ларёк ездить за пивом на авто не эффективно"

IO>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".

Моделирование всегда снижает сложность. Иначе это не моделирование.

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

IO>>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".

VGn>Моделирование всегда снижает сложность. Иначе это не моделирование.

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

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

IO>>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".

G>Это вообще говоря неверно. напрмиер сделать учетную систему в 1C гораздо проще, чем написать её на ассемблере (вместе с БД).

В данном случае бОльшая часть программируемого аспекта обьекта уже реализована в библиотеках 1С в отличие от ассемблера, но общая сложность решения не уменьшилась.

G>Сложность задачи и сложность кода, решающего задачу вещи вообще говоря ортогональные.

Речь не о сложности задачи, а о сложности решения.

IO>Моделирование снижает сложность обьекта путем выделение некоторого аспекта. Речь же идет о минимальной сложности кода, необходимой для реализации модели.

Если бы автоматизация была дороже ручного процесса, её бы никто не производил.
Так что сложность кода реализующего модель никак не может быть сложнее объекта (в деньгах).

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

E>Во что трансформируется сложность восприятия, если "корявый" код был "причесан" -- произведено переоформление кода, переименование переменных/классов/методов, и вместо notepad-а разработчик стал использовать IDEA?

В уровень подготовки программиста и сложность используемых инструментов.

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

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

G>А где здесь отвественности, которые стоило бы разделить?

Парсинг XML, алгоритм преобразования, генерация выходного потока. Тоже самое как и случае с компилятором: парсинг, преобразования, генерация.

G>Применять здесь SRP абсолютно незачем.

В данном примере это очевидно и мне и тебе, да и всем остальным.

G>>>Немного растет объем и немного увеличивается слжность чтения, но сильно уменьшается сложность изменения. Крмое того выделенные классы могут более удачно повторно использоваться, что приведет еще и к сокращению объема кода.
IT>>Немного растёт, классы могут. Главное, что сложность модификации растёт, т.е. гибкость кода страдает.
G>С чего ты взял что сложность модификации растет?

Ну сам немного подумай. В приведённом примере нужно добавить только одну строчку, а после применения SRP много больше чем одну.

G>Правильное прмиенение SRP уменьшает связность между различным функционалом, что позволяет вносить изменения в одном месте не беспокоясь что что-то сломается в другом.

Правильность — это оптимальное внесение сложности применяемым инструментом. Т.е. правильность — это как раз следствие, которое мне сейчас обсуждать не интересно.

G>Видиимо увеличивается только в случае неправильного применения SRP.

Но ведь увеличивается?

IT>>Ещё не понятно? Тогда ещё раз. Применение (абсолютно) любого инструмента ведёт к усложнению кода и совокупный эффект является большим вопросом.
G>Это пока еще не удалось доказать. даже с примерами такого туговато.

Т.е. теперь ты уже не согласен со своим предыдущим утверждением? SRP не добавляет сложности?

IT>>'Только в случае' для меня достаточно. Дело в том, что случаи бывают разные и главная проблема в том, что не все из них очевидны. Чем выше сложность системы, тем менее очевидны такие случаи. SRP в этом смысле как раз очень показательный принцип. Когда нужно остановиться, где та грань, после которой применение паттерна или принципа даёт обратный эффект? У тебя есть точная метрика?
G>Есть, прямо из определения SRP — когда один компонент отвечает за один аспект функционала.

В моём примере с XML -> TXT SRP можно применить во всей красе. В результате мы получим три компонента: парсер XML, модуль преобразования, генератор TXT. В результате твоя точная метрика даст усложнение кода в разы.

IT>>Всегда и не нужно. Лично мне достаточно того, что я понимаю одну простую вещь — любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот. На практике это означает критическое отношение к любому (абсолютно) паттерну или принципу. Даже к полюбившимся в этой ветке упорядочиванию и абстрагированию, т.к. упорядочивание и абстрагирование всегда в 100% случаях автоматически ведёт к усложнению, а вот для достижения упрощения ещё нужно попотеть.
G>Применение паттерна или принципа только ради его применения ведет к усложнению. Если головой понимаешь зачем применять, то получишь упрощение.

Правильно. А где граница между ведёт к усложнению или получишь упрощение?

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

VGn>Аналогия суждения: "использование автомобиля всегда ведёт к дополнительным затратам, потому что в соседний ларёк ездить за пивом на авто не эффективно"

Ты не согласен с такой своей аналогией?

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

IO>>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".

G>Это вообще говоря неверно. напрмиер сделать учетную систему в 1C гораздо проще, чем написать её на ассемблере (вместе с БД).

Всё верно. Твой пример как раз хорошо показывает зависимость сложности кода от сложности используемых инструментов.

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

IO>>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".

VGn>Моделирование всегда снижает сложность. Иначе это не моделирование.

Ты опять начинаешь разговаривать с телепатами.

Хорошая и важная статья. Только мне кажется что некоторые читатели могут после прочтения сделать неверные выводы, и решить что раз сложность никуда не девается, то и делать ничего не нужно. Тем не менее это неверно. Со сложностью надо бороться и всегда стараться свести ее к минимуму. Макконнелл в своей книге называет управление сложностью — главным техническим аспектом разработки ПО:

Важность управления сложностью

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

Управление сложностью — самый важный технический аспект разработки ПО. По-моему, управление сложностью настолько важно, что оно должно быть Главным Техническим Императивом Разработки ПО.

Сложность — не новинка в мире разработки ПО. Один из пионеров информатики Эдсгер Дейкстра обращал внимание на то, что компьютерные технологии — единственная отрасль, заставляющая человеческий разум охватывать диапазон, простирающийся от отдельных битов до нескольких сотен мегабайт информации, что соответствует отношению 1 к 109, или разнице в девять порядков (Dijkstra, 1989).
Такое гигантское отношение просто ошеломляет. Дейкстра выразил это так: «По сравнению с числом семантических уровней средняя математическая теория кажется почти плоской. Создавая потребность в глубоких концептуальных иерархиях, компьютерные технологии бросают нам абсолютно новый интеллектуальный вызов, не имеющий прецедентов в истории». Разумеется, за прошедшее с 1989 г. время
сложность ПО только выросла, и сегодня отношение Дейкстры вполне может характеризоваться 15 порядками. Дейкстра пишет, что ни один человек не обладает интеллектом, способным вместить все детали современной компьютерной программы (Dijkstra, 1972), поэтому нам — разработчикам ПО — не следует пытаться охватить всю программу сразу. Вместо этого мы должны попытаться организовать программы так, чтобы можно было безопасно работать с их отдельными фрагментами по очереди. Целью этого является минимизация объема программы, о котором нужно думать в конкретный момент времени. Можете считать это своеобразным умственным жонглированием: чем больше умственных шаров программа заставляет поддерживать в воздухе, тем выше вероятность того, что вы уроните один из них и допустите ошибку при проектировании или кодировании.
На уровне архитектуры ПО сложность проблемы можно снизить, разделив систему на подсистемы. Несколько несложных фрагментов информации понять проще, чем один сложный. В разбиении сложной проблемы на простые фрагменты и заключается цель всех методик проектирования ПО. Чем более независимы подсистемы, тем безопаснее сосредоточиться на одном аспекте сложности в конкретный момент времени. Грамотно определенные объекты разделяют аспекты проблемы так, чтобы вы могли решать их по очереди. Пакеты обеспечивают такое же преимущество на более высоком уровне агрегации.
Стремление к краткости методов программы помогает снизить нагрузку на интеллект. Этому же способствует написание программы в терминах проблемной области, а не низкоуровневых деталей реализации, а также работа на самом высоком уровне абстракции.
Суть сказанного в том, что программисты, компенсирующие изначальные ограничения человеческого ума, пишут более понятный и содержащий меньшее число ошибок код.

Как бороться со сложностью?
Чаще всего причинами неэффективности являются:
— сложное решение простой проблемы;
— простое, но неверное решение сложной проблемы;
— неадекватное сложное решение сложной проблемы.

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

Кстати, думаю что стоит обратить внимание и на сложность требований, приводящих к резкому увеличению сложности разрабатываемого ПО. Считается, что увеличение сложности задачи на 25% приводит к усложнению программного решения на 100% (Факты и заблуждения профессионального программирования (с) Роберт Гласс):

Факт 21
Увеличение сложности задачи на 25% приводит к усложнению программного решения на 100%, Это не условие, которое можно попытаться изменить (хотя сложность всегда желательно свести к минимуму), это реальное положение дел.

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

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

VGn>ИМХО приведённое выше определение немногим менее, чем полностью описывает твою статью. Так сказать умообразные заключения.

А, по-моему, тебе завидно, что сам так написать не можешь, вот и пытаешься чужой труд с дерьмом смешать.

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

IT>

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

IT>Надеюсь это успокоит формалистов и направит обсуждение в более продуктивное русло.

Ну, так назови статью адекватным образом. Например, "Виды сложности и преобразования между ними", или "Видя сложности и как с ними бороться", или "Заметки о том как бороться со сложностью".

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

IO>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".

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

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

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

IT>>Надеюсь это успокоит формалистов и направит обсуждение в более продуктивное русло.

VD>Ну, так назови статью адекватным образом. Например, "Виды сложности и преобразования между ними", или "Видя сложности и как с ними бороться", или "Заметки о том как бороться со сложностью".

Тогда пропадёт вся интрига.

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

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

G>>А где здесь отвественности, которые стоило бы разделить?

IT>Парсинг XML, алгоритм преобразования, генерация выходного потока. Тоже самое как и случае с компилятором: парсинг, преобразования, генерация.
И так все разделено? Объекты xml и file отвечают за парсинг и генерацию соотвественно, а сам метод за проеобразования.

G>>Применять здесь SRP абсолютно незачем.
IT>В данном примере это очевидно и мне и тебе, да и всем остальным.
Тогда к чему пример был?
Вроде как цель была показать пример где применение SRP увеличивает сложность.

G>>>>Немного растет объем и немного увеличивается слжность чтения, но сильно уменьшается сложность изменения. Крмое того выделенные классы могут более удачно повторно использоваться, что приведет еще и к сокращению объема кода.
IT>>>Немного растёт, классы могут. Главное, что сложность модификации растёт, т.е. гибкость кода страдает.
G>>С чего ты взял что сложность модификации растет?

IT>Ну сам немного подумай. В приведённом примере нужно добавить только одну строчку, а после применения SRP много больше чем одну.
Не нужно там применение SRP в принципе. В прмиере нету отвественностей которые надо разделять.
Все рассуждения идут от неверной посылки, следовательно сами рассуждения вполне могут быть неверными.

G>>Правильное прмиенение SRP уменьшает связность между различным функционалом, что позволяет вносить изменения в одном месте не беспокоясь что что-то сломается в другом.
IT>Правильность — это оптимальное внесение сложности применяемым инструментом. Т.е. правильность — это как раз следствие, которое мне сейчас обсуждать не интересно.
Правильность — соответсвие инструмента задаче. В приведенном выше коде не возникает задачи разделять отвественности, они там и так разделены, поэтому и инструмент применять не надо.
А изменение сложности как раз следствие.

G>>Видиимо увеличивается только в случае неправильного применения SRP.
IT>Но ведь увеличивается?
Любую программу можно написать плохо, давайте теперь дакажем что не стоит применять ни один паттерн, ООП и вообще писать надо только на ассемблере.

IT>>>Ещё не понятно? Тогда ещё раз. Применение (абсолютно) любого инструмента ведёт к усложнению кода и совокупный эффект является большим вопросом.
G>>Это пока еще не удалось доказать. даже с примерами такого туговато.

IT>Т.е. теперь ты уже не согласен со своим предыдущим утверждением? SRP не добавляет сложности?
Не добавляет.

IT>В моём примере с XML -> TXT SRP можно применить во всей красе. В результате мы получим три компонента: парсер XML, модуль преобразования, генератор TXT. В результате твоя точная метрика даст усложнение кода в разы.
Покажи в коде как это будет.
Сейчас есть:

void ConvertXmlToFile(xml, file)
{
    file.Put(xml.Get("123"));
}

объект xml — занимается парсингом, file — выводом, а сама функция — преобразование.
Что тут можно от чего отделить и какой код в результате будет?

IT>>>Всегда и не нужно. Лично мне достаточно того, что я понимаю одну простую вещь — любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот. На практике это означает критическое отношение к любому (абсолютно) паттерну или принципу. Даже к полюбившимся в этой ветке упорядочиванию и абстрагированию, т.к. упорядочивание и абстрагирование всегда в 100% случаях автоматически ведёт к усложнению, а вот для достижения упрощения ещё нужно попотеть.
G>>Применение паттерна или принципа только ради его применения ведет к усложнению. Если головой понимаешь зачем применять, то получишь упрощение.

IT>Правильно. А где граница между ведёт к усложнению или получишь упрощение?
Граница в правильном применении. Определение выше.

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

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

IO>>>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".

G>>Это вообще говоря неверно. напрмиер сделать учетную систему в 1C гораздо проще, чем написать её на ассемблере (вместе с БД).

IT>Всё верно. Твой пример как раз хорошо показывает зависимость сложности кода от сложности используемых инструментов.

От этого сложность самой задачи не меняется.

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

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

IO>>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".

VD>На то она и модель чтобы быть проще оригинала. Так что твое утверждение не верно. Верно будет утверждать, что модель должна быть проще оригинала. И если это не так, то это превышении необходимого уровня сложности.

Ладно, попробую уточнить.

1. Есть обьект — как правило его сложность бесконечна, если он не абстрактен.
2. Есть моделируемый аспект обьекта — сложность ниже.
3. Есть модель моделируемого аспекта обьекта — сложность еще ниже.
4. Есть реализация модели — вот тут минимальная сложность равна п.3 (именно ето я имел ввиду). Нужно стремится к такой минимальной сложности. В идеале — инструмент позволяет задать реализацию в тех же терминах и тем же способом, которым сформулирована модель.

VD>Сложность же кода действительно должна быть минимально необходимой для решения задачи. Кстати, не все задачи являются моделированием. Это перекос вызванный засильем ООП в умах масс. Многие задачи являются задачами трансформации. Их, как не странно, куда больше чем задач моделирования. В прочем, трансформировать можно модели.

Наверно с самого начала лучше было написать про _решение_ и его минимальную сложность. И сложность кода не ниже сложности решения.

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

IO>1. Есть обьект — как правило его сложность бесконечна, если он не абстрактен.
IO>2. Есть моделируемый аспект обьекта — сложность ниже.
IO>3. Есть модель моделируемого аспекта обьекта — сложность еще ниже.
IO>4. Есть реализация модели — вот тут минимальная сложность равна п.3 (именно ето я имел ввиду). Нужно стремится к такой минимальной сложности. В идеале — инструмент позволяет задать реализацию в тех же терминах и тем же способом, которым сформулирована модель.
Неверно, так как реализация зависит от технических средств, которые могут упростить решение до тривиального.
Например средства бизнес-аналитики, как MS SSAS, позволяют строить реализацию экономических моделей очень простым способом.
Тогда как при программировании на ЯП общего назначения создать такую модель будет чрезвычайно сложно.