P.S.-1 (текст ниже немного корявый, частично собран из кусков записок)
Сложность определяется не только архитектурой, но и оформлением этой архитектуры.
Хотя отделить одно от другого сложно, но условно можно. По крайней мере единственный способ изучить прграмму, это чтение кода, в том числе структура файлов проекта, навигация по коду инструментами разработки. С разными UML диаграммами проблема в том что это не программный код, а какие-то витания в облаках.
А для оформления есть важный аспект (но естейственно не единственный) — инкапсуляция.
Многие вопросы сложности сводятся к инкапсуляции. Особенно по части сложности восприятия, изучения кода.
Инкапсуляция, в одной из интерпретаций, это по сути введение ограничений, уменьшение степеней свободы.
Програмный код можно условно,приближенно считать это — множество данных и множество операций над данными.
И данные и операции организованы иерархически.Все это хозяйство является каким-то направленным иерархическим графом.
Один из важнейших типов направленных связей между элементами это — зависимости.
Т.е. если один элемент испортить, удалить, какие элементы посыпятся, перестанут компилироваться.
Важный момент, что зависимости(и другие типы связей) бывают:
— Текущие.Существующие в данный момент, в текущей версии,стадии разработки системы.
— Будущие, которые вероятнее всего появятся(потребуются) в дальнейшем
— Потенциальные. Они могут никогда вобще не потребоваться, но явных запретов,ограничений на их образование нет. Явно неограниченные ненужные связи являются вредоносными.
Связи между элементами описываются интерфейсами (не ключевое слово в C#) а в более широком смысле.
Интерфейсы бывают входящие и исходящие.
Интерфес в таком понимании, это описание способов использования одного элемента другим. Описание в каком угодно виде.
Вышесказанное это все довольно очевидные вещи,изложить их можно лучше или хуже и разными словами ....
Но хотел сказать по поводу инкапсуляции вот что:
----------
При изучении кода, происходит идентификация неявной структуры программы, со всеми иерархическими уровнями элементов и их зависимостями.
Современные средства разработки(и языковые и инструменты разработки), пока не достаточно помогают в оформлении кода (или создании дополнительных аспектов представления) таким образом чтобы можно было быстро идентифицировать структуру программы. Есть class,interface, сборки и ключевое слово internal. Но этого мало.В языке возможно уже нечего добавить, но что-то нужно со стороны средств разработки. Автоматическое построение диаграм классов это только игрушка.
---------
(Зависимости от стандартной библиотеки .NET игнорируем, по понятным причинам.)
— Если программист хорошо знаком с программой. Значит если его спросить "Что будет если удалить
вот эту функцию". Сколько функций и классов после этого перестанут компилироваться.
Если рекурсивно удалить все что не компилируется. Вопрос что тогда останется.
А если не знаком с программой, то как можно быстро ознакомиться с этим аспектом (даже сам писатель кода через определенное время станет менее знаком)?
Без хорошей среды разработки это сложно и долго.
— Или взять большой кусок кода (папку с кучей фалов или namespace). Как можно покоцать, удалить весь код за пределами этого куска, чтобы этот кусок компилировался и остался работоспособным.
Если нет понимания по таким вопросом относительно конкретной программы(проекта), вносить изменения и добавления становится довольно затруднительным.
В связи с этим есть такие проблемы:
1) Если образуются естейственные крупные инкапсуляции.
Программисты ленятся оформлять правильным образом (выделять в явном виде, накладывать ограничения).На момент написания в этом может не быть необходимости, потому что и так по памяти структура хорошо помнится.
2) Создание и оформление инкапсуляции вызывает определенные накладные расходы. В зависимости от величины элемента эти расходы,механизмы накладывания ограничений и описания интерфейса, могут быть разные.
Например некоторые виды инкапсуляции:
1)Инкапсуляция по-маленькому(один из вариантов)
Если в классе довольно сложная private функция реализуется с помощью 3-4 других вспомогательных private функций, если эти функции в классе больше нигде не используются. То разумно все это заключить в #region
С именем,например Func,encapsulation . Нестрогое объявление исходящего интерфеса, указывающее что за пределами #region видна только Func. Это только соглашение, но было бы неплохо если бы среда делала бы проверки, и выдавала предупреждения когда пытаются залезть внутрь. В стандарт языка это вносить нет смысла. Понятно что при пересечении определенной критической точки уже лучше будет вынести эту функцию в отдельный класс,возможно nested.
2)Инкапсуляцию на уровне класса пропустим.
3) Инкапсуляция по-среднему:
Реализация одного класса сложная, и для этого требуется 3-4 вспомогательных класса.Причем для других целей, другими классами, они никогда не будут использоваться. Просто так реализовать проще и понятнее, а использовать хуже, потому что эти ненужные классы будут мешаться. Проблема не в том что засоряют пространство имен, и в intelisence дольше функции искать, а в том что ухудшают адекватное восприятие структуры программы. Когда это принимает массовый характер, это губительно.
Один из способов — главный класс сделать partial. В одной части(файле) интерфейсная реализация. В других частях класса реализуются эти вспомогательные как private nested. Для большей адекватности, создать отдельную папку. В ней лежит файл с классом и папка internal где лежат вспомогательные классы. Но не совсем удобно бывает лазить по папкам с одним файлом и одной поддиректорией. Хорошо бы чтобы среда показывала такие папки в виде специальной иконки,похожей на файл, при клике на нее бы открывался этот один файл, а при раскрытии папки сразу в ней показывалось бы содержимое internal. И чтобы можно было переключить ее к виду нормальной папки и обратно... Можно namespace отдельный для вспомогательных классов, с добавкой internal.
4) Инкапсуляция по-крупному (или промежуточный вариант с предыдущим пунктом).
В основном для достаточно крупных,сложных кусков кода, поддающихся инкапсуляции по своей природе(не все куски такие).
Особенно для какой-то подсистемы, части являющейся единым целым, а не сборкой независимых утилит.
Например MS Excel — класс создатель + объектная модель. Но Excel это уж слишком крупная и явная инкапсуляция.
Но то же касается и более простых случаев, даже кусков кода 1000-3000 строк.
Использовать для этого отдельную dll сборку и защищать внутренности через internal во многих случаях неприемлемо и невозможно, и создает dll dependency hell. Проблема в том что эти сборки однонаправленное дерево, а между реальными элементами могут быть взаимные ссылки. Для особых случаев можно создать абстрактную сборку, и зависимости только от нее, чтобы разрулить циклические ссылки, но на каждые 1000 отдельную сборку не создашь.
В этом случае помещается такой кусок кода в отдельную папку [Elem]. В папке [Elem]\internal находится 95% или больше кода по числу строк. Вводится неявное соглашение содержимое [Elem]\internal доступно только из папки [Elem]. Все взаимодействие идет через входящий и исходящий интерфейс. Этот интерфейс находится в файлах в самой папке [Elem].
За попытки пробраться к коду в [Elem]\internal из внешних для [Elem] папок нещадно бить по рукам.
Хорошо бы если бы среда это контролировала, выдавала ошибки, чтобы была уверенность.
Бывает необходима и обратная(исходящая) изоляция содержания [Elem]\internal от внешнего мира (стандартные библиотеки .NET не являются внешним миром, по понятным причинам). Также нещадно бить по рукам за попытки пробраться наружу из internal наверх за пределы [Elem].
Если очень надо наверх, делаются исключения, но они явно описываются
в специальном файле [Elem]\OutgoingInterface.txt (или Uses.txt).
Либо даже для наружных элементов которые нужн,ы пишутся Wrapper'ы и помещаются в [Elem] (в нее доступ разрешен из internal).
Если Wrapper'ы не слишком трудоемкие и позволяют исключить часть ненужного функционала.
В самой папке [Elem] код сведен к минимуму. В основном Wraper'ы над тем что в internal.
Ну и естейственно [Elem]\Description.txt — где подробное описание всего элемента, с тонкостями и граблями.
Вот уж где комментарии наиболее полезны, так это на таких крупных скоплениях кода. А то бывает поналепят комментариев на каждую функцию или класс,а на более крупных скоплениях вобще ничего.Как будто их и нет. Типа, кто исходники сможет изучить тот поймет есть ли в коде вобще какие-то осмысленные крупные скопления, или полная каша из небольших классов и функций, или это большой массив независимых функций и классов.
Хорошо бы для таких конструкций поддержку со стороны среды — помечать такие папки особой иконкой и возможность включить исходящие и входящие ограничения (изоляцию), с выдачей ошибок при нарушениях, учитывая содержимое uses.txt. С возможностью отключить и включить этот режим.
Еще раз повторю что, ИМХО, через разделение на dll сборки такие проблемы не получиться решить в общем случае.
Самого языка и компилятора командной строки это скорее всего не касается, это дело среды.
---------
P.S.1 Можно сколько угодно рисовать красивые UML и прочие диаграмки. Но это просто живопись, если в самой среде разработки это все в виде каши и пущено на самотек.
P.S.2 Задачи и программы конечно бывают разные. Не для всех одинаково полезны одни и те же подходы. Когда одному или нескольким человекам нужно вмешиваться в код объемом 15-100 тыс строк, и сама система сильно связанная(по своей сути). И каждый должен понимать все детали в коде, и рефакторинг постоянный, то это одна ситуация.
Если кто-то слепил какой-то движок, потом толпы программистов шлепают под него независимые однотипные примочки в виде какой-то бизнес логики или чего-то похожего,в огромных количествах.Тогда это уже немного другая ситуация.
Здравствуйте, Lloyd, Вы писали: L>Здравствуйте, gandjustas, Вы писали:
L>Тут не термодинамика, тут любой процесс можно повернуть вспять и очень легко — окрываешь сорсконтрол и делаешь Revert Changes. И если в ревизии 101 у тебя при прочих равных сложность выше, чем в ревизии 100, то откатившись на 100-ю ревизию получишь уменьшение сложности, которого по мнению автора статьи "не существует".
И тут не математика, такое ощущение, что пытаешься представить каждую фразу в виде исчисления предикатов такого-то порядка.
Да и автор не говорил, что "не существует".
Это плохо работает, когда мы пытаемся заранее выделить код, который по идее можно повторно использовать, но на практике его повторно использовать не получается.
Если хочешь чтобы все сходилось с формальной точки зрения. Введи понятия(характеристики сложности):
Всякая сложность состоит из двук компонент:
Сложность = Объективная сложность + исскуственная(избыточная сложность,неумышленная обфускация)
всем очевидно что для функции int Sqr(int x){return x*x;} Можно до бесконечности увеличить сложность.Так что ни один программист за сутки не сможет доказать что она в квадрат возводит, разве что только экспериментально проверить...
И при этом не выполнится условие в одном месте выиграешь в другом проиграешь (и следствие в одном месте проиграешь значит в другом выиграешь). Но обективная компонента сложности останется неизменной (рост только за счет искусственной).
Существуют разные реализации одного и того же, в которых после устранения искусственной сложности, получаются ситуации когда в одном месте выигрываешь в другом проигрываешь (только по отношению оставшейся объективной сложности).
Вот можешь к каждому предложению автора где упоминается сложность добавлять префикс "объективная". Если бы обсуждался вопрос защиты программ и разные методы умышленной обфускации кода( какого нибудь JavaScript,чтоб никто не ковырялся). Тогда бы интересовала совсем другая компонента сложности.
Здравствуйте, Silver_s, Вы писали:
S_>Всякая сложность состоит из двук компонент: S_>Сложность = Объективная сложность + исскуственная(избыточная сложность,неумышленная обфускация)
S_>...Вот можешь к каждому предложению автора где упоминается сложность добавлять префикс "объективная"...
ЗдОрово! Тоже хотел отписать, что статья отличная, просто терминология местами, на мой взгляд, не удачная.
Сам автор использует префикс "изначальная", что можно понимать как сложность исходной версии (до рефакторинга и т.п.) кода, уже реализующего функционал. Так что любой рефакторинг приводит просто к перераспределению этой сложности в этом коде с возможным вынесением этой сложности в головы программистов (с выполнением закона сохранения) .
Я хотел предложить префикс "имманентная" для обозначения сложности, присущей самой задаче (она же будет минимальной возможной суммарной сложностью ее решения). И префикс "привнесенная" для обозначения того, что вызвано средствами, используемыми для решения задачи (включая мозги конкретного разработчика, который ее решал ).
Сохраняется именно "имманентная" составляющая общей сложности решения задачи.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Ikemefula, Вы писали:
I>>Времени нужно потратить столько что бы запихнуть задачу в долговременную память, это у каждого человека по своему. на качество воспроизведения влияет предыдущий опыт и последующий.
IT>Это как?
Это называется ретроактивная интерференция. Т.е. события в настоящем влияют на хранимую информацию в памяти.
I>>Кстати, идея про метапрограммирование это попытка прыгнуть выше головы, когда решение бОлее верхнего уровня не дается в нужный срок, девелопер сбрасывает сложность в обратно из головы в код в надежде что код удастся лучше контролировать. Т.е. метапрограммирование — контролируемый хаос. Но все таки хаос а не порядок.
IT>Мы об одном и том же метапрограммировании говорим?
IT>>>Задачи, легко поддающиеся декомпозиции не являются алгоритмически сложными именно по причине возможности их декомпозиции. Но бывают и другие задачи, требующие для своего решения построения полной модели в голове. И если, допустим, за два часа такую модель не построишь, то отставив задачу на день приходится всё опять строить заново.
VGn>>В этом случае проблема обычно решается введением дополнительного уровня абстракции, что опять же доступно именно интелекту
IT>В каком в этом? В каком-то твоём частном случае? Возможно, я даже спорить не буду.
Приведи пример задачи, которую нельзя декомпозировать на одном либо на разных уровнях абстракции.
IT>>>Сложность само по себе одно и тоже — затраченные усилия VGn>>Перевожу — "энтропия и энергия это одно и то же".
IT>Где такой переводчик взял?
Энтропия — мера упорядоченности системы. Не возникает ассоциаций?
Затраченные усилия -> затраченная работа -> затраченная энергия — это и дураку понятно.
Сложно?
VGn>>Статья основана на предпосылках что сложность складывается, вычитается и делится арифметически.
IT>Ты не внимательно её читал. Статья как раз основана на том, что сложность нельзя оценивать количественно.
Но в тоже время основной посыл — "не фиг с ней бороться, она всё равно никуда не девается"
VGn>>Я например уверен, что при упорядочивании общая энтропия кода уменьшается, а значит закон сохранения сложности — полная чушь.
IT>А что такое упорядочивание?
Наведение порядка
Структурирование.
VGn>>Так что софистика ваша статья.
IT>
IT>В широком смысле термин «софист» означал искусного или мудрого человека.
IT>Ты это имел ввиду?
Софистика — сознательное применение в споре или в доказательствах неправильных доводов, так называемых софизмов — всякого рода уловок, замаскированных внешней, формальной правильностью. Характерными приемами софистики являются вырывание событий из их связи с другими, применение закономерностей одной группы явлений к явлениям другой группы, одной исторической эпохи к событиям другой эпохи и т.д.
Здравствуйте, VGn, Вы писали:
VGn>>>Статья основана на предпосылках что сложность складывается, вычитается и делится арифметически. IT>>Ты не внимательно её читал. Статья как раз основана на том, что сложность нельзя оценивать количественно. VGn>Но в тоже время основной посыл — "не фиг с ней бороться, она всё равно никуда не девается"
Это уже второй раз подряд, когда ты пытаешься нагло переврать смысл написанного. Мне не понятно, ты плохо читал, ничего не понял или тебе просто по сути сказать нечего, а поговорить очень хочется?
VGn>>>Я например уверен, что при упорядочивании общая энтропия кода уменьшается, а значит закон сохранения сложности — полная чушь.
IT>>А что такое упорядочивание?
VGn>Наведение порядка VGn>Структурирование.
Ну да. SRP упорядочивает код или не упорядочивает?
IT>>В широком смысле термин «софист» означал искусного или мудрого человека.
IT>>Ты это имел ввиду?
VGn>Софистика — сознательное применение в споре или в доказательствах неправильных доводов, так называемых софизмов — всякого рода уловок, замаскированных внешней, формальной правильностью. Характерными приемами софистики являются вырывание событий из их связи с другими, применение закономерностей одной группы явлений к явлениям другой группы, одной исторической эпохи к событиям другой эпохи и т.д.
VGn>Знать надо термины, а не выдумывать их значения.
Ты за нас не переживай. Термины мы знаем и главное, умеем их правильно применять, чему тебе не мешало бы поучиться. А то я так и не понял к чему ты тут софистику упомянул. Пришлось даже обращаться к историческому смыслу термина.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VGn, Вы писали:
VGn>>>В этом случае проблема обычно решается введением дополнительного уровня абстракции, что опять же доступно именно интелекту IT>>В каком в этом? В каком-то твоём частном случае? Возможно, я даже спорить не буду. VGn>Приведи пример задачи, которую нельзя декомпозировать на одном либо на разных уровнях абстракции.
Например, добавление генерации отладочной информации в компилятор. Необходимо протянуть её от парсера до кодо-генератора через все преобразования, ничего не сломав и сохранив все детали. Давай, вводи абстракцию.
Если нам не помогут, то мы тоже никого не пощадим.
VGn>>Энтропия — мера упорядоченности системы. Не возникает ассоциаций?
IT>Продолжай.
упорядоченность
синоним: порядок, система
антоним: хаотичность
(Wiki)
сложный
3. Трудный для рассмотрения или разрешения, запутанный.
(словарь Ушакова)
VGn>>Затраченные усилия -> затраченная работа -> затраченная энергия — это и дураку понятно.
IT>А дураку понятно в каких килоджоулях сравнивать сложность обучения и сложность восприятия плохоотформатированного кода?
А то ты не вспотел?
Кстати заметь, опять с усилий на сложность перескочил. Как бы невзначай.
IT>Например, добавление генерации отладочной информации в компилятор. Необходимо протянуть её от парсера до кодо-генератора через все преобразования, ничего не сломав и сохранив все детали. Давай, вводи абстракцию.
Где здесь модель?
Думается, у тебя большие сложности с отделением сущностей от действий.
VGn>>Софистика — сознательное применение в споре или в доказательствах неправильных доводов, так называемых софизмов — всякого рода уловок, замаскированных внешней, формальной правильностью. Характерными приемами софистики являются вырывание событий из их связи с другими, применение закономерностей одной группы явлений к явлениям другой группы, одной исторической эпохи к событиям другой эпохи и т.д.
VGn>>Знать надо термины, а не выдумывать их значения.
IT>Ты за нас не переживай. Термины мы знаем и главное, умеем их правильно применять, чему тебе не мешало бы поучиться. А то я так и не понял к чему ты тут софистику упомянул. Пришлось даже обращаться к историческому смыслу термина.
ИМХО приведённое выше определение немногим менее, чем полностью описывает твою статью. Так сказать умообразные заключения.
Здравствуйте, VGn, Вы писали:
VGn>>>Энтропия — мера упорядоченности системы. Не возникает ассоциаций?
IT>>Продолжай.
VGn>упорядоченность VGn> синоним: порядок, система VGn> антоним: хаотичность VGn>(Wiki) VGn>сложный VGn>3. Трудный для рассмотрения или разрешения, запутанный. VGn>(словарь Ушакова)
Ну да. И что? В огороде бузина, а в Киеве дядька?
VGn>>>Затраченные усилия -> затраченная работа -> затраченная энергия — это и дураку понятно.
IT>>А дураку понятно в каких килоджоулях сравнивать сложность обучения и сложность восприятия плохоотформатированного кода?
VGn>А то ты не вспотел?
Я то тут при чём? Тебе понятно или нет? Или вопрос требует слишком конкретного для тебя ответа?
Тебе нужно в соседней теме с DG пообщаться. Он пытается измерять сложность в вариантах, а ты в колоджоулях. Вы должны найти с ним много общего.
VGn>Кстати заметь, опять с усилий на сложность перескочил. Как бы невзначай.
Почитай статью. Только повнимательнее, там в первых же абзацах написано.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VGn, Вы писали:
IT>>Например, добавление генерации отладочной информации в компилятор. Необходимо протянуть её от парсера до кодо-генератора через все преобразования, ничего не сломав и сохранив все детали. Давай, вводи абстракцию.
VGn>Где здесь модель?
Как это где? Весь компилятор и есть модель.
VGn>Думается, у тебя большие сложности с отделением сущностей от действий.
Вообще-то мы здесь говорим не о сущностях и не о дейтсвиях, а о программировании и решении конкретных задач с помощью программирования. Ты предложил мне привести пример задачи, я тебе её привёл. Теперь твоя очередь, давай, применяй свои любимые абстракции.
Если нам не помогут, то мы тоже никого не пощадим.
VGn>>>Софистика — сознательное применение в споре или в доказательствах неправильных доводов, так называемых софизмов — всякого рода уловок, замаскированных внешней, формальной правильностью. Характерными приемами софистики являются вырывание событий из их связи с другими, применение закономерностей одной группы явлений к явлениям другой группы, одной исторической эпохи к событиям другой эпохи и т.д.
VGn>>>Знать надо термины, а не выдумывать их значения.
IT>>Ты за нас не переживай. Термины мы знаем и главное, умеем их правильно применять, чему тебе не мешало бы поучиться. А то я так и не понял к чему ты тут софистику упомянул. Пришлось даже обращаться к историческому смыслу термина.
VGn>ИМХО приведённое выше определение немногим менее, чем полностью описывает твою статью. Так сказать умообразные заключения.
Понятно. В принципе, когда по сути сказать нечего, а поговорить очень хочется, то можно ещё дальше зайти.
А про умообразные заключения — надо будет запомнить. Это как раз очень хорошо подходит одному любителю абстракций, который в этой теме много говорил, но пока не сказал ничего конкретного.
Если нам не помогут, то мы тоже никого не пощадим.
IT>>>Например, добавление генерации отладочной информации в компилятор. Необходимо протянуть её от парсера до кодо-генератора через все преобразования, ничего не сломав и сохранив все детали. Давай, вводи абстракцию.
VGn>>Где здесь модель?
IT>Как это где? Весь компилятор и есть модель.
Ну так ты его уже и без меня начал декомпозировать. Надо просто не бояться
VGn>>Думается, у тебя большие сложности с отделением сущностей от действий.
IT>Вообще-то мы здесь говорим не о сущностях и не о дейтсвиях, а о программировании и решении конкретных задач с помощью программирования. Ты предложил мне привести пример задачи, я тебе её привёл. Теперь твоя очередь, давай, применяй свои любимые абстракции.
Оттолкнулись мы от фразы
Но бывают и другие задачи, требующие для своего решения построения полной модели в голове.
Здравствуйте, Lloyd, Вы писали: L>>>Следовательно, если мы не будем пытаться "заранее выделить код", то взамен ничего не потеряем, сложность уменьшим. G>>Противоположность увеличения сложности — неувеличение, а не строгое уменьшение. Поэтой при нулевых поползновениях сложность не изменится.
L>Тут не термодинамика, тут любой процесс можно повернуть вспять и очень легко — окрываешь сорсконтрол и делаешь Revert Changes. И если в ревизии 101 у тебя при прочих равных сложность выше, чем в ревизии 100, то откатившись на 100-ю ревизию получишь уменьшение сложности, которого по мнению автора статьи "не существует".
Это плохо работает, когда мы пытаемся заранее выделить код, который по идее можно повторно использовать, но на практике его повторно использовать не получается.
А вобще в таких случаях("заранее выделить код") приходится принимать интуитивное решение на основе разумного баланса между противоречиями. Причем противоречия принципиальные неустранимые да еще и в условиях неопределенности.
Есть две поговорки "Быстрее едешь дальше будешь", "Тише едешь дальше будешь" обе из них правильные. Примеры думаю не нужны.
Есть высказывания в XP "Никогда не делай сегодня то, что может потребоваться только завтра". Но это такая же метафорическая поговорка.
При принятии решения о "заранее выделить код" на завтра приходится учитывать.
1) Если при выборе одного из двух решений, потом в случае неудачного выбора откат назад слишком трудоемкий (в сумме труды на первый вариант + переделка на второй). Тогда тут 10 раз надо сначала подумать.
2) Надо пытаться предсказать что потребуется завтра, если пункт 1 заставляет. Причем надо оценить не только вероятности того насколько подойдет вариант, но и сложность создания обоих вариантов, а также перевода одного варианта в другой.Но ясновидцев нет. Только эмпирические интуитивные прогнозы можно делать. И бывает когда они не делаются.
3) Надо учитывать что бывают случаи, если что-то не сделаешь сегодня, то завтра на это уже в 5 раз больше усилий затратишь.
Если например у такой фичи слабая связность. int Sqr(unt x){return x*x;}
Если есть подозрения на 50% что потом потребуется более универсальный вариант. Например не в квадрат возводить, а в вещественную степень. То глупо это делать сегодня, подождать пока понадобится.
А если писал фичу две недели, и есть подозрения на 50% что потом к ней потребуется добавка которую 1 час писать, а если отложить на 2 недели, то потребуется 8 часов чтобы ту же добавку написать (переключение контекста).
Если подсчитать матожидание затрат (как бы не смешно звучало) : в первом случае 1 час, во втором 0.5*8
В реальности матожидания рассчитывать невозможно, слишком много факторов, с постоянно меняющимися стоимостями,вероятностями и прочими... Только интуитивные оценки остаются в ральных ситуациях. А в теории можно только обозначить разные факторы, чтоб знать где вобще копать.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, VGn, Вы писали:
VGn>>>>Энтропия — мера упорядоченности системы. Не возникает ассоциаций?
IT>>>Продолжай.
VGn>>упорядоченность VGn>> синоним: порядок, система VGn>> антоним: хаотичность VGn>>(Wiki) VGn>>сложный VGn>>3. Трудный для рассмотрения или разрешения, запутанный. VGn>>(словарь Ушакова)
IT>Ну да. И что? В огороде бузина, а в Киеве дядька?
Немного о месте ассоциативного подхода в лексике Ассоциативное мышление
VGn>>>>Затраченные усилия -> затраченная работа -> затраченная энергия — это и дураку понятно.
IT>>>А дураку понятно в каких килоджоулях сравнивать сложность обучения и сложность восприятия плохоотформатированного кода?
VGn>>А то ты не вспотел?
IT>Я то тут при чём? Тебе понятно или нет? Или вопрос требует слишком конкретного для тебя ответа?
Это шутка о тепловыделении, если не понял.
IT>Тебе нужно в соседней теме с DG пообщаться. Он пытается измерять сложность в вариантах, а ты в колоджоулях. Вы должны найти с ним много общего.
Ну вот. Теперь ты мне ставишь в вину именно ту логическую ошибку, которую я поставил в вину тебе. Замечательно.
VGn>>Кстати заметь, опять с усилий на сложность перескочил. Как бы невзначай.
IT>Почитай статью. Только повнимательнее, там в первых же абзацах написано.
Здравствуйте, VGn, Вы писали:
VGn>>>Где здесь модель?
IT>>Как это где? Весь компилятор и есть модель. VGn>Ну так ты его уже и без меня начал декомпозировать.
Совершенно верно, он уже и без тебя докомпозирован.
VGn>Надо просто не бояться
Вот и не бойся, давай, давай. Меньше слов — больше дела. Применяй свои абстракции.
VGn>Оттолкнулись мы от фразы
Для того, чтобы вырывать фразы из контекста ума много не надо. Надо совсем мало ума. Ты лучше сообрази как предложенную задачу декомпозировать.
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
