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

F>Я не специалист в измерении кода и багов в перерасчете на строки кода, однако, насколько я могу понять, речь идет о вносимых ошибках при написании кода. Дальнейшая отладка позволяет отловить и убрать ошибки (возможно с внесением новых) и постепенно сократить их вплоть до нуля.

Если так — тогда больше на правду похоже , только как тогда измерения проводились ? Врядли человек отдаст комунить неотлаженный и непроверенный код ?

Gaperton,

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

G>Охренеть. Вот ведь наука дошла. Ссылочку не дадите — я что-то не нашел .

Да зачем тебе ссылки-то? Опций — всего ничего: текстовое, графическое и бинарное Подозреваю, что оппонент намекает на графическое представление.

Gaperton,

-1
В знак искренней симпатии

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

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

КЛ>В первом примере объявлено 9 классов (интерфейс IFigure хоть и объявлен, но не используется — его не считаем). Эти классы используются для представления 3-х сущностей: прямоугольника, ромба и квадрата. Итого: 3 класса на сущность.

Те много интефейсов всегда хуже чем мало? Я правильно понял?

Например у меня есть подсистема в которой на 5 сущьностей приходится 10 интерфейсов. Это плохо? Мне надо срочно все рефакторить?

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

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

F>>Я не специалист в измерении кода и багов в перерасчете на строки кода, однако, насколько я могу понять, речь идет о вносимых ошибках при написании кода. Дальнейшая отладка позволяет отловить и убрать ошибки (возможно с внесением новых) и постепенно сократить их вплоть до нуля.

M>Если так — тогда больше на правду похоже , только как тогда измерения проводились ? Врядли человек отдаст комунить неотлаженный и непроверенный код ?

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

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

F>Пример прямо сегодня был — переписал код программиста (причем не стажера!) — экран кода (строк 20-30), находящегося в глубоко нерабочем состоянии заменил на 3 (три!) строки кода, которые сразу заработали верно (ну, сложно ошибиться в 3 строчках, правда?).

А за счёт чего происходит такое сокращение количества строк?

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

FDS>А за счёт чего происходит такое сокращение количества строк?

Например, вот такое:

if (a == true)
{
    return true;
}
else
{
    return false;
}

можно сократить в 8 раз:

return a;

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

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

FDS>>А за счёт чего происходит такое сокращение количества строк?

IT>Например, вот такое:

IT>

IT>if (a == true)
IT>{
IT>    return true;
IT>}
IT>else
IT>{
IT>    return false;
IT>}
IT>

IT>можно сократить в 8 раз:

IT>

IT>return a;
IT>

Ээээ. Я думаю, это бывает далеко не всегда

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

FDS>А за счёт чего происходит такое сокращение количества строк?
...
IT>return a;

FDS>Ээээ. Я думаю, это бывает далеко не всегда

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

1. человек просто не знает что в стандартной (или просто используемой) библиотеке уже есть готовый метод для нужного ему набора действий и воспроизводит его самостоятельно.
2. используют неподходящий в данном случае алгоритм, что выливается в более сложный и запутанный код.
3. Делают ошибку в самом начале где-то (взаимодействующие сущности или порядок обработки данных), а потом старательно выписывают страницы кода, обходя порожденные проблемы, считая что все идет нормально и даже не понимая, что надо вернуться к началу и исправить еще там...
4. Начинают оптимизировать код по мере написания, как только начинают подозревать, что "это будет медленно". Создают "быстрый" вариант. Потом трудолюбиво воюют с неудобствами этого варианта, создавая килобайты кода обходных маневров.

Когда такое вижу то часто поражаюсь "как же так вообще можно?", потом вспоминаю себя лет 5 назад и понимаю, что да, вполне можно...

Глядя на собственные исходники нескольколетней давности, понимаешь, что теперь Бог думает о мире...

Дорогой друг !
То что Вам поможет, называется Бритвой Оккамы ("не плодите сущности без необходимости")
И ей лет намного больше чем нам с вами. Так зачем плодить сущности в виде малополезных статей ?

Здравствуйте, minorlogic, Вы писали:
M>Если так — тогда больше на правду похоже , только как тогда измерения проводились ? Врядли человек отдаст комунить неотлаженный и непроверенный код ?
Не знаю, как обстоят дела в вашей компании, а у нас есть специальные люди, которым отдают неотлаженный и непроверенный код. Они называются QA, и их задача — проверить код и помочь в его отладке. В идеальной команде программист, конечно же, никогда не закоммитит непротестированный код в VCS. Но в реальной жизни а) программист не всегда идеален и б) у него банально может не хватить ресурсов для проверки всех граничных случаев. К примеру, есть кусок кода, который он коммитит. Его работоспособность по какой-то причине является платформенно-зависимой. Мы что, заставим его поднять локально 24 VM со всеми таргет-платформами и прогнать тестовые сценарии? Нет, он проверяет код на своей локальной платформе и выполняет коммит. Этот код будет проверен QA отделом в рамках значительно более длинных test sequences, и если он таки падает на какой-то другой платформе, то девелоперу вернется баг. Конечно, при починке девелопер будет проверять фикс как раз на той платформе, на которой баг был найден. Но опять же полный цикл тестирования проводить он не станет.

В итоге, мы имеем в багзилле массу информации о том, как качество кода эволюционирует в процессе разработки. Грамотные пацаны выполняют на этой статистике всякие исследования.

Если у вас к-во багов близко к заявленному , и отдается сырым тестерам , я не понимаю как у вас хоть что то работает ....

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

M>Если у вас к-во багов близко к заявленному , и отдается сырым тестерам , я не понимаю как у вас хоть что то работает ....
В каком смысле? Что такое "сырой тестер"? Почему непонятно, как хоть что-то работает?

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

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

M>>Если у вас к-во багов близко к заявленному , и отдается сырым тестерам , я не понимаю как у вас хоть что то работает ....
S>В каком смысле? Что такое "сырой тестер"? Почему непонятно, как хоть что-то работает?

Сырой код а не тестер, сырой это не готовый не отлаженный , тестер это тот который тестирует еще их называют QA.

Непонятно , потомцу что и при меньшем к-ве багов приложения которые я встерчал банально нетработали , или работали ошибочно.

Здравствуйте, minorlogic, Вы писали:
M>Непонятно , потомцу что и при меньшем к-ве багов приложения которые я встерчал банально нетработали , или работали ошибочно.
Гм. Ну и у нас оно сначала работает ошибочно. QA для того и нужен, чтобы оно работало безошибочно.

Кажется я понял о чем презентация автора. Он открыл для себя "Абстрактные типы данных"

С.Макконнел. "Совершенный код", глава 6 , 6.1. Основы классов: абстрактные типы данных.

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

WH>Те много интефейсов всегда хуже чем мало? Я правильно понял?

Вопрос абстрактный. Точно так же можно спросить: "1000 строк кода — это плохо или хорошо?". Нужно еще учитывать и контекст. Например, в случае объектной модели полезно оценить количество интерфейсов и классов, приходящихся на одну сущность. Чем их больше, тем хуже.

WH>Например у меня есть подсистема в которой на 5 сущьностей приходится 10 интерфейсов. Это плохо?

А сколько еще на эти 5 сущностей приходится классов? Вот и оцените.

WH>Мне надо срочно все рефакторить?

Рефакторить, считаю, не надо до тех пор, пока не столкнетесь со сложностью сопровождения.

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

КЛ>Например, в случае объектной модели полезно оценить количество интерфейсов и классов, приходящихся на одну сущность. Чем их больше, тем хуже.
Ты в этом так уверен?

КЛ>А сколько еще на эти 5 сущностей приходится классов? Вот и оцените.
5 классов + 2 аттрибута + 1 фабрика из одного однострочного метода. Это одна из реализаций этих сущьностей.
Другая может содержать другое колличество классов.

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

КЛ>Рефакторить, считаю, не надо до тех пор, пока не столкнетесь со сложностью сопровождения.
Так столько классов и интерфейсов и было сделано для того чтобы можно было легко работать, сопровождать и расширять.

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

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

КЛ>>А сколько еще на эти 5 сущностей приходится классов? Вот и оцените.
WH>5 классов + 2 аттрибута + 1 фабрика из одного однострочного метода. Это одна из реализаций этих сущьностей.
WH>Другая может содержать другое колличество классов.
Итого — 15 "классов" (10 интерфейсов + 5 классов) на 5 сущностей? Получается — по 3 "класса" на сущность.

WH>Вся работа осуществляется только через интерфейсы. Таким образом мы можем работать с множеством реализаций одновременно.
Ну и с классом (без всякого дополнительного интерфейса) программист тоже работает через интерфейс класса.

WH>А столько интерфейсов нужно для того чтобы можно было работать единообразно со всеми сущьностями которые поддерживают то или иное действие.
WH>Те я просто беру коллекцию, отфильтровываю элементы по интерфейсу и вперед.
Боюсь, ничего не могу сказать, т.к. мне непонятна суть задачи и ее решения. Все описано слишком абстрактно. Лучше рассмотреть конкретный пример. Тогда, думаю, станет все ясно.

КЛ>>Рефакторить, считаю, не надо до тех пор, пока не столкнетесь со сложностью сопровождения.
WH>Так столько классов и интерфейсов и было сделано для того чтобы можно было легко работать, сопровождать и расширять.
Опять-таки, думаю, что конкретный пример прояснит ситуацию.

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

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

WH>>5 классов + 2 аттрибута + 1 фабрика из одного однострочного метода. Это одна из реализаций этих сущьностей.
WH>>Другая может содержать другое колличество классов.
КЛ>Итого — 15 "классов" (10 интерфейсов + 5 классов) на 5 сущностей? Получается — по 3 "класса" на сущность.
Арифметика из серии: (5 крокодилов + 10 помидоров) / 5 мотоциклов
Самому не смешно?

WH>>Вся работа осуществляется только через интерфейсы. Таким образом мы можем работать с множеством реализаций одновременно.
КЛ>Ну и с классом (без всякого дополнительного интерфейса) программист тоже работает через интерфейс класса.
Как ты будешь работать с разными реализациями (читай классами) в статически типизированном языке? Если не через интерфейсы?

КЛ>Боюсь, ничего не могу сказать, т.к. мне непонятна суть задачи и ее решения. Все описано слишком абстрактно. Лучше рассмотреть конкретный пример. Тогда, думаю, станет все ясно.
Нужна хитрая объектаная модель: У объектов могут быть собственные свойства и события, а также могут быть присоедененные свойства и события.
Например:
В случае ГУИ у нас есть кнопка.
Собственные свойства кнопки это допустим text и собственное событие это OnClick.
С присоедененными свойствами все куда веселее. Дело в том что есть мнение которое хрен оспоришь что x, y, width и height это не собственные свойства кнопки.
Эти свойства добавляет контейнер в который кладут кнопку. Те контейнер AbsolutePosition добавляет x, y, width и height, а контейнер Grid добавляет row и col.

И того 5 сущьностей: собственное свойство, собственное событие, присоедененное свойство, присоедененное событие и тип.

Соответственно нужна модель метаданных для всего этого дела. Также нужна сериализация всего этого безобразия (в разные предстваления XML, binary, DB...) Еще нужно иметь в виду что читема должна уметь десереализовать в разные представления например в WinForms и WebForms.
Также нужно несколько реализаций метаданных. Ибо в разных случаях могут быть удобны разные реализации.

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