Reason to change? Ты понимаешь смысл слова reason или тебе перевести?
IT>>Для меня, например, алгоритм разбора xml, алгоритм преобразования и алгоритм генерации текста — это разные ответственности. Для тебя, как я понимаю, — нет. G>С чего ты взял? это разные отвественности и они уже реализуются разными компонентами, объект xml отвечает за разбор xml_я, file за генерацию текста, а сам метод Convert за преобразование.
С того и взял. Для меня компонент xml и file — это способы доступа к конкретному формату, а не алгоритм разбора и генерации конкретных данных в моеё бизнес логике. Точно такие же компоненты у меня есть и для компилятора. Впрочем, мы начинаем ходить по кругу, что означает бессмысленность дальнейшей дискуссии.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Каких, чего? Конкретней, пожалуйста, для каждого вида сложности. Нам понадобятся количественные характеристики для определения (я начну, а ты продолжай):
IT>- объёма кода, видимо количество строк или мегабайт.
Байт, инструкций.
IT>- сложности обучения
Надо взвешивать инструменты (библиотеки, языковые елементы). Наверно сначала вручную...
IT>- сложности восприятия кода, даже не знаю что предложить, DG пытался здесь притулить количество вариантов рассмотрения.
Частично — производное от предыдуших.
Также наличие нелинейных выражений со множеством инструкций. Структуру дерева "нелинейного выражения" сложно упаковать.
IT>- алгоритмической сложности, DG говорил о количестве вариантов поведения кода.
В общем случае тяжело...
IT>- гибкости
Dependency?..
IT>- сложности понимания поставленной задачи (ещё один вид, который я бы выделил в отдельный).
Статья уже о решениях.
Сначала ваш спор не читал, так шо сори если не в тему.
Здравствуйте, IO, Вы писали:
IO>Байт, инструкций. IO>Надо взвешивать инструменты (библиотеки, языковые елементы). Наверно сначала вручную... IO>Частично — производное от предыдуших. IO>Также наличие нелинейных выражений со множеством инструкций. Структуру дерева "нелинейного выражения" сложно упаковать. IO>В общем случае тяжело... IO>Dependency?..
IO>Сначала ваш спор не читал, так шо сори если не в тему.
Теперь нужно научиться всё это теплое и мягкое между собой сравнивать. Есть идеи?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, thesz, Вы писали:
IT>>>Ну давай попробуем найти твою количественную меру. Мы её тут в соседней ветке с DarkGray уже месяц ищем. В основном занимаемся сравнением мягкого с тёплым и пушистым. T>>Честное слово, я в этом не виноват. IT>Ну извини что так получилось. Так будем искать количественную меру или будем заниматься демагогией?
Волен ли я сделать выбор?
IT>>>>>Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста. T>>>>Взвешенная сумма? Полином? IT>>>Сумма чего? T>>Количественных характеристик? IT>Каких, чего? Конкретней, пожалуйста, для каждого вида сложности. Нам понадобятся количественные характеристики для определения (я начну, а ты продолжай): IT>- сложности восприятия кода, даже не знаю что предложить, DG пытался здесь притулить количество вариантов рассмотрения.
Время на одну полезную строку после приведения к стандарту кодирования?
IT>- алгоритмической сложности, DG говорил о количестве вариантов поведения кода.
Количество возможных мест, где мы можем ошибиться с выбором варианта решения?
IT>- объёма кода, видимо количество строк или мегабайт.
Полезные строки кода.
IT>- сложности обучения
Обучение чему? Квантуем это "чего" и получаем метрику "время на единицу чего".
IT>- гибкости
Даёшь удовлетворительное определение гибкости, квантуешь, получаешь метрику гибкости.
А можешь выбросить из рассмотрения, пока не найдёшь.
IT>- сложности понимания поставленной задачи (ещё один вид, который я бы выделил в отдельный).
Зависит от метрики сложности задачи и скорости понимания (которая у всех разная).
IT>Интересны количесвенные характеристики каждого вида и функции, с помощью которых их можно было бы привести к единой мере для дальнейших манипуляций.
Это исследование надо проводить, на это я пойтить не могу.
Но в результате всё сведётся к прогнозу времени.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
IT>>Ну извини что так получилось. Так будем искать количественную меру или будем заниматься демагогией?
T>Волен ли я сделать выбор?
Да ради бога, только выбор не очень большой.
IT>>- сложности восприятия кода, даже не знаю что предложить, DG пытался здесь притулить количество вариантов рассмотрения. T>Время на одну полезную строку после приведения к стандарту кодирования?
Не знаю что он понимал под рассмотрением, но как минимум тут возникает сразу два вопроса: что такое полезная строка и что такое стандарт кодирования? Как они формализуются?
IT>>- алгоритмической сложности, DG говорил о количестве вариантов поведения кода. T>Количество возможных мест, где мы можем ошибиться с выбором варианта решения?
Критерий ошибочности? Два разных алгоритма можгут безошибочно решать одну и ту же задачу, только один будет простым, другой сложным.
IT>>- объёма кода, видимо количество строк или мегабайт. T>Полезные строки кода.
Опять же критерий полезности.
IT>>- сложности обучения T>Обучение чему? Квантуем это "чего" и получаем метрику "время на единицу чего".
Чего — например, ООП. Можно квантануть до наследования, инкапсуляция, полиморфизм. Какова будет метрика?
IT>>- гибкости T>Даёшь удовлетворительное определение гибкости, квантуешь, получаешь метрику гибкости.
Гибкость — сложность модификации кода. Как будем квантовать?
T>А можешь выбросить из рассмотрения, пока не найдёшь.
Не-не-не. Не надо ничего выбрасывать, надо наоборот добавлять.
IT>>- сложности понимания поставленной задачи (ещё один вид, который я бы выделил в отдельный). T>Зависит от метрики сложности задачи и скорости понимания (которая у всех разная).
Разная у всех не только сложность понимания, но ещё и обучаемость и предел алгоритмической сложности. Это всё тоже нужно как-то включать в формальное определение.
IT>>Интересны количесвенные характеристики каждого вида и функции, с помощью которых их можно было бы привести к единой мере для дальнейших манипуляций. T>Это исследование надо проводить, на это я пойтить не могу.
А зря.
T>Но в результате всё сведётся к прогнозу времени.
Время — это хорошо, но надо подумать. Есть моменты.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IO, Вы писали:
IO>Из "закона сохранения сложности" следует, что сложность при рефакторинге переходит из одного вида в другой. IO>Берем два варианта решения одной задачи и измеряем куда и сколько переместилось сложности. IO>Получим что-то типа "100 единиц сложности восприятия по статистике равно 300 единицам сложности обьема".
Ну то есть тёплое с мягким.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, IO, Вы писали:
IO>>Из "закона сохранения сложности" следует, что сложность при рефакторинге переходит из одного вида в другой. IO>>Берем два варианта решения одной задачи и измеряем куда и сколько переместилось сложности. IO>>Получим что-то типа "100 единиц сложности восприятия по статистике равно 300 единицам сложности обьема".
IT>Ну то есть тёплое с мягким.
Ну да, я же отвечал на вопрос "Теперь нужно научиться всё это теплое и мягкое между собой сравнивать."...
А что не так?
Здравствуйте, IT, Вы писали:
IT>Не знаю что он понимал под рассмотрением, но как минимум тут возникает сразу два вопроса: что такое полезная строка и что такое стандарт кодирования? Как они формализуются?
Берешь студию, запускаешь метрики и тебе показывается количество полезных строк.
ставишь fxcop+stylecop и получаешь нарушения "стандарта".
Потом делишь количество строк на кол-во нарушений и получаешь более менее нормальную метрику.
Также из студии можно использовать полезные вещи, такие как "цикломатическая сложность" и "свзяность классов".
Причем имеют смысл эти метрики на строку кода по всему проекту.
Вот эти 3 метрики + количество строк кода дают вполне пригодную оценку "качества кода", при минимизации метрик качество растет.
IT>>>- алгоритмической сложности, DG говорил о количестве вариантов поведения кода. T>>Количество возможных мест, где мы можем ошибиться с выбором варианта решения?
IT>Критерий ошибочности? Два разных алгоритма можгут безошибочно решать одну и ту же задачу, только один будет простым, другой сложным.
IT>>>- объёма кода, видимо количество строк или мегабайт. T>>Полезные строки кода. IT>Опять же критерий полезности.
IT>>>- сложности обучения T>>Обучение чему? Квантуем это "чего" и получаем метрику "время на единицу чего".
IT>Чего — например, ООП. Можно квантануть до наследования, инкапсуляция, полиморфизм. Какова будет метрика?
Связность.
IT>>>- гибкости T>>Даёшь удовлетворительное определение гибкости, квантуешь, получаешь метрику гибкости. IT>Гибкость — сложность модификации кода. Как будем квантовать?
Обратная величина к линейной функции от связности и цикломатической сложности при фиксированном объеме кода.
Гибкость падает при увеличении количества строк и константных других параметров.
IT>>>- сложности понимания поставленной задачи (ещё один вид, который я бы выделил в отдельный). T>>Зависит от метрики сложности задачи и скорости понимания (которая у всех разная). IT>Разная у всех не только сложность понимания, но ещё и обучаемость и предел алгоритмической сложности. Это всё тоже нужно как-то включать в формальное определение.
Субъективные факторы, типа сложности обучения, лучше не учитывать в формальных выкладках.
IT>>>Интересны количесвенные характеристики каждого вида и функции, с помощью которых их можно было бы привести к единой мере для дальнейших манипуляций. T>>Это исследование надо проводить, на это я пойтить не могу. IT>А зря.
Не очень получится, в зависимости от задачи одни метрики могут быть более приоритетные, чем другие.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, thesz, Вы писали:
IT>>>Ну извини что так получилось. Так будем искать количественную меру или будем заниматься демагогией? T>>Волен ли я сделать выбор? IT>Да ради бога, только выбор не очень большой.
Мне главное иметь возможность. За каковую большое спасибо.
IT>>>- сложности восприятия кода, даже не знаю что предложить, DG пытался здесь притулить количество вариантов рассмотрения. T>>Время на одну полезную строку после приведения к стандарту кодирования? IT>Не знаю что он понимал под рассмотрением, но как минимум тут возникает сразу два вопроса: что такое полезная строка и что такое стандарт кодирования? Как они формализуются?
PSP/TSP, спец Влад Балин aka Gaperton.
Давай условимся, на некоторое время, что мы работаем со вполне определёнными людьми, у которых выработаны определённые критерии совместной работы и характеристики которых мы знаем. В частности, у них есть стандарт кодирования.
От группы к группе он может отличаться, но внутри группы он постоянен.
Полезная строка кода — это строка кода, в которой может быть ошибка после компиляции программы. Для фиксированного стандарта кодирования производительность программиста в полезных строках кода достаточно стабильна.
IT>>>- алгоритмической сложности, DG говорил о количестве вариантов поведения кода. T>>Количество возможных мест, где мы можем ошибиться с выбором варианта решения? IT>Критерий ошибочности? Два разных алгоритма можгут безошибочно решать одну и ту же задачу, только один будет простым, другой сложным.
Ну вот как ты определишь "один простой, а другой сложный"?
По-моему, в сложном алгоритме проще ошибиться.
Вот число 21 в виде числа Пеано:
S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))))))))))
Если мы его сложим с числом S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S Z)))))))))))))))))))), то получим S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S(S (S (S (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))))))))))))))))))))))))))))))) или 42.
Запись чисел Пеано сложна для чтения. И их сложность растёт с ростом чисел — в числе 42 41 скобка, а в 21 — 20.
Если помимо Z и S мы соберёмся добавить ещё какой-либо конструктор, получится, что вероятность ошибиться (просто опечататься) в конструкторе будет пропорциональна длине (абсолютной величине) числа.
Зато сложение очень просто:
type family NPlus a b
type instance NPlus Z b = b
type instance NPlus (S a) b = S (NPlus a b)
Для двоичной позиционной записи чисел код сложения длинней в несколько раз. Читать же двоичные числа много проще.
Поэтому числа Пеано требуют практики.
Вот и размен: для Пеано проще доказывать теоремы, работать же лучше с позиционной системой счисления. Обычные программисты предпочитают второе, HOT программисты — первое. "Integers are for sissies!" (C) ироничный J. Shapiro, создатель BitC.
IT>>>- объёма кода, видимо количество строк или мегабайт. T>>Полезные строки кода. IT>Опять же критерий полезности.
Чуть выше.
IT>>>- сложности обучения T>>Обучение чему? Квантуем это "чего" и получаем метрику "время на единицу чего". IT>Чего — например, ООП. Можно квантануть до наследования, инкапсуляция, полиморфизм. Какова будет метрика?
Самое простое — подход а-ля IQ. Создаём большой список вопросов по теме, от простых до сложных, проводим тесты. Метрика понимания — количество отвеченных вопросов за определённое время. Можно ввести вес вопросов.
IT>>>- гибкости T>>Даёшь удовлетворительное определение гибкости, квантуешь, получаешь метрику гибкости. IT>Гибкость — сложность модификации кода. Как будем квантовать?
По-моему, гибкость обратно пропорциональна сложности модификации.
Тем не менее. Сложность — количество мест, где мы можем ошибиться. Большой код сложен, короткий и запутанный код также сложен. Модификация — изменение кода для решения задачи. Получается, что чем сложней модификация, тем выше количество ошибок на решение задачи.
Соответственно, гибкость будет обратно пропорциональна количеству ошибок на решение задачи.
T>>А можешь выбросить из рассмотрения, пока не найдёшь. IT>Не-не-не. Не надо ничего выбрасывать, надо наоборот добавлять.
Это не мой подход.
IT>>>- сложности понимания поставленной задачи (ещё один вид, который я бы выделил в отдельный). T>>Зависит от метрики сложности задачи и скорости понимания (которая у всех разная). IT>Разная у всех не только сложность понимания, но ещё и обучаемость и предел алгоритмической сложности. Это всё тоже нужно как-то включать в формальное определение.
То есть, скорость понимания снижается от уровня сложности задачи. Это можно связать.
IT>>>Интересны количесвенные характеристики каждого вида и функции, с помощью которых их можно было бы привести к единой мере для дальнейших манипуляций. T>>Это исследование надо проводить, на это я пойтить не могу. IT>А зря.
Я разработчик, не когнитивный исследователь.
T>>Но в результате всё сведётся к прогнозу времени. IT>Время — это хорошо, но надо подумать. Есть моменты.
Это единственный невосполнимый ресурс.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
IT>>>>- сложности понимания поставленной задачи (ещё один вид, который я бы выделил в отдельный). T>>>Зависит от метрики сложности задачи и скорости понимания (которая у всех разная). IT>>Разная у всех не только сложность понимания, но ещё и обучаемость и предел алгоритмической сложности. Это всё тоже нужно как-то включать в формальное определение.
T>То есть, скорость понимания снижается от уровня сложности задачи. Это можно связать.
Скорость понимания условий задачи? Просто,ИМХО, две большие разницы — сложность условий задачи и сложность решения.
Бывают задачи простые,краткие, с недвусмысленными условиями.Но с очень сложным решением.
А бывает наоборот, описание задачи намного длиннее и сложнее чем решение. (не обязательно от заказчика, но и какие-то локальные подзадачи)
Сложность понимания условий задачи мерять в секундах тяжеловато. ИМХО, легче ее мерять в количестве букв в тексте на естейственном языке (не ЯП), необходимых чтобы ее достаточно точно описать.
Я вот тут попытался дать способ вычисления одного показателя на эту тему: http://www.rsdn.ru/forum/philosophy/3487882.1.aspx
Он якобы имеет какое-то отношение к инкапсуляции...
Вот когда в реализации системы(задачи) образуется много подсистем(подзадач) допускающих намного более краткое описание на человеческом языке, чем их реализяция на ЯП. То какая-то общая сложность снижается.Даже если реализация на ассемблере была, без стандартов на кодирование.Все равно при изучении такого кода это можно разглядеть.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, thesz, Вы писали:
IT>>>>>- сложности понимания поставленной задачи (ещё один вид, который я бы выделил в отдельный). T>>>>Зависит от метрики сложности задачи и скорости понимания (которая у всех разная). IT>>>Разная у всех не только сложность понимания, но ещё и обучаемость и предел алгоритмической сложности. Это всё тоже нужно как-то включать в формальное определение. T>>То есть, скорость понимания снижается от уровня сложности задачи. Это можно связать.
S_>Скорость понимания условий задачи? Просто,ИМХО, две большие разницы — сложность условий задачи и сложность решения.
Буду краток: что всё это значит?
S_>Бывают задачи простые,краткие, с недвусмысленными условиями.Но с очень сложным решением.
Пример?
S_>А бывает наоборот, описание задачи намного длиннее и сложнее чем решение. (не обязательно от заказчика, но и какие-то локальные подзадачи)
Пример?
S_>Сложность понимания условий задачи мерять в секундах тяжеловато. ИМХО, легче ее мерять в количестве букв в тексте на естейственном языке (не ЯП), необходимых чтобы ее достаточно точно описать.
S_>Он якобы имеет какое-то отношение к инкапсуляции... S_>Вот когда в реализации системы(задачи) образуется много подсистем(подзадач) допускающих намного более краткое описание на человеческом языке, чем их реализяция на ЯП.
За счёт чего? Правильно, за счёт контекста.
S_>То какая-то общая сложность снижается.Даже если реализация на ассемблере была, без стандартов на кодирование.Все равно при изучении такого кода это можно разглядеть.
Вообще не понял.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали: T>Здравствуйте, Silver_s, Вы писали: S_>>Здравствуйте, thesz, Вы писали:
S_>>Скорость понимания условий задачи? Просто,ИМХО, две большие разницы — сложность условий задачи и сложность решения. T>Буду краток: что всё это значит?
Это значит если тебя попросят написать коллекцию такую как Dictionart<TKey,TValue> но чтобы на один ключ много value можно было повесить.
Либо вторая задача. Реализовать интерфейс IList<T> но чтобы не в виде массива хранил, а связанным списком.С удалением любого элемента со сложностью O(1). И с поведением стандартного List<T>.
Думаю тебе одного этого предложения хватит(если .NET интересуешся) чтобы понять что требуется. 10-20 секунд. А провозишься с написанием гораздо дольше.
Если такие задачи возникнут, то есть возможность сплавить их на сторону. Поймать на улице первого встречного программиста сунуть ему задачу + оплату. И долго не объяснять куда это все будет встраиваться, ему это знать и не нужно.
S_>>Бывают задачи простые,краткие, с недвусмысленными условиями.Но с очень сложным решением. T>Пример?
Пример я там где то приводил. Написать функцию на входе .bmp с сайтов, где пишут введите код на картинке если вы человек а не web робот. На выходе строка которую нужно будет вводить.
S_>>А бывает наоборот, описание задачи намного длиннее и сложнее чем решение. (не обязательно от заказчика, но и какие-то локальные подзадачи) T>Пример?
Например есть у мяня полезный модуль A и еще один полезный модуль B. Нужно заставить их работать совместно. Переконвертировать какие-то данные выдаваемые из модуля A в формат который сможет пережевать модуль B. И чего-то там между ними синхронизировать.
А дальше длинная портянка текста на 400 строк с описанием интерфейсов этих модулей и форматов данных, протоколов обмена данными с ними.
В результате будешь сначала долго,долго изучать все эти протоколы, чтобы понять что и как нужно сделать. А потом напишешь код, ктороый возможно строчек на 50-100 всего будет.
S_>>Сложность понимания условий задачи мерять в секундах тяжеловато. ИМХО, легче ее мерять в количестве букв в тексте на естейственном языке (не ЯП), необходимых чтобы ее достаточно точно описать.
T>И что ты с этим потом будешь делать?
T>Правильно, приводить к оценке времени.
Ну,да, можно и к времени свести.
S_>>Я вот тут попытался дать способ вычисления одного показателя на эту тему: S_>>http://www.rsdn.ru/forum/philosophy/3487882.1.aspx
S_>>Он якобы имеет какое-то отношение к инкапсуляции... S_>>Вот когда в реализации системы(задачи) образуется много подсистем(подзадач) допускающих намного более краткое описание на человеческом языке, чем их реализяция на ЯП.
T>За счёт чего? Правильно, за счёт контекста.
За счет того что подзадачи можно раздать первым встречным, быстро проверить правильность их решения. И собрать все вместе.
Если что-то не работает, то искать ошибки уж не внутри реализации IList (приведенный выше). Если он тест прошел, про его внутренности можно забыть практически навсегда. Есть только класс реализующий этот IList а кода нету, сложность системы его использующей стала меньше.
Просто есть такой закон неофициальный чем меньшим количеством слов можно полностью(или почти) описать суть задачи, или способы работы с подсистемой,модулем. Тем легче протестировать ее правильность решения. И тем меньше проблем она потом будет создавать.
Собственно вопрос не в том, легче ли работать с системой поддающейся декомпозиции на подзадачи.Тут ответ очевидный.
А есть ли этот неофициальный закон, о минимальном числе слов на естейственном языке.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, thesz, Вы писали: T>>Здравствуйте, Silver_s, Вы писали: S_>>>Здравствуйте, thesz, Вы писали:
S_>>>Скорость понимания условий задачи? Просто,ИМХО, две большие разницы — сложность условий задачи и сложность решения. T>>Буду краток: что всё это значит? S_> Это значит если тебя попросят написать коллекцию такую как Dictionart<TKey,TValue> но чтобы на один ключ много value можно было повесить. S_> Либо вторая задача. Реализовать интерфейс IList<T> но чтобы не в виде массива хранил, а связанным списком.С удалением любого элемента со сложностью O(1). И с поведением стандартного List<T>.
Ты приводишь примеры там, где требуются объяснения.
S_>Думаю тебе одного этого предложения хватит(если .NET интересуешся) чтобы понять что требуется. 10-20 секунд. А провозишься с написанием гораздо дольше. S_> Если такие задачи возникнут, то есть возможность сплавить их на сторону. Поймать на улице первого встречного программиста сунуть ему задачу + оплату. И долго не объяснять куда это все будет встраиваться, ему это знать и не нужно.
Что всё это значит? Я не вижу связи между двумя этими параграфами самими по себе и между примерами перед этим.
S_>>>Бывают задачи простые,краткие, с недвусмысленными условиями.Но с очень сложным решением. T>>Пример? S_>Пример я там где то приводил. Написать функцию на входе .bmp с сайтов, где пишут введите код на картинке если вы человек а не web робот. На выходе строка которую нужно будет вводить.
Вся простота формулировки твоей задачи скрывается в контексте.
Выяви этот контекст, задача потеряет простоту формулировки. Либо приобретёт простоту реализации.
S_>>>А бывает наоборот, описание задачи намного длиннее и сложнее чем решение. (не обязательно от заказчика, но и какие-то локальные подзадачи) T>>Пример? S_>Например есть у мяня полезный модуль A и еще один полезный модуль B. Нужно заставить их работать совместно. Переконвертировать какие-то данные выдаваемые из модуля A в формат который сможет пережевать модуль B. И чего-то там между ними синхронизировать. S_> А дальше длинная портянка текста на 400 строк с описанием интерфейсов этих модулей и форматов данных, протоколов обмена данными с ними. S_> В результате будешь сначала долго,долго изучать все эти протоколы, чтобы понять что и как нужно сделать. А потом напишешь код, ктороый возможно строчек на 50-100 всего будет.
Вот, лишили задачу контекста, ввели его в формулировку. Задача стала сложной в формулировке.
Скорее всего, из-за избыточного контекста.
S_>>>Сложность понимания условий задачи мерять в секундах тяжеловато. ИМХО, легче ее мерять в количестве букв в тексте на естейственном языке (не ЯП), необходимых чтобы ее достаточно точно описать. T>>И что ты с этим потом будешь делать? T>>Правильно, приводить к оценке времени. S_> Ну,да, можно и к времени свести.
Ничего другого и не нужно. Время — это единственный невосполнимый ресурс, единственная реальная ценность.
S_>>>Я вот тут попытался дать способ вычисления одного показателя на эту тему: S_>>>http://www.rsdn.ru/forum/philosophy/3487882.1.aspx
S_>>>Он якобы имеет какое-то отношение к инкапсуляции... S_>>>Вот когда в реализации системы(задачи) образуется много подсистем(подзадач) допускающих намного более краткое описание на человеческом языке, чем их реализяция на ЯП. T>>За счёт чего? Правильно, за счёт контекста. S_> За счет того что подзадачи можно раздать первым встречным, быстро проверить правильность их решения. И собрать все вместе.
Ты опять перескакиваешь. Пожалуй, я откажусь от дальнейшей дискуссии.
S_>Если что-то не работает, то искать ошибки уж не внутри реализации IList (приведенный выше). Если он тест прошел, про его внутренности можно забыть практически навсегда. Есть только класс реализующий этот IList а кода нету, сложность системы его использующей стала меньше.
S_> Просто есть такой закон неофициальный чем меньшим количеством слов можно полностью(или почти) описать суть задачи, или способы работы с подсистемой,модулем. Тем легче протестировать ее правильность решения. И тем меньше проблем она потом будет создавать. S_> Собственно вопрос не в том, легче ли работать с системой поддающейся декомпозиции на подзадачи.Тут ответ очевидный. S_>А есть ли этот неофициальный закон, о минимальном числе слов на естейственном языке.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Вот, лишили задачу контекста, ввели его в формулировку. Задача стала сложной в формулировке. T>>>За счёт чего? Правильно, за счёт контекста. S_>> За счет того что подзадачи можно раздать первым встречным, быстро проверить правильность их решения. И собрать все вместе. T>Ты опять перескакиваешь. Пожалуй, я откажусь от дальнейшей дискуссии.
Ну пусть будет контекст, не возражаю.
Я собственно хотел сказать только о том что:
Один из критериев того что задачу удалось разбить на подзадачи. Это насколько трудоемко создать исчерпывающую документацию для подзадачи. Или исчерпывающие требования, если еще не разработано. Исчерпывающие — значит по одной такой документации и описанию контекста , "на стороне" смогут реализовать эту подзадачу. Реализовать так, чтобы эту подзадачу можно было встроить в основную задачу с минимальными исправлениями.
Вот если к документации(описанию требований) подзадачи, нужно прилагать контекст в виде исходников всей системы(не меньше).
То это тяжелый случай. Например, найди причину бага в системе, непонятно где возникающего. Смогут эффективно справиться, только те кто уже знаком с контекстом.
Но к контекстам,в принципе, применимы принципы наследования и повторного использования.
Если кому-то пришлось изучить .NET для одного проекта, он сможет эти знания(контекст) применить и для других проектов. Или какую-то библиотеку изучил потом, знания повторно использует...
Если группа разработчиков над одним проектом работает, уже они в каком-то общем контексте.
Но тем не менее, даже и для кода над которым работает один разработчик. Если в нем нет подзадач (либо невозможно,либо не захотел), которые возможно кратко(в сравнении с объемом кода) и исчерпывающе задокументировать с минимальным прилагаемым контекстом. То тяжело ему прийдется (в зависимости от объемов кода). Если при описании повторно запользует контекст, который или общий для большого числа разработчиков, либо общий для большого числа задач которые сам решал (но другие с этим контекстом могут быть и незнакомы). Тогда может все упроститья. Но количество этих контекстов не безгранично (в которых может ориентироваться один человек).
Я, кстати , не устанавливаю прямую связь между "возможность кратко,исчерпывающе задокументировать части программы". И тем хорошо ли написана программа и какая связность в ней.
Для массивов независимых модулей содержащих бизнесс логику. Хрошо,как раз, когда большое число бизнесс-правил заказчика упаковано в небольшое число строк кода. И кратко это никак не задокомунтируешь. Сам код бизнес правил это и есть краткая документация (если все хорошо сделано)
А если прийдется делать свою реализацию IList , то это плохо, похоже на велосипедостроение. Написание кода не относящегося к задаче. Или плохо просто то, что легко и кратко формулируемая задача, решается сложно и долго.
Но при повышении связности системы, количества повторного использования велосипедов, и еще чего-то...cитуация может поменяться на противоположную. К тому же в самой решаемой задаче может присутствовать потребность в велосипеде, не таком как уже есть.
Велисипедом это я называю условно потому что, задачи с краткими понятными концепциями, с простым использованием, но со сложной реализацией, уже как правило реализованы много раз. Если они полезны на практике.
Если пример хочется кроме IList. Возьмем систему рисования графиков, диаграмм. Наверно и не одну тысячу раз это делали. И не одна сотня продуктов есть. Но прийдется делать снова, если не найдется продукт в котором сойдутся все потребности.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, thesz, Вы писали:
T>>Вот, лишили задачу контекста, ввели его в формулировку. Задача стала сложной в формулировке. T>>>>За счёт чего? Правильно, за счёт контекста. S_>>> За счет того что подзадачи можно раздать первым встречным, быстро проверить правильность их решения. И собрать все вместе. T>>Ты опять перескакиваешь. Пожалуй, я откажусь от дальнейшей дискуссии.
S_> Ну пусть будет контекст, не возражаю. S_>Я собственно хотел сказать только о том что: S_>Один из критериев того что задачу удалось разбить на подзадачи. Это насколько трудоемко создать исчерпывающую документацию для подзадачи. Или исчерпывающие требования, если еще не разработано. Исчерпывающие — значит по одной такой документации и описанию контекста , "на стороне" смогут реализовать эту подзадачу.
Контекст не поддаётся описанию.
Он содержится в недомолвках разговора коллег.
S_>То это тяжелый случай. Например, найди причину бага в системе, непонятно где возникающего. Смогут эффективно справиться, только те кто уже знаком с контекстом.
S_> Но к контекстам,в принципе, применимы принципы наследования и повторного использования.
Это только к тем контекстам, что ты смог придумать.
Вот я тебя сейчас попрошу написать ядро системы моделирования цифровой аппаратуры, синхронного варианта с одной тактовой частотой.
Ты поковыряешься и что-то выдашь.
Теперь я попрошу написать ядро системы моделирования синхронной аппаратуры с несколькими тактовыми частотами.
Тебе придётся выбросить всё, что написал до этого и написать заново.
А теперь я попрошу включить в ядро поддержку комбинаторной логики.
И снова тебе придётся выбросить всё, что ты до этого написал.
Что самое интересное, если написать сразу ядро с поддержкой комбинационной логики, то оно будет мало подходяще для первых двух случаев.
А вроде одно в другое включается, в обе стороны.
S_>Если кому-то пришлось изучить .NET для одного проекта, он сможет эти знания(контекст) применить и для других проектов. Или какую-то библиотеку изучил потом, знания повторно использует...
Ты смотришь, в случае .Нет, на умеренно общий контекст. А в случае библиотеки — на узкий класс проектов.
Теперь выкинь из описания задачи нижележащий фреймворк, оставь только саму суть. И попробуй расширь класс проектов.
После чего посмотри, сможет ли тебе помочь .Net в решении задачи, и позволит ли помочь тебе знание библиотеки сторонним разработчиком.
S_>Если группа разработчиков над одним проектом работает, уже они в каком-то общем контексте.
Вот это здравая мысль.
S_>Но тем не менее, даже и для кода над которым работает один разработчик. Если в нем нет подзадач (либо невозможно,либо не захотел), которые возможно кратко(в сравнении с объемом кода) и исчерпывающе задокументировать с минимальным прилагаемым контекстом. То тяжело ему прийдется (в зависимости от объемов кода). Если при описании повторно запользует контекст, который или общий для большого числа разработчиков, либо общий для большого числа задач которые сам решал (но другие с этим контекстом могут быть и незнакомы). Тогда может все упроститья. Но количество этих контекстов не безгранично (в которых может ориентироваться один человек).
А это я снова не понял.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте thesz, Вы писали:
T>Контекст не поддаётся описанию. T>Он содержится в недомолвках разговора коллег.
Ну если это вводится по определению. Тогда для контекстов поддающихся описанию просто прийдется придумать другой термин.
S_>> Но к контекстам,в принципе, применимы принципы наследования и повторного использования. T>Это только к тем контекстам, что ты смог придумать.
Не хочу злоупотреблять термином контекст, когда он неопределен. При моделировании описанном ниже, даже если код не унаследуешь.
Опыт, знания все равно перенесешь от предыдущих вариантов...
T>Вот я тебя сейчас попрошу написать ядро системы моделирования цифровой аппаратуры, синхронного варианта с одной тактовой частотой. T>Теперь я попрошу написать ядро системы моделирования синхронной аппаратуры с несколькими тактовыми частотами. T>Тебе придётся выбросить всё, что написал до этого и написать заново. T>А теперь я попрошу включить в ядро поддержку комбинаторной логики. T>И снова тебе придётся выбросить всё, что ты до этого написал. T>Что самое интересное, если написать сразу ядро с поддержкой комбинационной логики, то оно будет мало подходяще для первых двух случаев. T>А вроде одно в другое включается, в обе стороны.
Если скажешь что перепрыгнул с вопроса о наследовании контекстов, на это вот все. Для меня в примеденном примере вопрос о наследовании контекстов десятый,двадцатый. Заначит в данном конкретном случае фтопку фразу "наследование контекстов" Философия, философией, а ....
Поскольку с моделями цифровой аппаратуры не знаком. Поэтому не совсем понимаю как можно добавить комбинаторную логику в модель оставив старую модель неизменной. Просто дописав какой-то "клей" который эти две штуки свяжет или как-то по-другому. Не знаю и какого объема(в человоко-днях и в строках кода) часть выбрасывается и переписывается заново. Куда больше времени тратится на написание кода или на что-то другое.Не знаю и сколько таких вариантов моделей нужно. Только 3 или 300 и ни одну повторно не получается использовать. Неизвестно насколько в этой задаче можно жертвовать производительностью(оптимизацией). Без этого оптимум не опредлить.Наверное именно оптимум нужен, а не просто повторно использовать какие-то строчки кода как самоцель.
Когда 300 штук похожих кусков, сократить их толщину почти всегда можно, чем-то пожертвовав. Для трех штук эти жертвы могут не оправданными.
T>А это я снова не понял.
Это можно и в мусорку.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте thesz, Вы писали:
T>>Контекст не поддаётся описанию. T>>Он содержится в недомолвках разговора коллег. S_>Ну если это вводится по определению. Тогда для контекстов поддающихся описанию просто прийдется придумать другой термин.
КОНТЕ'КСТ, а, м. [латин. contextus — сплетение, соединение] (филол.).
Связное словесное целое по отношению к входящему в него определенному слову или фразе. Надо взять фразу в контексте, и тогда она станет понятной.
Все контексты поддаются описанию.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
КОНТЕ'КСТ, а, м. [латин. contextus — сплетение, соединение] (филол.). T>Связное словесное целое по отношению к входящему в него определенному слову или фразе. Надо взять фразу в контексте, и тогда она станет понятной.
T>Все контексты поддаются описанию.
Когда сложные и общие термины(по словарю) часто применяют в конкретной области они немного другой смысл могут приобретать.
А теперь не о контекстах, а снова IDictionary<TKey,TValue> поскольку он широко известен. Да и вобще об интерфейсах.
Что есть этот IDictionary ? Он имеет конкретное в ЯП значение, список членов. И плюс соглашения что каждый член означает и какое поведение ожидается. Почти все подробно закомментировано в MSDN. Но не все. Например не сказано что если объект добавлен в IDictionary, то он не может изчезнуть, пока не будет удален (через один из базовых интерфесов), или сам перепрыгнуть на другой key.
Все описать невозможно, часть соглашений "переходит по наследству" от всего .NET, часть просто от здравого смысла программистов, и вобще от здравого смысла.
Это соглашение IDictionary появилось в .Net потому что это велосипед. Его легко изучить и запомнить, можно часто использовать для разных целей, и не очень просто реализовать. И реализовать можно по разному просто но не эффективно, сложно но эффективнее, оптимизированно под конкретный сценарий или под общийслучай.
Все эти соглашения это тоже контекст.
Контекст который образуется в конкретной задаче. Это уже локальный контекст в коде. "На уме" у программиста он может быть и не быть. Если есть, то может быть краткосрочным и долгосрочным (раз естейственная память такая). Краткосрочный он недолгий зато может быть на порядок больше по объему. ... и пошло и поехало...
Если нам не помогут, то мы тоже никого не пощадим.
