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

I>>Сто пудов, у тебя есть как минимум интуитивная оценочная функция и надо чуток поработать, что бы можно было сформули ровать внятно, по-человечески.

IT>Если ты имеешь ввиду оценочную функцию производительности труда, то такой функции у меня нет. Я более двадцати лет пишу код и когда сегодня мне мой начальник задаёт вопрос "сколько это займёт времени", то я однозначно отвечаю — "не знаю". С другой стороны, я могу задать встречный вопрос — "а сколько у меня есть времени", и, в зависимости от его ответа, я могу ответить одно из:

IT>- импосибл,
IT>- только если включить форсаж,
IT>- бу сделано,
IT>- фигня вопрос.

Переводится в конкретные цифры методом половинного деления.

IT>При этом всегда присутствует оговорка, что это всё при отсутствии непредвиденных обстоятельств АКА мистической хреноты.

Чтобы учесть "обстоятельства", достаточно дать _два_ прогноза. С обстоятельствами и без них.

Грубо говоря — "раньше не справлюсь" — "точно успею". Разумные люди в прогнозах оперируют вариациями, а не "точными значениями". Но — при этом оперируют цифрами.

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

IT>Гапертон вообще говорит о чём-то своём. Он изобрёл метрику, в которой в качестве попугаев используются ошибки.

Первым этот подход изобрел Уотс Хамфри. И ошибки, конечно, там не используются в качестве "попугаев". Там вообще все просто, но не тупо.

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

Лучше за Хамфри порадуйся . И за студентов Carnegie-Mellon, у которых это в стандартную программу обучения входит.

IT>Только, во-первых, это всё его субъективный взгяд на его собственные проблемы, а, во-вторых, статья совсем не об этом.

Почему субъективный? Метрики-то как раз наблюдаемы объективно. А вот твои рассуждения о сложности — субъективны полностью.

IT>Обрати внимание, говоря о сложности, Гапертон всё время соскакивает на трудоёмкость.

Почему? Не только. Я все факторы учитываю. Про цикломатику, например, я достаточно внятно сказал.

IT>Он менеджер, он видит сложность только с этой стороны. В принципе, это нормально.

Нет, не правильно. Менеджер — это не более чем должность. И почкованием они не размножаются. У меня лет 10 стажа инженерной работы. И я с этой сложностью, как и любой Senior Software Developer (что тоже не более чем должность, а не религия и не образ мысли), знаком не хуже тебя. Все перечисленные тобой виды сложности имеют место быть, и прекрасно учитываются. У тебя просто системы нет в управлении сложностью. Я тебе ее показал. Вот и все.

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

G>>>>1) Объем. В строках кода, количестве классов, количестве функций — это не принципиально. Это — объем.
IT>>>А что даёт такая метрика?
G>>Дает объективную характеристику объема кода.

IT>Был у меня один случай лет пять назад. В Банке Оф Америка. Достался мне в наследство один недавно начатый проект от одного индуса. Объёма кода море, баги, глюки, тормоза, в общем всё как положено. После нескольких недель рефакторинга объём рукописного кода сократился раз в пять, баги, глюки, тормоза куда-то сами собой подевались, а тот же самый объём кода был достигнут только месяца через четыре, когда проект представлял собой уже не просто демку из формочек, а приложение под завяз напичканое функционалом.

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

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

IT>С тех пор веру в объём кода как в объективную характеристику я окончательно потерял.

У тебя появились сомнения, что объем кода объективно и точно считается? Однако .

IT>Да и в дальнейшем не раз приходилось в этом убеждаться.

Появились сомнения — а теперь "убеждаться"? У тебя что, тулза измерения SLOC разные результаты выдавала от запуска к запуску на одном файле? Выкинь эту тулзу.

IT> Сейчас, кстати, работаю над проектом, вротой его версией. Искренне надеюсь, что удастся сократить объём кода раза в два по сравнению с первой версией.

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

Я не понял, ты думаешь, что ты какие-то возражения против элементарных метрик приводишь?

G>>А еще — дает неплохие корелляции с количеством ошибок и временем, для каждого отдельно взятого Васи, и Коли.

IT>Количество ошибок безусловно как-то коррелирует с объёмом кода, но гораздо сильнее оно коррелирует с количеством мозгов у ошибающегося.

Не "как-то", а очень хорошо кореллирует. Так как мозг у ошибающегося находится в относительно стабильном состоянии, количество ошибок дает прекрасные корреляции с тем объемом кода, который он пишет. Корреляции великолепны и очень сильны — гораздо сильнее, чем корреляции время-объем. Производная метрика "плотность ошибок" Defects/KLOC ну очень стабильная для каждого отдельно взятого разработчика.

Померь и убедись сам. Все факты, о которых я говорю, проверяемы. Для проверки этого, правда, придется фиксировать все вносимые тобой ошибки, а не только те, которые находят тестеры.

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

G>>>>2) Время. С этим вопросов нет, не так-ли?
IT>>>Вопрос. Что даст такая метрика без учёта способностей Васи и Коли?
G>>Такая метрика объективно даст время решения задачи Васей и Колей. Никакого учета их способностей для измерения времени, которое они на задачу потратят, очевидно, не требуется.

IT>Т.е. это постфактум?

Для законченного проекта — постфактум, для незаконченного — прогноз.

IT>>>А что такое трудоёмкость?
G>>Штука такая, сводится к оценка объема работы в человекочасах. Очевидно, определяется сочетанием задачи и человека. Парадокс? Наверное, только для программистов.

IT>Есть такая штука... точнее была когда-то в СССР, сейчас уже не уверен — сметные нормы на строительные работы, которые всячески пытались учитывать производительность труда. Так вот, правильные командиры и мастера строй-отрядов абсолютно безошибочно выбирали для отряда те виды работ, которые наиболее хорошо оплачивались при минимальных затратах ресурсов, учитывая особенности конкретных бойцов. Неправильные командиры брались за любую работу. В результате при примерно одинаково выполненных объёмах работ и человекочасах зарплата в разных отрядах отличалась в разы. Хотя делалось всё по одним сметным нормам, учитывающим одну и туже производительность труда.

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

Более того, методики основанные на метриках говорят ровно обратное. Метрики _запрещено_ использовать для оценки "годности" персонала, и более того, например, в TSP менеджер вообще не видит индивидуальных метрик. Только агрегатные метрики по команде. Личные метрики считаются личной, приватной информацией, ее разглашать запрещено. Тулза их прячет.

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

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

G>>>>Вот и вся "сложность". Все, как видишь, очень просто.
IT>>>Даже слишком просто.
G>>Ты слишком много уделил внимания вводной части, в которой просто перечислялись известные объективные метрики, и пропустил часть, в которой была суть.

IT>Ты плохо читал статью. Я тщательно старался избегать любое упоминание о каких бы то ни было метриках.

Почему? Я очень внимательно прочитал статью. Ты тщательно избегал упоминания о метриках, а мне-то это зачем?

IT>Метрики нужны менеджерам, особенно плохим, им без них никак.

О как.

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

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

IT>>>Мало знать, что один код сложнее, чем другой. Сам по себе этот факт с практической точки зрения совершенно не интересен.
G>>Мысль в моем комментарии чуточку посложнее этой банальщины. Но не понял, и ладно.

IT>Сложность твоей мысли из той же серии что и сложность в доставшемся мне проекте, о котором я говорил выше. Если её (мысль) правильно отрефакторить, то возможно она станет простой и понятной не только одному тебе. И возможно, у неё даже будет шанс когда-нибудь стать банальной

Она и понятна не только мне. Лично тебе она не понятна . Начиная с момента — что называется объективной метрикой. Но я, в общем, не в претензии.

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

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

Не могу. Включить форсаж означает потеря качества кода. Это приемлемо в редких случаях, но заниматься этим систематически крайне вредно. К тому же предлагая нижнюю и верхнюю границу, я буду иметь ввиду верхнюю, а начальник всегда нижнюю. Какой смысл а таких сроках?

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

Трудоёмеость в программировании — это в чистом виде субъективная оценка конкретного индивидуума сроков выполнения его проектов, построенная на его предпочтениях. Можно, конечно, выявлять закономерности, но работать это будет в строго ограниченных рамках. Если бы такие закономерности можно было бы выявить хотя бы приблизительно и распространить на всю индустрию, то это уже давно было бы сделано. Уже давно закончились бы споры C# vs Java vs C++ и в мире рулил бы Немерле Но пока это не так. Потому что в мире есть люди со своими предпочтениями, есть "зи" архитекторы, принимающие дебильные решения, есть менеджеры, не умеющие распределять ресурсы, есть программисты с кривыми конечностями. И наоборот.

G>Странно что ты пытаешься не замечать этого.

Мне это не интересно в рамках данного обсуждения. Я вообще не об этом. Вот смотри, подходит, например, к тебе твой младший товарищ с таким вопросом — "Товарищ, gandjustas, что мне здесь лучше использовать? Visitor pattern, walker, просто набор ifs, заиспользовать F# и его ПМ или вообще забить?". Что ты ему ответишь?

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

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

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

IT>Не могу. Включить форсаж означает потеря качества кода. Это приемлемо в редких случаях, но заниматься этим систематически крайне вредно. К тому же предлагая нижнюю и верхнюю границу, я буду иметь ввиду верхнюю, а начальник всегда нижнюю. Какой смысл а таких сроках?
Поэтому оценка из двух сроков и дается.

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

IT>Трудоёмеость в программировании — это в чистом виде субъективная оценка конкретного индивидуума сроков выполнения его проектов, построенная на его предпочтениях.
В том то и дело что трудоемкость — чисто объективна, так как легко измеряется.

IT>Можно, конечно, выявлять закономерности, но работать это будет в строго ограниченных рамках. Если бы такие закономерности можно было бы выявить хотя бы приблизительно и распространить на всю индустрию, то это уже давно было бы сделано. Уже давно закончились бы споры C# vs Java vs C++ и в мире рулил бы Немерле Но пока это не так. Потому что в мире есть люди со своими предпочтениями, есть "зи" архитекторы, принимающие дебильные решения, есть менеджеры, не умеющие распределять ресурсы, есть программисты с кривыми конечностями. И наоборот.
Ну это же не повод совсем отказываться от оценок.

G>>Странно что ты пытаешься не замечать этого.

IT>Мне это не интересно в рамках данного обсуждения. Я вообще не об этом. Вот смотри, подходит, например, к тебе твой младший товарищ с таким вопросом — "Товарищ, gandjustas, что мне здесь лучше использовать? Visitor pattern, walker, просто набор ifs, заиспользовать F# и его ПМ или вообще забить?". Что ты ему ответишь?
Используй Силу, юный падаван. (серьезно)

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

IT>>Трудоёмеость в программировании — это в чистом виде субъективная оценка конкретного индивидуума сроков выполнения его проектов, построенная на его предпочтениях.
G>В том то и дело что трудоемкость — чисто объективна, так как легко измеряется.

Постфактум мало интересен. Мне нужно принимать решение здесь и сейчас, а не после разбора полётов.

IT>>Можно, конечно, выявлять закономерности, но работать это будет в строго ограниченных рамках. Если бы такие закономерности можно было бы выявить хотя бы приблизительно и распространить на всю индустрию, то это уже давно было бы сделано. Уже давно закончились бы споры C# vs Java vs C++ и в мире рулил бы Немерле Но пока это не так. Потому что в мире есть люди со своими предпочтениями, есть "зи" архитекторы, принимающие дебильные решения, есть менеджеры, не умеющие распределять ресурсы, есть программисты с кривыми конечностями. И наоборот.
G>Ну это же не повод совсем отказываться от оценок.

Да ради бога. Только я ещё раз повторяю, в рамках данной статьи мне эта тема не интересна.

IT>>Мне это не интересно в рамках данного обсуждения. Я вообще не об этом. Вот смотри, подходит, например, к тебе твой младший товарищ с таким вопросом — "Товарищ, gandjustas, что мне здесь лучше использовать? Visitor pattern, walker, просто набор ifs, заиспользовать F# и его ПМ или вообще забить?". Что ты ему ответишь?
G>Используй Силу, юный падаван. (серьезно)

А почему не "Используй Трудоёмкость, юный падаван."?

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

>>С другой стороны, я могу задать встречный вопрос — "а сколько у меня есть времени", и, в зависимости от его ответа, я могу ответить одно из:
I>Я это понимаю. Но это ведь для тех случав, когда работа радикально отличается от тех что были раньше ? Или ты имеешь скзать, что тебя ставят на проекты на которых другие уже провалили всё подряд ?

Не обязательно радикально отличаться. Может быть просто ситуация приоритетная и надо сделать быстро. А может быть наоборот.

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

IT>Не могу. Включить форсаж означает потеря качества кода. Это приемлемо в редких случаях, но заниматься этим систематически крайне вредно. К тому же предлагая нижнюю и верхнюю границу, я буду иметь ввиду верхнюю, а начальник всегда нижнюю. Какой смысл а таких сроках?

Твой начальник — идиот? Он не понимает, что ты ему вариацией даешь оценки случайной величины, и чтобы избежать систематической недооценки в плане, надо взять нечто похожее на "матожидание", т.е. как минимум (H-L)/2?

И чтобы успеть к общему сроку — на весь проект заложить "буфер безопасности", накинув как минимум одну сигму сверху, что даст нам примерно 85% вероятность укладывания в срок?

Ну, если он все-таки идиот (в чем я лично сильно сомневаюсь) — то ты говори ему M + S, то есть оценку, стоящую на трех четвертях между вариациями сроков. Тебе-то что мешает?

G>>Странно что ты пытаешься не замечать этого.

IT>Мне это не интересно в рамках данного обсуждения. Я вообще не об этом. Вот смотри, подходит, например, к тебе твой младший товарищ с таким вопросом — "Товарищ, gandjustas, что мне здесь лучше использовать? Visitor pattern, walker, просто набор ifs, заиспользовать F# и его ПМ или вообще забить?". Что ты ему ответишь?

"Полшестого". Ни разу не припомню, что бы кто-то к кому-то приходил с подобным вопросом.

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

Например, сокращение объема кода (и соответственно работы), упрощение этого кода (выражающееся в низкой цикломатике), или дешевизна будущих правок, выражающаяся в объеме кода и количестве место при внесении правки.

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

G>То, что ты в своих рассуждениях ввел разнообразные факторы — это неплохо. Это лучше, чем просто говорить "сложно". Но непосредственно из этого ничего не следует, ибо с проектным управлением твои рассуждения не стыкуются. Они не уложены в систему. Рассуждать, в результате, ты не можешь — ты можешь только пользоваться "чуйкой".

Я могу обосновать правильность выбора того или иного решения в процессе разработки и при этом учесть максимальное количество влияющих на это факторов. А какое решение примешь ты, зная что в прошлом проекте у тебя было 125 багов?

G>Как их уложить в систему — я тебе показал.

Я тут выше по ветке приводил пример с мндусиком, вклад которого в код был 5%, а количество багов в треккере 80%. После его изгнания его код был переписан и количество багов у команды сократилось в 5 раз. Вот и вся твоя система. Меня вообще из IBM провожали со словами "Мужик, мы тебя запомнить как человека, не оставившего следов в баг-треккере". На что ты теперь будешь умножать свою трудоёмкость, на 0?

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

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

IT>>>Трудоёмеость в программировании — это в чистом виде субъективная оценка конкретного индивидуума сроков выполнения его проектов, построенная на его предпочтениях.
G>>В том то и дело что трудоемкость — чисто объективна, так как легко измеряется.

IT>Постфактум мало интересен. Мне нужно принимать решение здесь и сейчас, а не после разбора полётов.

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

IT>>>Можно, конечно, выявлять закономерности, но работать это будет в строго ограниченных рамках. Если бы такие закономерности можно было бы выявить хотя бы приблизительно и распространить на всю индустрию, то это уже давно было бы сделано. Уже давно закончились бы споры C# vs Java vs C++ и в мире рулил бы Немерле Но пока это не так. Потому что в мире есть люди со своими предпочтениями, есть "зи" архитекторы, принимающие дебильные решения, есть менеджеры, не умеющие распределять ресурсы, есть программисты с кривыми конечностями. И наоборот.
G>>Ну это же не повод совсем отказываться от оценок.

IT>Да ради бога. Только я ещё раз повторяю, в рамках данной статьи мне эта тема не интересна.

Не интересна — зачем комментируешь? Дай другим обсудить. Вдруг — кому-то еще интересна?

IT>>>Мне это не интересно в рамках данного обсуждения. Я вообще не об этом. Вот смотри, подходит, например, к тебе твой младший товарищ с таким вопросом — "Товарищ, gandjustas, что мне здесь лучше использовать? Visitor pattern, walker, просто набор ifs, заиспользовать F# и его ПМ или вообще забить?". Что ты ему ответишь?
G>>Используй Силу, юный падаван. (серьезно)

IT>А почему не "Используй Трудоёмкость, юный падаван."?

Да нивапрос. Используй Трудоемкость, юный падаван . Единственный эффективный способ сделать работу быстрее — не делать лишней работы.

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

G>>То, что ты в своих рассуждениях ввел разнообразные факторы — это неплохо. Это лучше, чем просто говорить "сложно". Но непосредственно из этого ничего не следует, ибо с проектным управлением твои рассуждения не стыкуются. Они не уложены в систему. Рассуждать, в результате, ты не можешь — ты можешь только пользоваться "чуйкой".

IT>Я могу обосновать правильность выбора того или иного решения в процессе разработки и при этом учесть максимальное количество влияющих на это факторов. А какое решение примешь ты, зная что в прошлом проекте у тебя было 125 багов?

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

Например, если 120 из 125 багов локализованы в одном модуле, и "плотность ошибок" Defects/KLOC в нем аномально высока, и выходит за обычную вариацию — я буду искать причину этой аномалии, разбираться с ситуацией, и принимать меры. В особенности, если туда будут ожидаться в будущем правки. А какие именно меры — это уже зависит от ситуации.

И в будущем — обязательно проверю, возымели меры эффект, или нет.

G>>Как их уложить в систему — я тебе показал.

IT>Я тут выше по ветке приводил пример с мндусиком, вклад которого в код был 5%, а количество багов в треккере 80%. После его изгнания его код был переписан и количество багов у команды сократилось в 5 раз. Вот и вся твоя система.

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

И это, разумеется, далеко не вся "моя система". В реальности — он вообще ничего закоммитить не смог бы, по причине наличия код- и дизайн-ревью. И при регулярно зашкаливающем количестве issues на этом ревью (тоже метрика), он бы довольно скоро был вынужден либо включить мозг в положение ON, либо пойти искать себе другую работу.

IT>Меня вообще из IBM провожали со словами "Мужик, мы тебя запомнить как человека, не оставившего следов в баг-треккере". На что ты теперь будешь умножать свою трудоёмкость, на 0?

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

Не понял — и зачем мне на что-то умножать свою трудоемкость?

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

G>Ну, если у тебя есть автомобиль, то ты регулярно используешь метрики . С неработающей приборной доской в автомобиле ты даже не поймешь, что у тебя заканчивается бензин. С работающей — ты поймешь, что тебе надо бы на заправку зарулить, и увидев знак "это единственная заправка на 100 миль" ты туда завернешь.

А принимая решение повернуть налево или направо ты каким прибором пользуешься, спидометром или тахометром?

G>Вот, реально, простейший вариант.

Судя по всему мы с тобой говорим о разных вещах. Ну правда, мне не интересна тема управления проектами в рамках данной статьи. Где-нибудь в другом месте я бы с удовольствием потрепался на эту тему. А здесь мне интересней выяснить, например, почему решения, использующие Visitor pattern в целом сложнее, чем применение pattern-matching.

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

G>У тебя просто системы нет в управлении сложностью. Я тебе ее показал. Вот и все.

Вообще-то ты показал управление сроками, а не сложностью.

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

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

G>>Ну, если у тебя есть автомобиль, то ты регулярно используешь метрики . С неработающей приборной доской в автомобиле ты даже не поймешь, что у тебя заканчивается бензин. С работающей — ты поймешь, что тебе надо бы на заправку зарулить, и увидев знак "это единственная заправка на 100 миль" ты туда завернешь.

IT>А принимая решение повернуть налево или направо ты каким прибором пользуешься, спидометром или тахометром?

Выбирая маршрут — наручными часами, показывающими текущее время, и данными по средней скорости потока на карте, которые выдает навигатор в виде цветных линий.

Принимая решение повернуть направо на заправку — указателем бензина в бензобаке.

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

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

G>>Вот, реально, простейший вариант.

IT>Судя по всему мы с тобой говорим о разных вещах. Ну правда, мне не интересна тема управления проектами в рамках данной статьи.

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

IT>Где-нибудь в другом месте я бы с удовольствием потрепался на эту тему. А здесь мне интересней выяснить, например, почему решения, использующие Visitor pattern в целом сложнее, чем применение pattern-matching.

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

Причина наличия "паттернов" — слабый адхок полиморфизм в ОО модели. Только по одному (неявному) аргументу. В паттерн-матчинге он делается по любому количеству аргументов. Паттерн же раздербанивает тебе "единицу мысли", размазывая ее по нескольким местам, затрудняя reverse engineering, ибо тебе надо из фрагментов все заново сложить, а это уже работа.

Что тут обсуждать-то? Все достаточно очевидно.

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

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

IT>>>Трудоёмеость в программировании — это в чистом виде субъективная оценка конкретного индивидуума сроков выполнения его проектов, построенная на его предпочтениях.
G>>В том то и дело что трудоемкость — чисто объективна, так как легко измеряется.
IT>Постфактум мало интересен. Мне нужно принимать решение здесь и сейчас, а не после разбора полётов.
Анализ предыдущего опыта (не только своего) помогает принимать решения.

IT>>>Можно, конечно, выявлять закономерности, но работать это будет в строго ограниченных рамках. Если бы такие закономерности можно было бы выявить хотя бы приблизительно и распространить на всю индустрию, то это уже давно было бы сделано. Уже давно закончились бы споры C# vs Java vs C++ и в мире рулил бы Немерле Но пока это не так. Потому что в мире есть люди со своими предпочтениями, есть "зи" архитекторы, принимающие дебильные решения, есть менеджеры, не умеющие распределять ресурсы, есть программисты с кривыми конечностями. И наоборот.
G>>Ну это же не повод совсем отказываться от оценок.

IT>Да ради бога. Только я ещё раз повторяю, в рамках данной статьи мне эта тема не интересна.

Тебе — может и неинтересна, а другим вполне. Меня уже давно интересует сложность не сама по себе, а какими последствиями это грозит на проекте. Если я увижу что применение X вместо Y вызывало увеличение плотности багов и уменьшение скорости написания кода, то смогу сделать определенные выводы. А если будут только рассуждения о сложности той или иной функциональности, то мне это ничего не даст.

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

G>Причина наличия "паттернов" — слабый адхок полиморфизм в ОО модели. Только по одному (неявному) аргументу. В паттерн-матчинге он делается по любому количеству аргументов. Паттерн же раздербанивает тебе "единицу мысли", размазывая ее по нескольким местам, затрудняя reverse engineering, ибо тебе надо из фрагментов все заново сложить, а это уже работа.

То есть, для распознавания случая применения "паттерна", и для внесения сознательной правки, тебе надо удерживать в голове несколько объектов/мест одновременно. Это отвлекает в случае, когда ты знаешь что там паттерн, а вот если ты не знаешь — то тебе еще надо найти эти места, чтобы потом сложить из них "паттерны".

Учитывая, что одна из основных характеристик "хорошего" дизайна, это как раз количество мест + объем логики, которые тебе надо понимать и держать в уме одновременно, для внесения осмысленной правки — код с агрессивным применением "паттернов" таковым является с большой натяжкой.

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

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

Хороший дизайн подразумевает разбиение кода на набор слабосвязных компонент. Связность бывает "по состоянию" и "функциональная". Связность характеризуется "шириной интерфейса" (количеством разных функций/сообщений — функциональная связность) и сложностью протокола поверх данного интерфейса (связность по состоянию). Последняя характеризуется количеством состояний в протоколе.

Клинический случай сильной связности по состоянию — общие данные.

Так вот, для внесения правки в хороший дизайн тебе надо понимать небольшой фрагмент системы, и ты не сильно рискуешь. Происходит это благодаря связности. Основные свойства системы, характеризующие дизайн (т.е. входные данные для его оценки), можно выразить через объективные количественные метрики, и именно этот факт позволяет тебе оценивать их интуитивно, используя хитрую весовую функцию в голове, которая строится годами на основе твоего опыта.

А вот "весовую функцию" которая выполняет оценку в твоей голове, формализовать на все случаи жизни не просто невозможно, но просто бессмысленно и не нужно. Это есть тот самый уникальный "творческий" компонент. И это основной момент в работе с метриками, который ты почему-то отказываешься понимать. Пойми.

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

G>>У тебя просто системы нет в управлении сложностью. Я тебе ее показал. Вот и все.

IT>Вообще-то ты показал управление сроками, а не сложностью.

Точно так. К этому "прикладная теория сложности" и сведется.

Вне контекста сроков (трудоемкости) текущих и будущих работ, сложность, взятая сама по себе, ни малейшего интереса не представляет. Нафига нам абстрактная "сложность", никак не влияющая на сроки работ и цену внесения изменений?

Вот у тебя кусок кода. У него "высокая сложность", что означает крайне дорогие правки в этот код, даже если правки сами по себе незначительные. Но! Код отлажен, изолирован за годными интерфейсами, отлично работает, и никаких правок туда в ближайшие 5 лет не ожидается.

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

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

IT>>С тех пор веру в объём кода как в объективную характеристику я окончательно потерял.
G>У тебя появились сомнения, что объем кода объективно и точно считается? Однако .
IT>>Да и в дальнейшем не раз приходилось в этом убеждаться.
G>Появились сомнения — а теперь "убеждаться"? У тебя что, тулза измерения SLOC разные результаты выдавала от запуска к запуску на одном файле? Выкинь эту тулзу.

О, да! Допустим, у меня в команде объём одного из проектов 50k строк. Как ты думаешь — это сложный проект или не очень? А объём второго — 100k. Какой из них сложнее? А сложнее в чём? А какой быстрее написали? А на сколько быстрее?

IT>>Под ресурсами здесь, кстати, понимается в основном грубая физическая сила имеющихся в наличии индивидуумов. Мы же здесь толкуем о работе мозгами. Если бы мы тогда работали мозгами, то разница была бы не в разы, а на порядки.
G>Корреляции элементарных метрик наблюдаемы объективно, в том числе и при работе мозгами.

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

IT>>Ты плохо читал статью. Я тщательно старался избегать любое упоминание о каких бы то ни было метриках.
G>Почему? Я очень внимательно прочитал статью. Ты тщательно избегал упоминания о метриках, а мне-то это зачем?

Заметь, статья не о метриках, а о сложности. В основном о сложности выбора между двумя/тремя/... решениями. А не о сроках выполнения проектов.

IT>>Мне метрики не нужны, мне нужно распознать и предотвратить появление проблемных мест в приложении. А для этого мне вполне достаточно вещей вроде "больше"/"меньше".
G>Сравнивать на больше-меньше можно только количественные показатели. А не апельсины с бананами, и не вась с петями.

Да ну? Если я буду использовать, например, датасеты в своём приложении, то ускорю его написание на пару дней. А если не буду, то уменьшу баговость процентов на 30%. Сравнивай и, главное, выбирай.

IT>>Сложность твоей мысли из той же серии что и сложность в доставшемся мне проекте, о котором я говорил выше. Если её (мысль) правильно отрефакторить, то возможно она станет простой и понятной не только одному тебе. И возможно, у неё даже будет шанс когда-нибудь стать банальной

G>Она и понятна не только мне. Лично тебе она не понятна . Начиная с момента — что называется объективной метрикой. Но я, в общем, не в претензии.

Лично мне она прежде всего не интересна, потому что абсолютно не в тему.

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

IT>>Мне это не интересно в рамках данного обсуждения. Я вообще не об этом. Вот смотри, подходит, например, к тебе твой младший товарищ с таким вопросом — "Товарищ, gandjustas, что мне здесь лучше использовать? Visitor pattern, walker, просто набор ifs, заиспользовать F# и его ПМ или вообще забить?". Что ты ему ответишь?

G>"Полшестого". Ни разу не припомню, что бы кто-то к кому-то приходил с подобным вопросом.

А я ни разу не припомню, чтобы ко мне кто-то приходил и говорил — у тебя в прошлый раз было 5 багов, теперь тебе 2 месяца на решение новой задачи.

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

А в чём гениальность?

G>Например, сокращение объема кода (и соответственно работы), упрощение этого кода (выражающееся в низкой цикломатике), или дешевизна будущих правок, выражающаяся в объеме кода и количестве место при внесении правки.

Т.е. ты ему скажешь, что если пойдёшь налево, то напишешь кода на 1264 строки меньше. Пойдёшь направо — справишься бысрее на 5 часов. Пойдёшь прямо — сделаешь 14 багов. Так? Я тебя правильно понял? А если не так, то чем твоя гениальность отличается от моей, твоя эзотерика от моей метафизики?

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

IT>>Постфактум мало интересен. Мне нужно принимать решение здесь и сейчас, а не после разбора полётов.
G>И при принятии решения ты учитываешь собственный прогноз трудоемкости. Сознательно, или безсознательно.

Я не только трудоёмкость учитываю, а ещё много чего другого.

IT>>Да ради бога. Только я ещё раз повторяю, в рамках данной статьи мне эта тема не интересна.
G>Не интересна — зачем комментируешь? Дай другим обсудить. Вдруг — кому-то еще интересна?

Пожалуйста, сколько угодно.

IT>>>>Мне это не интересно в рамках данного обсуждения. Я вообще не об этом. Вот смотри, подходит, например, к тебе твой младший товарищ с таким вопросом — "Товарищ, gandjustas, что мне здесь лучше использовать? Visitor pattern, walker, просто набор ifs, заиспользовать F# и его ПМ или вообще забить?". Что ты ему ответишь?
G>>>Используй Силу, юный падаван. (серьезно)

IT>>А почему не "Используй Трудоёмкость, юный падаван."?

G>Да нивапрос. Используй Трудоемкость, юный падаван . Единственный эффективный способ сделать работу быстрее — не делать лишней работы.

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

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

IT>>>Мне это не интересно в рамках данного обсуждения. Я вообще не об этом. Вот смотри, подходит, например, к тебе твой младший товарищ с таким вопросом — "Товарищ, gandjustas, что мне здесь лучше использовать? Visitor pattern, walker, просто набор ifs, заиспользовать F# и его ПМ или вообще забить?". Что ты ему ответишь?

G>>"Полшестого". Ни разу не припомню, что бы кто-то к кому-то приходил с подобным вопросом.

IT>А я ни разу не припомню, чтобы ко мне кто-то приходил и говорил — у тебя в прошлый раз было 5 багов, теперь тебе 2 месяца на решение новой задачи.

И такого я тоже такого не припомню. Зачем кому-то к тебе приходить, и говорить что-то вроде "в огороде бузина, а в Киеве дядька"? Не понимаю.

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

IT>А в чём гениальность?

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

G>>Например, сокращение объема кода (и соответственно работы), упрощение этого кода (выражающееся в низкой цикломатике), или дешевизна будущих правок, выражающаяся в объеме кода и количестве место при внесении правки.

IT>Т.е. ты ему скажешь, что если пойдёшь налево, то напишешь кода на 1264 строки меньше. Пойдёшь направо — справишься бысрее на 5 часов. Пойдёшь прямо — сделаешь 14 багов. Так? Я тебя правильно понял? А если не так, то чем твоя гениальность отличается от моей, твоя эзотерика от моей метафизики?

Объем-ошибки и объем-время дают корреляции, так что предложенная тобой альтернатива либо-либо-либо невозможна в принципе. Меньше кода — в среднем меньше ошибок, меньше времени. Это в целом и общем. В деталях и в конкретных случаях — возможны варианты.

Мне достаточно будет сказать, почему не сделать вот так — кода будет сильно меньше. И вовсе не обязательно приводить "точное" значение, насколько строк меньше. Есть и другие критерии, за которыми также стоят объективно измеримые вещи. Но значимость их — зависит от ситуации.

Разница в том, что ты отказываешься привязывать свою теорию сложности к объективно измеримым вещам.