Здравствуйте, IT, Вы писали:
IT>Я думал об этом и пока не могу однозначено разделить две вещи: уровень интеллекта и способность удерживать в голове целиком задачу определённого размера. Мне кажется это суть одно и тоже, но, возможно, я не прав. Было бы интересно обсужить эти вещи подробнее.
Интеллект может справиться со сложной задачей в основном только путем декомпозиции. Поэтому не нужно стремиться удерживать в голове целиком задачу большого размера. Но это в теории, а на практике только этим и приходится заниматься
Здравствуйте, goldblueranger, Вы писали:
G>Законы сохранения действуют в обоих направлениях, соответственно, если бы такой закон был, то при искусственном увеличении сложности в реализации какой-то функции, сложность чего-то другого уменьшалась бы.
Если бы такой закон был, то его уже давно открыли бы и без нас с вами. Это и так понятно. В статье как раз написано, давайте условно назовём это законом сохранения сложности. С другой стороны исскуственное усложнение на пустом месте тоже не происходит. Искуственное увеличение сложности в реализации какой-то функции, происходит за счёт уменьшения усилий при её написании, т.е. чем меньше сложности в мозгах, тем сложнее получаемый код
G>Или я что-то не понял?
Всё примерно так.
G>А вообще респект за тему — управление сложностью — самое важное в разработке.
Именно это и хочется обсудить, а уж как там это назвать дело десятое.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, goldblueranger, Вы писали:
IT>>Я думал об этом и пока не могу однозначено разделить две вещи: уровень интеллекта и способность удерживать в голове целиком задачу определённого размера. Мне кажется это суть одно и тоже, но, возможно, я не прав. Было бы интересно обсужить эти вещи подробнее.
G>Интеллект может справиться со сложной задачей в основном только путем декомпозиции. Поэтому не нужно стремиться удерживать в голове целиком задачу большого размера. Но это в теории, а на практике только этим и приходится заниматься
Задачи, легко поддающиеся декомпозиции не являются алгоритмически сложными именно по причине возможности их декомпозиции. Но бывают и другие задачи, требующие для своего решения построения полной модели в голове. И если, допустим, за два часа такую модель не построишь, то отставив задачу на день приходится всё опять строить заново. В результате такие подходы к снаряду не заканчиваются ни чем. Требуется полное погружение на 8-10 часов в течении нескольких дней. А после того, как такую задачу удаётся продавить модель разрушается и в голове мало что остаётся.
Понятное дело, что таких задач не много, но периодически они попадаются. Так вот мне интересно, чем именно обусловлен предел. Скоростными возможностями мозгов при построении модели, размером модели или чем-то другим? Ответ на этот вопрос даст лучшее понимание природы алгоритмической сложности, позволит отбросить лишнее и сконцентрироваться на главном.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>Этот рефакторинг выполняется автоматически и занимает минимум времени. Гораздо больше займет собственно понимание что делает код.
IT>Это зависит от кода. Можно так написать, что простой в понимании код вообще не будет читаться, а его рефакторинг займёт гораздо больше времени, чем его понимание. В общем, без конкретного кода я не стал бы даже это обсуждать.
Если код не был специально запутан, то рефакторинг в той же студии выполняется достаточно быстро.
G>>Так что для "восприятия" нужно "обучение".
IT>Возможно термин восприятие не очень удачен, но в моём определении важно как раз то, что он отделён от обучения и относится к форме кода, а не его содержанию. Если у тебя есть более точное определение предлагай.
Тогда подходящий термин "чтение", а "обучение" надо заменить "пониманием".
О самом обучении, те преодолении порога вхождения, ниже.
IT>>>Сложность обучения придётся преодолевать каждому новому бойцу в команде, для которого порог вхождения в код выше его текущего предела. G>>Это еще более редкое явление.
G>>Преодоление этих сложностей требует гораздо меньших затрат по сравнению с преодолением сложности изменений при постоянном развитии проекта.
IT>Опять же это всё зависит от конкретного рассматриваемого случая. В моей команде используется всё, что сегодня доступно на рынке мэйнстрима: последние версии компиляторов и их новые возможности, последние технологии и т.д. Это позволяет нам перераспределить сложность наших проектов в сложность обучения и контролировать наш код малым числом людей. Я не возьму на работу человека далёкого от всего этого, например, такого, который застыл на уровен .NET 1.1. Не возьму по простой причине — затраты на его обучение не будут, как ты утверждаешь, меньше по сравнению с преодолением других видов сложности. Они будут значительно больше, и если это будет контрактник на 10 месяцев, то за это время он не успеет сделать ничего полезного.
Тут другой фактор играет роль. Пока человек не обучен всем применяемым средствам он не сможет участовать в проекте. Тода как сложность изменения практически не будет зависить от качеств человека.
Всетаки стоит сделать разделение на сложность объективную (например вызванную высокой связностью системы или применяемыми алгоритмами) и субъективную (например знание технологий конкретными людьми).
Статья основана на предпосылках что сложность складывается, вычитается и делится арифметически.
Поробуйте к примеру рассмотреть сложность на исходных данных задачи коммивояжёра (экстремальный случай).
Я например уверен, что при упорядочивании общая энтропия кода уменьшается, а значит закон сохранения сложности — полная чушь.
Ток что софистика ваша статья.
IT>Сложность само по себе одно и тоже — затраченные усилия
Перевожу — "энтропия и энергия это одно и то же".
Да энтропия и энергия связаны напрямую, но говорить, что это одно и то же — полный бред.
IT>Задачи, легко поддающиеся декомпозиции не являются алгоритмически сложными именно по причине возможности их декомпозиции. Но бывают и другие задачи, требующие для своего решения построения полной модели в голове. И если, допустим, за два часа такую модель не построишь, то отставив задачу на день приходится всё опять строить заново.
В этом случае проблема обычно решается введением дополнительного уровня абстракции, что опять же доступно именно интелекту
IT>Я думал об этом и пока не могу однозначено разделить две вещи: уровень интеллекта и способность удерживать в голове целиком задачу определённого размера. Мне кажется это суть одно и тоже, но, возможно, я не прав. Было бы интересно обсужить эти вещи подробнее.
Да вроде просто все — уровень интеллекта ограничивает время за которое ты сможешь взместить в голову всю задачу.
Т.е. вопрос в том, успеет ли кандидат модифицировать у себя в голове модель некоей системы (задачу) в режиме реального времени или же ему придется докупать где то время.
Всю статью можно свести к одной фразе — "Сложность — понятие сложное". Утверждение, бесспорно, верное. Но его практическая применимость лично для меня под вопросом.
IT>Задачи, легко поддающиеся декомпозиции не являются алгоритмически сложными именно по причине возможности их декомпозиции. Но бывают и другие задачи, требующие для своего решения построения полной модели в голове. И если, допустим, за два часа такую модель не построишь, то отставив задачу на день приходится всё опять строить заново. В результате такие подходы к снаряду не заканчиваются ни чем. Требуется полное погружение на 8-10 часов в течении нескольких дней. А после того, как такую задачу удаётся продавить модель разрушается и в голове мало что остаётся.
IT>Понятное дело, что таких задач не много, но периодически они попадаются. Так вот мне интересно, чем именно обусловлен предел. Скоростными возможностями мозгов при построении модели, размером модели или чем-то другим? Ответ на этот вопрос даст лучшее понимание природы алгоритмической сложности, позволит отбросить лишнее и сконцентрироваться на главном.
Времени нужно потратить столько что бы запихнуть задачу в долговременную память, это у каждого человека по своему. на качество воспроизведения влияет предыдущий опыт и последующий. Задачи решаются в кратковременной паамяти, куда влазит 5+-2 составляющих (в некоем формализме).
Чем сильнее были прокачаны интеллектуальные функции(анализ — синтез, абстракция — конкретика, сравнение — сопоставление, обобщение — классификация, кодирование — декодирование) тем проще удерживать в голове модель.
Грубо говоря, уровень прокачки это уровень формализма в котором ты можешь описать задачу, например
0 установить i равным длине списка минус один, взять i-элемент, если признак равен ...
1 в цикле проверять каждый элемент списка и в случае чего удалять нахрен
2 фильтровать список по некоему признаку или так
3 мега-опэрация(мега-объект)
итого — предел времени зависит от прокачки, скорости изменения прокачки, масштаба задачи и скорости расхода этого времени на задачу.
Кстати, идея про метапрограммирование это попытка прыгнуть выше головы, когда решение бОлее верхнего уровня не дается в нужный срок, девелопер сбрасывает сложность в обратно из головы в код в надежде что код удастся лучше контролировать. Т.е. метапрограммирование — контролируемый хаос. Но все таки хаос а не порядок.
Здравствуйте, VGn, Вы писали:
VGn>Статья основана на предпосылках что сложность складывается, вычитается и делится арифметически.
Ты не внимательно её читал. Статья как раз основана на том, что сложность нельзя оценивать количественно.
VGn>Поробуйте к примеру рассмотреть сложность на исходных данных задачи коммивояжёра (экстремальный случай).
Давай конкретную реализацию задачи, поговорим о сложности/простоте её реализации.
VGn>Я например уверен, что при упорядочивании общая энтропия кода уменьшается, а значит закон сохранения сложности — полная чушь.
А что такое упорядочивание?
VGn>Ток что софистика ваша статья.
Из вики
В широком смысле термин «софист» означал искусного или мудрого человека.
Ты это имел ввиду?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VGn, Вы писали:
IT>>Задачи, легко поддающиеся декомпозиции не являются алгоритмически сложными именно по причине возможности их декомпозиции. Но бывают и другие задачи, требующие для своего решения построения полной модели в голове. И если, допустим, за два часа такую модель не построишь, то отставив задачу на день приходится всё опять строить заново.
VGn>В этом случае проблема обычно решается введением дополнительного уровня абстракции, что опять же доступно именно интелекту
В каком в этом? В каком-то твоём частном случае? Возможно, я даже спорить не буду.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Vamp, Вы писали:
V>Всю статью можно свести к одной фразе — "Сложность — понятие сложное". Утверждение, бесспорно, верное. Но его практическая применимость лично для меня под вопросом.
Применимость нужно рассматривать на конкретном коде. В принципе, можно взять какую-нибудь задачу посложнее и рассмотреть.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ikemefula, Вы писали:
I>Времени нужно потратить столько что бы запихнуть задачу в долговременную память, это у каждого человека по своему. на качество воспроизведения влияет предыдущий опыт и последующий.
Это как?
I>Кстати, идея про метапрограммирование это попытка прыгнуть выше головы, когда решение бОлее верхнего уровня не дается в нужный срок, девелопер сбрасывает сложность в обратно из головы в код в надежде что код удастся лучше контролировать. Т.е. метапрограммирование — контролируемый хаос. Но все таки хаос а не порядок.
Мы об одном и том же метапрограммировании говорим?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
G>Если часто надо переключаться между проектами, то это хреновый менеджемнт и сложности не относится.
+1
Хочется добавить, что частое переключение между проектами,
свойственно "командам с низким уровнем обучения" (как они упомянуты в статье).
Для однодневных простеньких проектов, данный подход способен принести положительный результат,
но как дело выходит за рамки 2*2=4, проявляется вся абсурдность данного подхода.
Здравствуйте, gandjustas, Вы писали:
T>>В общем случае, это неверно. Лично я забываю всякую ерунду очень быстро, и, как следствие, приходится помногу раз вникать в один и тот же проект. Соответственно, чем выше порог вхождения, тем больше тратится ресурсов на "переключение контекста" между проектами.
G>Если часто надо переключаться между проектами, то это хреновый менеджемнт и сложности не относится.
Если нам не помогут, то мы тоже никого не пощадим.
