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

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

IT>>>О, блин! Только что ответил выше Повторюсь здесь. Да, буду править, если сложность восприятия этого кода будет для меня проблемой. Сразу оговорюсь, буду править не потому, что заглядывая в него я буду тратить лишнее время (ты же всё равно к этому всё сведёшь, правильно ), а потому что я очень расстраиваюсь, когда вижу плохой код и моё хорошее настроение мне дороже любого времени.

G>>Совать руки в отлаженный работающий механизм, куда не ожидаются правки, внося туда новые баги, просто потому, что случайно заглянул туда не в том настроении?

IT>Бывает, что время на то, чтобы разобраться в отлаженном работающем механизме требуется больше, чем время чтобы его нормально переписать, отладить, откоментировать и обложить тестами.

А бывает и так, что в работающем коде нет повода ни разбираться, ни переписывать. Потому, что работы, которую _можно_ сделать, обычно гораздо больше, чем ты сделать физически в состоянии.

Но это не главное. Главное, что ты, наконец, не уследил за собой, и нечаянно охарактеризовал "сложность" через время и трудозатраты, связанные с внесением правки.

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

AVK>>>Если у тебя в руках молоток, все вокруг кажется гвоздями.

G>>На себя примерь.

AVK>Не подошло.

Отлично. Теперь личная просьба — тебя не затруднит прекратить делать переходы на личности, вспоминая искрометные поговорки? Тебе ведь не сложно, нет?

AVK>>>Ты упорно говоришь про что то свое, не про то что в статье. Она вообще не о сроках и трудоемкости.

G>>Я говорю про то, что в статье.

AVK>При этом автор тебе говорит о том, что ничего подобного он не писал. Знаешь лучше автора?

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

Тебя это чем-то не устраивает?

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

M>>>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом."

M>>>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...

G>>Один ошибочный вывод не делает бредом всю статью. В конце концов, непрерывно нести бред очень тяжело. Почти так же тяжело, как и все время говорить истину, и только истину . Если предмет статьи содержателен, конечно.

M>Конечно нет , но уровень статьи сразу понижает. Может все же Мак Коннелла почитать? без шуток ? Ну уже классика, пока не стареющая.

Да нормальная у IT в целом статья. Не вижу причины, почему бы ему не написать статью о своем видении сложности. Даже если на эту тему уже писал МакКоннел. Что — теперь нельзя, чтоли?

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

G>Отлично. Теперь личная просьба — тебя не затруднит прекратить делать переходы на личности, вспоминая искрометные поговорки?

Это не переход на личности. Это не имеет отношение к твоей личности, это намек на то, что в твоих сообщениях демонстрируется крайне узкая точка зрения, плохо коррелирующая с тем, что имел в виду автор статьи.

AVK>>При этом автор тебе говорит о том, что ничего подобного он не писал. Знаешь лучше автора?

G>Я в курсе, что он ничего подобного не писал. И вообще — не вижу смысла писать то, что автор уже написал. Я дополняю его статью взглядом с другой стороны на ту же проблему.

Если бы ты только дополнял. Но ты же споришь и опровергаешь. И это при том, что IT тебе ясно написал, что ничего против метрик не имеет, но статья не о том.

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

I>>Вообще говоря — да.

I>>Код не должен просто работать.

G>Код должен просто работать. Когда у тебя возникает _резон_ вносить туда правку, ты можешь рассматривать его рефакторинг.

Работать — это недостаточно, что бы оставлять его в неизменном виде.

I>>Если в код никто не лазит, то, как правило, его никто и не знает, следовательно, никто не знает ни возможностей, ни особенностей этого кода.

G>Вообрази ситуацию, что твоему продукту 10 лет, и объем исходников составляет миллион строк кода, и он при этом постоянно развивается. Систему такого объема один человек не в состоянии понимать и удерживать в голове целиком, и ситуация, когда ты знаком и работаешь с ее фрагментом — естественна.

3 млн строк если тупо строками. Все полностью в голове не нужно держать.

G>Нет ни необходимости, ни практической возможности лазить в места, которые давно написаны, отлажены, и отлично работают.

Если отлично работают, дублирования не дают, с освоением проблем не возникает, фич не планирует, багов нет — это ж как в сказке

G>У тебя на практике не будет на это ни времени, ни возможности — рефакторинг такого кода слишком сложен и затратен, чтобы делать его пробегая мимо. Тому, кто так будет делать, коллеги с тестерами довольно быстро руки вырвут.

Пробегая мимо и не нужно. В бекграунде вполне возможно.

I>>Следовательно, новый функционал с большой вероятностью будет дублировать уже имеющийся.

G>Не следует, и не будет. Ни единого резона на то нет. С какого дуба очередь коллцентра должна дублировать хоть что-то из функциональности перевода звонка? У тебя это просто не получится.

Дублирование не на уровне подсистем конечно. Дублирование можт проявляться на пример в вагонах водопроводного кода или кода для конфигурации.

G>Для меня вообще загадка, о каких системах вы думаете, когда говорите подобное.

Сложно предложить хороший пример, я согласен.

I>>ПОтому код надо пересматривать регулярно. А если у кода "высокая сложность", то обычно с этого все и начинается.

G>Скорость просмотра незнакомого кода, на которой ты в состоянии более-менее его понять, и найти там какие-то ошибки — 200 строк кода в час. Это измеренный темп кодревью свежего (т.е. довольно неплохого) кода. Переписывание обойдется куда дороже.

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

G>Теперь. У тебя миллион строк, из которого активная разработка затрагивает, допустим, 200 тысяч строк. Остальной код — стабилен, и там иногда находят баги.

Как то очень абстрактно. Мне надо знать, что там за баги, т.е. не описание, а вся цепочка возникновения. Буде цепочки длинные, не зависимо от severity, это указывает на проблемы.

Даже если в этом остальном коде багов нет, нужно смотреть цепочки возникновения багов в том коде где идет активная разработка.

G>И у тебя, естественно, полный бэклог багов и фич, на год вперед, и жопа в мыле.

Если можно очень четко изолировать эти 200к строк с багами и фичами, то это слишком простой случай.

G>Валяй, считай, сколько времени ты готов потратить на "просматривание" остальных 800 тысяч.

Все 800 тысяч не нужно просматривать. Нужно находить ключевые места в коде и через них преобразоывать код.

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

Эти ключевые места вобщем то и определеяют состояние всего кода.

По времени оценить сложно, т.к. много неизвестных.

G>Знаешь, от программеров всего ожидать можно, но от тебя не ожидал. Я ведь типовую ситуацию описываю, не какую-нибудь экзотику.

Я 10 лет проработал на длинных и проектах и вобщем говорю про типовые ситуации.

Код начинает тухнуь вобщем то с тех мест которые вроде как стабильны, работают и тд.

I>>Как правило, корень проблем, на мой взгляд, это как раз код который работает годами и туда никто не лазит

G>Это нормальная ситуация, и ты никуда от нее не денешься — хочешь или не хочешь.

Почему же не денешься, просто сразу все зараз переписывать не нужно.

Бывает, менеджеры имеют обыкновение отгонять девелоперов от такого кода, что не есть правильно.

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

G>>Я говорю про то, что в статье.

AVK>При этом автор тебе говорит о том, что ничего подобного он не писал. Знаешь лучше автора?

Автор статьи в этом треде не раз и не два прокололся. А иногда возникает ощущение что он под пивом

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

I>Автор статьи в этом треде не раз и не два прокололся. А иногда возникает ощущение что он под пивом

У меня ощущение, что под пивом или чем то еще в этом требе как раз ты.

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

G>Но это не главное. Главное, что ты, наконец, не уследил за собой, и нечаянно охарактеризовал "сложность" через время и трудозатраты, связанные с внесением правки.

Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя. Если интересно могу об этом случае рассказать подробнее.

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

I>>Автор статьи в этом треде не раз и не два прокололся. А иногда возникает ощущение что он под пивом

AVK>У меня ощущение, что под пивом или чем то еще в этом требе как раз ты.

На давайте теперь обсудим, кто тут под пивом, а кто под водкой.

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

I>>Автор статьи в этом треде не раз и не два прокололся. А иногда возникает ощущение что он под пивом
AVK>У меня ощущение, что под пивом или чем то еще в этом требе как раз ты.

Мальчики, не ссорьтесь! Тем более, что сегодня пятница и вам обоим уж точно давно пора быть по пивом

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

I>>Автор статьи в этом треде не раз и не два прокололся. А иногда возникает ощущение что он под пивом

AVK>У меня ощущение, что под пивом или чем то еще в этом требе как раз ты.

Ты сильно погорячился. А проколы автора вобщем то четко обозначены.

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

G>>Но это не главное. Главное, что ты, наконец, не уследил за собой, и нечаянно охарактеризовал "сложность" через время и трудозатраты, связанные с внесением правки.

IT>Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя.

Ты уже в который раз вместо указания конкретных фактов используешь эмоциональную оценку.

"Геморрой" это обычно время, активность и твоя эмоциональная оценка этих затрат.

Попробуй отделить эмоциональную оценку от того, что ты хочешь сказать.

Под пивом, сдаётся, это не просто

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

IT>>Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя.
I>Ты уже в который раз вместо указания конкретных фактов используешь эмоциональную оценку.

Я уже в который раз пытаюсь кое-кому объяснить, что эмоциональная оценка такие же конкретные факты, как и всё остальное.

I>Под пивом, сдаётся, это не просто

Ты уже? У меня ещё рабочий день не закончился.

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

G>>Отлично. Теперь личная просьба — тебя не затруднит прекратить делать переходы на личности, вспоминая искрометные поговорки?

AVK>Это не переход на личности. Это не имеет отношение к твоей личности, это намек на то, что в твоих сообщениях демонстрируется крайне узкая точка зрения, плохо коррелирующая с тем, что имел в виду автор статьи.

А ты, Андрей, не намекай, ты сразу прямо говори. Свои ж люди, давно заочно знакомы.

Отвечаю по существу. Я уверен, что моя точка зрения отлично коррелирует с тем, что хотел сказать автор.

И я готов это доказать. По самым строгим правилам — приведя прямое соответствие между пунктами его статьи, и тем, что сказал в своем первом комменте я.

Я, правда, грешным делом полагал, что это очевидно. Но если нет — то не вопрос.

AVK>>>При этом автор тебе говорит о том, что ничего подобного он не писал. Знаешь лучше автора?

G>>Я в курсе, что он ничего подобного не писал. И вообще — не вижу смысла писать то, что автор уже написал. Я дополняю его статью взглядом с другой стороны на ту же проблему.

AVK>Если бы ты только дополнял. Но ты же споришь и опровергаешь. И это при том, что IT тебе ясно написал, что ничего против метрик не имеет, но статья не о том.

Он спорит, и пытается опровергать очевидное. Но давай это оставим, это не важно. Важно:
1) Статья я знаю, что не о том. Я в своем комменте привязываю контент статьи к метрикам, ибо с моей точки зрения оно о том. Можно, нельзя?
2) Где именно IT это сказал? Не заметил, сцылко, плиз.

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

I>>>Автор статьи в этом треде не раз и не два прокололся. А иногда возникает ощущение что он под пивом

AVK>>У меня ощущение, что под пивом или чем то еще в этом требе как раз ты.

I>Ты сильно погорячился. А проколы автора вобщем то четко обозначены.

Не. ты от ответа не уходи. Ты под пивом или под водкой?

Вот у меня лично сложный состав. В основе — Jack Daniels + Сибирская Корона + Хугарден.

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

G>>Но это не главное. Главное, что ты, наконец, не уследил за собой, и нечаянно охарактеризовал "сложность" через время и трудозатраты, связанные с внесением правки.

IT>Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя. Если интересно могу об этом случае рассказать подробнее.

Валяй, расскажи. Не вижу причин, почему нет — на конкретику всегда полезно перейти. Будет интересно.

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

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

IT>>>Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя.
I>>Ты уже в который раз вместо указания конкретных фактов используешь эмоциональную оценку.

IT>Я уже в который раз пытаюсь кое-кому объяснить, что эмоциональная оценка такие же конкретные факты, как и всё остальное.

Почитай, что мы, менеджеры, пишем про эмоциональную оценку. Будет интересно. Примерь на себя.
http://gaperton.livejournal.com/50685.html
Hint: некоторые из нас, менеджеров, не боятся "грязной работы", и иногда устраивают себе испытание: заставляют себя тряхнуть стариной, и в полный рост кодить. Из принципа, чтобы не отрываться от реальности. Редкость, но бывает, ага. И тогда появляются такие статьи.

I>>Под пивом, сдаётся, это не просто

IT>Ты уже? У меня ещё рабочий день не закончился.

Ниче, я надеюсь, ты нас догонишь.

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

G>>Вопрос некорректен. В любом _проекте_ сроки имеют значение, ибо проект всегда ограничен временем по определению. Не ограничены временем _программа_ и разгильзяйство. Но программа состоит из проектов. А из чего состоит разгильзяйство — мне не интересно.

IT>Думаю, что вот этот никак не ограничен временем.

Ниче не могу сказать. Просто, я ничего не знаю про это проект.

Скажу так. Я рассматриваю коммерческие проекты.

Если проект — исследование, он всегда ограничен временем и бюджетом. Почему? Потому, что цель проекта — получить новое знание, и всегда есть верхняя граница того, сколько готовы за это знание заплатить. По времени, и по деньгам. Это те реалии, с которыми я постоянно сталкиваюсь. А российской классификации, такой проект называется "НИР".

Если же проект имеет цель не получение нового знания, а получение работоспособного изделия/кода (сталкивался и с тем и с другим — я программно-аппаратными комплексами занимаюсь последние 5 лет), то это, пнимаешь-ли, называется ОКР.

И ты знаешь, один хрен он ограничен временем и деньгами.

Все проекты ограничены временем и деньгами, если это не так — то это не проекты — а "программа исследований".

Ты знаешь, я руководил в том числе и программами исследований. Было дело — в ИТМиВТ (институт точной механики и вычислительной техники). Вот, я тебе скажу, — "программа" бьется на серию вполне конкретных исследований (НИР), каждое из которых имеет конкретную цель, и ограничено рамками времени.

Почему? Потому, что даже в прикладной науке нам не нужен результат любой ценой. И если по конкретному направлению не будет результата длительное время (и не будет движухи по "открытым проблемам", то есть, их список не меняется длительное время) — оно будет закрыто.

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

IT>>>Здорово. Только я всё не возьму в толк, как мне это поможет выбрать правильный дизайн базы данных? Вот, например, у меня есть форма с гридом, в котором 24 колонки для 24-х месяцев, по 12 на 2 года. Как мне лучше их уложить в базу, как 24 месяца в одну запись или как две записи по 12 месяцев? Какую метрику посоветуешь?

G>>Посоветую не морочить людям голову, и перестать выдумывать и писать ерунду.
G>>Надоело.

IT>Т.е. для этого случая метрики не нашлось. На самом деле, и здесь всё можно свести ко времени, только проблема в том, что это время хрен засечёшь секундомером. Неверный дизайн всегда однозначно приводит к замедлению проекта, только вряд ли это "больше/меньше" можно померять с точностью хотя бы плюс/минус трамвайная остановка.

Нет. Просто ты в конце концов задолбал прикидываться валенком, Игорь.

Вопрос в очередной раз некорректно поставлен, и я реально задолбался в 7-й раз объяснять, почему.

Хочешь ответ вне контекста (т.е. юзкейсов)? Третья нормальная форма. Устраивает? Метрики здесь, как ты понимаешь, не причем. То есть, ни в красную армию, ни в известную дырку.

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

G>>Где вот такая херня написана, как ты привел? Ты их не просто читал, ты их, видимо, тщательно отбирал .
S>Да через раз. Отбирал их не я — отбирали авторы учебного курса на MBA.

Ссылку хотя бы на одинин источник, пожалуйста.

G>>Правда? Ну расскажи же мне, что же там еще такого есть, в теории менеджмента, чтоб про софтверные метрики (характеризующие software process по своей природе), но при этом ни в коем случае не про этот самый software process.
S>Открою тайну: метрики бывают вовсе не софтверные.

Тайну про то, что существуют самые разные числа на совершенно произвольную тему, ты мне открыть опоздал. Это сделала учительница физики в начальных классах средней школы.

А теперь я обращу внимание твое внимание на внезапную и неожиданную вешь, Синклер. Тока ты сядь на всякий случай. А то мало-ли что случится, от неожиданности-то.

Мы в этом форуме о софте говорим. И метрики обуждаем — софтверные. Не горнопрохождческие, станкостроительные, и даже не HR-ные. Не поверишь — но те как на духу говорю — правда. На название форума глянь, если не веришь.