Здравствуйте, FDSC, Вы писали:
FDS>Я бы на вашем месте так резко не реагировал даже на личную критику, в конечном итоге это вам нужно вычленить зерно истины из его критики, а не ему (если вам не нужно, то зачем вы вообще спорите?). Если честно, мне очень странно видеть вашу реакцию на критику, вы портите себе репутацию.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, FDSC, Вы писали:
FDS>>Я бы на вашем месте так резко не реагировал даже на личную критику, в конечном итоге это вам нужно вычленить зерно истины из его критики, а не ему (если вам не нужно, то зачем вы вообще спорите?). Если честно, мне очень странно видеть вашу реакцию на критику, вы портите себе репутацию.
КЛ>Со стороны Capertona была не критика, а грубость.
Даже если то, что он сказал немного грубовато (именно немного), всё равно это именно критика с зерном смысла. Да и то, потому что вы сами не очень-то корректно ведёте себя, со стороны это заметно.
В любом случае, тогда бы просто не отвечали на его сообщения. Тут одно из двух: или вы пытаетесь понять, что вам пытаются сказать (если в высказываниях есть смысл), но тогда вам надо избегать острых мест и всячески смягчить тон беседы, выяснить, что вам непонятно;
или наоборот, если это грубость, в которой нет никакого смысла, то просто поставьте минус и не отвечайте на неё. Зачем зря ругаться?
Вместо того, что бы проигнорироваться грубость, вы сами отвечаете грубостью. Естественно, тяжело ожидать, что ваша беседа пойдёт в конструктивных рамках и приведёт к более полному пониманию позиций сторон.
Вот это меня удивляет. Может быть, я не понимаю, и есть какие-то другие мотивы ответов... интересно было бы их услышать
Здравствуйте, Кирилл Лебедев, Вы писали:
FDS>>Я бы на вашем месте так резко не реагировал даже на личную критику, в конечном итоге это вам нужно вычленить зерно истины из его критики, а не ему (если вам не нужно, то зачем вы вообще спорите?). Если честно, мне очень странно видеть вашу реакцию на критику, вы портите себе репутацию.
КЛ>Со стороны Capertona была не критика, а грубость.
Тонкая душевная организация — хороший и удобный повод оставлять без ответа неудобные вопросы. Браво, коллега.
Давно заметил — эта организация почему-то особенно тонка у людей, склоных к хамству и высокомерию . Впрочем, не важно.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Вот странный человек. Для того и создаются различные методологии, чтобы сократить количество ошибок в коде. И различные процедуры проверки качества типа code review. А Вы все заладили про постоянство ошибок. Поруководите хотя бы пол годика реальными программистами, и Вы сами уже будете знать, сколько ошибок и их серьезность допустит тот или иной программист.
Вообще-то народу известно, что он руководил. И какими проектами.
И его опыт многими весьма ценится. В том числе потому, что он им делится не в форме истины в последней инстанции.
Здравствуйте, Gaperton, Вы писали:
G>Тонкая душевная организация — хороший и удобный повод оставлять без ответа неудобные вопросы. Браво, коллега.
Пожалуйста, без высокомерных комментариев перечислите здесь вопросы, на которые Вы не получили ответа. Если "наездов" не будет, на каждый вопрос Вы получите ответ.
G>Давно заметил — эта организация почему-то особенно тонка у людей, склоных к хамству и высокомерию . Впрочем, не важно.
Внимательно прочтите свои собственные сообщения, начиная с самого первого.
Здравствуйте, deniok, Вы писали:
D>Вообще-то народу известно, что он руководил. И какими проектами. D>И его опыт многими весьма ценится. В том числе потому, что он им делится не в форме истины в последней инстанции.
Это не отменяет необходимости корректно общаться (без наездов). Его отзыв был крайне груб. Я так считаю: если не понимаешь что-то, спроси. Или, по крайней мере, скажи, что не понимаешь. Самоутверждаться за счет других — не лучшая тактика общения.
Здравствуйте, Кирилл Лебедев, Вы писали:
E>>Не могли бы вы здесь, без ссылок на свои статьи или части своей презентации, сформулировать, что нового показала ваша презентация по сравнению, хотя бы, с данной главой из книги Страуструпа?
КЛ>Вы хотите, чтобы я назвал отличия? Ну, что ж, держите:
КЛ> КЛ>Понятие идеальной программы. Почему выгодно ориентироваться на идеальность.
Этого у страуструпа нет. Потому, что этот ваш тезис — ошибочен.
КЛ>Этапы развития "кода" (как архитектуры, так и самого кода). Волнообразная модель.
Этого тоже нет. Потому, что 1) так на практике не происходит, и 2) ничего полезного от этой модели все равно нет.
КЛ>Метод группировки разнородных сущностей. Ему посвящены этапы 1.3 и 2.2. КЛ>Обычно группируют, находя похожие атрибуты и вынося их в базовые классы.
Обычно так только лохи делают, которые вообще в ООП ничего не понимают — это противоречит принципу инкапсуляции. Аттрибуты вообще игнорируются при построении объектной модели. За такое "обычно" руки вырывать надо с корнем из одного места — откуда они обычно в таких случаях растут, в общем.
Свежо короче. У Страуструпа такого, наверно, нет .
КЛ>В презентации говорится, что контекст для группировки нужно искать со стороны, т.е. не по похожести атрибутов, а потому, как и для чего объекты используются.
Очень свежо. Да про это в любой книге по ООД говорится в самом начале.
КЛ>Схлопывание иерархии в класс.
Этого нет. Потому как нафиг никому не надо этим заниматься (тезис основан на ложной посылке, что "много классов — это плохо"). Впрочем, нечто похожее описано в книге "антипаттерны", где про рефакторинг пишут. Правда, "схлопывания в класс" там вроде не указано — там напротив, все больше даются рекомендации по расхлопыванию класса, написанного кривыми руками.
КЛ>Этапы свертывания. В частности, то, что задание одинаковых интерфейсов для различных сущностей — первый шаг к дальнейшему их свертыванию.
Вроде как шаг рефакторинга описывается — только непонятно, зачем так делать. Сколько раз легаси-код рефакторил — ну ни разу "этапа свертывания" не замечал.
КЛ>То, что различия между объектами "надо продвигать вниз" (на нижние слои). КЛ>То, что нижние слои поглощают средние.
Это комментировать не возьмусь. Как легаси код прет в свеженаписанную подсистему, проламывая клином страшенных багов и неожиданных фич эшелонированную оборону из слоев абстракции — видел. Как нижние слои поглощают средние — нет. Что-то страшное наверно, вроде столкновения и поглощения галактик. Зачем надо различия между объектами куда-то продвигать — не понятно. Тема, короче, не раскрыта.
КЛ>То, что сначала нужно выявлять не классы/понятия, а действия. И проектировать конкретные структуры данных под эти операции (назовем их макро-операции или бизнес-функции).
Угумс. В любой книге про практическое применение УМЛ в самом начале — когда юзкейсы описываются. Структуры даных под эти действия, правда, проектировать при объектном подходе прям так сразу — запрещено (структуры данных инкапсулированы в классы — об интерфейсах надо думать), но это мелочи жизни. КЛ>
А-а-ставайтесь с нами. http://rsdn.ru/Forum/Message.aspx?mid=1158902&only=1
Здравствуйте, Кирилл Лебедев, Вы писали:
G>>Тонкая душевная организация — хороший и удобный повод оставлять без ответа неудобные вопросы. Браво, коллега.
КЛ>Пожалуйста, без высокомерных комментариев перечислите здесь вопросы, на которые Вы не получили ответа. Если "наездов" не будет, на каждый вопрос Вы получите ответ.
Спасибо за предложение, но я воздержусь . Мне не настолько интересны ваши ответы, коллега, чтобы выискивать свои вопросы и опять затевать с вами занудную переписку. Я ведь не особенно хочу вас в чем-то убеждать. А мнение о вас и вашей презентации у меня уже сложилось.
Сразу замечу, что предмет вашего спора мне не интересен. Так что поговорю о форме.
Гапертон у нас известный забеяка, но тем не менее ты тут тоже от конструктивности далек.
Пробегусь по примерам:
G>>Не устраивает, разумеется. Меня интересует "каким образом", а то что вы "из головы" свои качественные выводы берете — это и так понятно. Не откуда больше.
КЛ>Если Вас интересует ответ на этот вопрос, обратите внимание на пример, приведенный в презентации. Полагаю, что ответ будет очевиден.
Это называется "отмазка". Если ты хочешь чтобы кто-то обратил внимание на пример из презентации, то дай сслыку на нужный слайд и поясни, что ты хочешь показать этим слайдом.
G>>Код меряется в строках кода. Его так весь мир измеряет. Потому что только эта метрика дает мало-мальски приличные корелляции со временем разработки и с количеством ошибок. Количество классов не является метрикой объема кода, количество операторов дает строгую корелляцию с количеством строк кода, поэтому меряют все равно в строках кода — они проще в подсчете.
КЛ>Уважаемый коллега! В детстве, Вы наверняка, смотрели мультик про слоненка, мартышку, попугая и удава. Там наглядно показано, что длину можно мерить в чем угодно. Так удава измеряли и в мартышках, и в слоненках, и в попугаях. Даже маленькие дети понимают, что измерять можно, в чем угодно. В чем удобнее, в том и измерим. Неужели же программист с более чем 10-летним стажем не понимает этой столь простой истины?
Мне кажется "уважаемый колега" намекла, на то что есть общепринятые подходы. Я правда знаю два тких подхода в строках и в LOC-ах. Но тем не менее объяснение приемуществ "операторного похода" они не дают. Так что потрудись объяснить, а не отмазываться. Если, конечно, тебе интересна дисскусия, а не флэйм.
G>>Но все-таки, я наверное чего-то не понимаю. Приведите примеры, в каких ситуациях и почему именно "выгоднее" измерять объем кода "в операторах". Желательно — живой пример из своего 11-летнего опыта. Просим-просим.
КЛ>Пример есть в презентации. Если же Вам что-то непонятно, задайте вопрос без ехидства. Я отвечу. На вопросы, сформулированные в таком тоне, как сейчас, я отвечать не буду.
Опять. "Есть в презентации" — это все равно что ничего не сказать. Она довольно большая.
Мы вот всем кто пишет статьи объясняем, что нужно не объяснять что написано втом или ином абзаце редакторам, и не давать им ссылки, а переписать текст так чтобы не возникало вопросов. Причем у всех (или большинства).
Так что если у кого-то возникают вопросы по твоей презентации, то лучше уточни в чем они заключаютя и исправь презентацию так, чтобы вопросы отпали сами собой.
G>>Раз все настолько сложно и неоднозначно — что понятие "код" берется в кавычки и у этого понятия возможны оказывается разные (!) толкования, то вам следовало посвятить понятию "кода" отдельные слайды вашей презентации. Ваш труд, по видимости, фундаментален, и пересматривает сами основы?
КЛ>Я не предполагал, что для кого-то банальная истина может быть непонятна.
Значит наткнувшись на этот файт, надо изменить свое мнение и таки дать объяснение в презенатции, а не всревать в дрязги и объяснять окружающим, что они не понимают очевидного. Не понимают, значти не очевидно.
КЛ> С учетом того, что здесь уже кажется обсуждали, что текст — не единственно возможное представление кода. Поищите, думаю, обсуждение было где-то в марте-апреле.
Опять отмакза. Не надо заставлять окружающих искать. Дай ссылку. А лучше исправь презентацию.
КЛ>Ведь Вы же код меряете только в уже написанных строках! А о том, что иерархию из 115 классов (хотя бы их код и будет минимален) будет трудно сопровождать, Вы как-то не задумываетесь. Если бы задумывались, то, по крайней мере, не спрашивали бы меня, когда код полезно измерять в классах.
Я думаю, что Гапертон пытался тебе сказать, что классы бывают разными по размеру. Можно залудить один класс который будет сложнее и больше чем 115 мелких и простых. Более того моно вообще обходиться без классов. В языках с паттерн-матчингом, например есть такие фишки как алгеброические типы. В некоторых ситуациях они позволяют радикально сократить объем кода не согращая количества сущностий (которые ты привык называть классами).
Так что про архитектуру ты говоришь врено. Но вот толко есть разные сопобы получать хорошую архитекруру. И это никак не оправдывает измерение объема кода в количестве классов.
КЛ>Поруководите хотя бы пол годика реальными программистами, и Вы сами уже будете знать, сколько ошибок и их серьезность допустит тот или иной программист.
А вот это уже понты. Дело в том, что тут тебе в основном аппонируют люди которые не один год руководили программистами. Так что подобные понты выглядят со стороны очень некрасиво.
Кстати, из моего опыта я знаю, что самые сложные ошибки допускают самые квалифицированные программисты. Делают они их редко, но проблемы с ними обычно получаются самыми большими.
Что касается ошибок, то конечно тренерованный спец делает их меньше чем юный "гений". Но тем не менее некоторая статистика по этому поводу есть. И она показывает, что от качества проектирования многие классы ошибок не зависят.
КЛ>С чего Вы взяли, что я вообще чего-то взял? Презентация выложена для желающих. Вам это неинтересно? Не читайте! И уж тем более не пишите какие-либо отзывы. Хотя бы потому, что написать вежливо, по-существу и конкретно у Вас не получается. А вычитывать подростковую грубость мне неинтересно.
Забавный подход. То есть отзыв должен быть неприменно положительным? Ну, вот ты наткнулся на отрицательный. Если честно, то я на этом форуме положительных и не видел. Может все же задуматься над тем, что что-то не так в твоей презентации или даже твоих мыслях?
Учись из всего извлекать пользу, а отходы выбрасывать за ненадобностью. Если человек выражет недовольство, то пойми чем оно вызвано и устрани эти причины. Если он неадекватен или неконструктивен, то просто проигнорируй его мнение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Я-то как раз знаю, сколько ошибок допускают программисты. Скажу по секрету — по метрикам компании CQG, где я работал пару лет назад, плотность ошибок колеблется в среднем в коридоре 20-40 штук на 1000 строк кода. Язык С++.
Собственно у меня вопрос , вот беру я свой модуль 400 строк кода , и задумываюсь , а как он вааще может работать если там от 8 до 16 ошибок ? Т.е. мне даже представить тяжело программу с таким к-вом багов
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, deniok, Вы писали:
D>>Вообще-то народу известно, что он руководил. И какими проектами. D>>И его опыт многими весьма ценится. В том числе потому, что он им делится не в форме истины в последней инстанции.
КЛ>Это не отменяет необходимости корректно общаться (без наездов). Его отзыв был крайне груб. Я так считаю: если не понимаешь что-то, спроси. Или, по крайней мере, скажи, что не понимаешь. Самоутверждаться за счет других — не лучшая тактика общения.
Киррил , вам уже неоднократно замечали что ваша манера общаться мягко говоря не лучше, высокомерно хамовитая. Так чего на зеркало пенять ?
Здравствуйте, FDSC, Вы писали:
FDS>У каждого измерения есть цель, грубо говоря, функциональная предпосылка. Какая цель в измерении кода количеством строк сказал выше Gaperton, а вот какая цель в измерении классами как-то не очень понятно. Тем более, что не классами он у вас должен меряться, а количеством связей и интерфейсов на одном абстрактном слое. Тут вы сами себе противоречите.
Какой из них лучше?
Не смотря на то, что оба примера плохи, второй пример лучше. Почему? Давайте посчитаем количество классов и интерфейсов, приходящихся на одну сущность.
В первом примере объявлено 9 классов (интерфейс IFigure хоть и объявлен, но не используется — его не считаем). Эти классы используются для представления 3-х сущностей: прямоугольника, ромба и квадрата. Итого: 3 класса на сущность.
Во втором примере объявлено 4 класса. Они используются для представления 2-х сущностей: прямоугольника и квадрата. Итого: 2 класса на сущность.
Чем больше классов, представляющих сущность, тем хуже. Если в сущности что-то поменяется, то придется менять все связанные с ней классы.
Иногда сущности группируются (например, в иерархии). Но и внутри группы они тоже нередко проявляют свою самобытность. Так каждый класс иерархии может предоставлять еще какие-то дополнительные атрибуты и методы, которых нет в базовом классе. Если же для каждой сущности группы тоже создать по нескольку классов (и все их поместить в иерархию), то сопровождение кода станет невозможным.
Если сущность помещена в группу, и размер группы невелик, можно ограничиться одним классом на сущность. Однако с возрастанием количества сущностей в группе, даже и это значение становится большим. Если иерархия содержит много классов, ее становится трудно сопровождать, т.к. изменения в интерфейсе приводят к изменениям в каждой из реализаций.
Именно поэтому большие иерархии выгодно "схлопывать" в один класс. Но, конечно, не ценой возникновения оператора switch. Т.к. это будет никакое не схлопывание, а то же самое, что и было. Только вместо каждого класса — отдельный case.
FDS>Не единственно возможное, но наиболее часто используемое, удобное и привычное. Сами бы дали ссылку, вам-то легче найти. Споров таких в философии было уже штук пять наверное, на моей памяти.
Я немного ошибся. На самом деле, это утверждение было не на форуме, а в статье. Возможно, похожее обсуждалось и на форуме, но я первее нашел статью.
"Сегодня 99% программистов считают, что программирование есть запись инструкций, которым должен следовать компьютер. Нас учили, что компьютеры смоделированы по модели машины Тьюринга, так что они «думают» в терминах наборов инструкций. Но такой взгляд на программирование неполноценен: он путает способы и цели программирования. Я покажу, чем ЯОП лучше традиционного программирования, но в первую очередь необходимо кое-что прояснить: программа в ЯОП – это не набор инструкций. Тогда что это?
Имея проблему, я обдумываю ее решение. Это решение выражено в словах, понятиях, концепциях, мыслях – как бы вы их не называли. Это модель решения в моей голове. Практически никогда я не думаю о наборах инструкций, вместо этого я думаю о взаимосвязанных концепциях, специфичных для области в которой я работаю. К примеру, рассуждая о GUI, я думаю «Эта кнопка должна быть там, это поле тут, а в комбобокс надо поместить набор значений». Я могу даже просто представлять картинку, вообще не используя слов.
Я называю эту мысленную модель решением: я могу объяснить ее другому программисту с достаточной степенью детализации, чтобы он мог сесть и написать программу (скажем, на Java), решающую проблему. Мне не нужно выражать решение в терминах языка программирования – оно может быть в любой форме. Объясняя GUI, я рисую картинку. Это предметно-ориетированное представление должно быть программой. Другими словами, должен быть способ использовать это представление как готовую программу, а не только как способ общения с другими программистами. Отсюда следует мое неформальное определение программы: программа есть любое однозначно описанное решение проблемы. Или, более точно: программа есть любая точно определенная модель решения некоторой проблемы в некоторой предметной области, выраженная через понятия предметной области".
FDS>Здесь замечание уходит туда же, куда и мои замечания по поводу того, что вы не рассмотрели весь процесс разработки и не выясниили, каким образом проектировать СРАЗУ хорошую архитектуру так, чтобы необходимость в сворачивании кода была минимальна.
Как раз этому и посвящена презентация. Там шаг за шагом (этап за этапом) описан процесс развития кода (или, если Вам не нравится это слово, архитектуры). И понятно, что стратегически нужно двигаться к этапам 1.3, 2.2, 2.3 и 2.4. Т.е. если у Вас получается иерархия, то надо подумать, где она разъедится (этап 2.1), и как сделать так, чтобы не разъезжалась (этап 2.2).
Если иерархия устаканилась, то следует попробовать перейти к этапу 2.3 и попытаться заменить ее одним классом, выполнив операцию свертывания на уровне реализации.
При этом совершенно необязательно писать код. Подобные операции выполняются на этапе проектирования.
FDS>Сворачивание кода — дополнительная паразитная работа, которой хотелось бы избежать. Об этом вам говорит Gaperton, если я его правильно понимаю, конечно
Я бы рад не заниматься свертыванием. Но, как правило, без группировки проектирование не обходится. В том-то и состоит задача архитектора. Потому что изначально есть разные сущности, а их нужно сгруппировать, чтобы работать с ними стандартно, а не уникально.
FDS>Т.е. вы предлагаете всю эту иерархию запихнуть в один класс и сказать, что его будет лечге сопровождать, чем хорошо построенную иерархию из простых классов?
Да, если решение не подразумевает оператора switch.
КЛ>>Не уходите в сторону, а отвечайте на вопрос: "Код стажера и код профи, действительно, по Вашему мнению, имеет одинаковое количество багов?" Тут кто-то говорил про универсальность метрик. Так что презентация тут не при чем.
FDS>Т.е. вы хотите сказать, что количество ошибок на один класс у программиста-гуру и стажёра будет одно и то же?
Здравствуйте, minorlogic, Вы писали:
M>Киррил , вам уже неоднократно замечали что ваша манера общаться мягко говоря не лучше, высокомерно хамовитая. Так чего на зеркало пенять ?
Здравствуйте, minorlogic, Вы писали:
G>>Я-то как раз знаю, сколько ошибок допускают программисты. Скажу по секрету — по метрикам компании CQG, где я работал пару лет назад, плотность ошибок колеблется в среднем в коридоре 20-40 штук на 1000 строк кода. Язык С++.
M>Собственно у меня вопрос , вот беру я свой модуль 400 строк кода , и задумываюсь , а как он вааще может работать если там от 8 до 16 ошибок ? Т.е. мне даже представить тяжело программу с таким к-вом багов
Я не специалист в измерении кода и багов в перерасчете на строки кода, однако, насколько я могу понять, речь идет о вносимых ошибках при написании кода. Дальнейшая отладка позволяет отловить и убрать ошибки (возможно с внесением новых) и постепенно сократить их вплоть до нуля.
Или у тебя модуль на 400 строк был сразу написан без единой ошибки? Что ж, это возможно, Gaperton говорит, что все зависит от человека, однако тем не менее — выражаю глубокое восхищение и уважение.
З.Ы. В процессе коде-ревью иногда (редко, но запоминается) нахожу баги в коде, запущенном в производственную эксплуатацию, которые явно есть, но при этом не обнаруживаются, благодаря удачному стечению обстоятельств, годами...
Здравствуйте, Кирилл Лебедев, Вы писали:
G>> Что означает, что количество ошибок в среднем большей степени определяется объемом кода.
КЛ>Позвольте спросить, Вы утверждаете, что код, написанный программистом-стажером и профи, содержит одинаковое количество багов на 1000 строк? Если Ваш ответ "да", то Вы страшно далеки от реальных проектов. Ибо количество ошибок у стажера может превышать количество ошибок у профи в десятки раз.
Ты не учитываешь один хитрый фактор, который коварно учитывает Gaperton. Количество ошибок в программе (модуле) в целом у стажера действительно может быть в десятки раз больше чем у профи. Но. Объем кода для решения той же задачи у "профи" меньше объема кода у стажера так же десятки раз. Таким образом плотность ошибок на строки кода остается неизменной.
Пример прямо сегодня был — переписал код программиста (причем не стажера!) — экран кода (строк 20-30), находящегося в глубоко нерабочем состоянии заменил на 3 (три!) строки кода, которые сразу заработали верно (ну, сложно ошибиться в 3 строчках, правда?).
Сегодня же писал другой код сам — экран несложного кода, ошибка, поиск и отладка.
Такие дела.
Здравствуйте, Gaperton, Вы писали:
G>Тонкая душевная организация — хороший и удобный повод оставлять без ответа неудобные вопросы. Браво, коллега.
G>Давно заметил — эта организация почему-то особенно тонка у людей, склоных к хамству и высокомерию . Впрочем, не важно.
G>ЗЫ: Слив засчитан.
На самом деле ты тоже хорош. Первое высказывание было по теме. Дальше ты уже подкалывал оппонента. Я конечно понимаю, что это фирменный стиль. Но такой интеллектуальный троллинг ни к чему хорошему не приводит.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
. Впрочем, не важно.
Если нам не помогут, то мы тоже никого не пощадим.
