VGn>>Очевидно ты не совсем знаком с областью проблем, решаемых аналитиком. Почитай Вигерса. S>Как раз читаю. Только практика и теория слегка рознятся. Некоторые компаниии (знаю не по наслышке) вкладывают именно этот, указанный мной смысл, а не описываемый. И приходится ориентироваться именно на то что имеется а не на то как должно быть. У меня есть желание прикрутить данную статью от автора с моими поправками на мою реальность и реализовать её на практике. Не судите строго за мои отступления от хорошо описанной теории. VGn>>Настолько устоялся обычай, что аналитик — прокладка без крылышек, что даже вот приходится разъяснять, что аналитик должен вообще что-то делать кроме макулатуры. S>И разъясняйте если не сложно. Будет полезно всем участникам.
Ну так если читал, то должно быть понятно, что аналитик должен не только выявлять требования но и отслеживать их, оценивать риски изменения этих требований, общаться с заказчиком и с исполнителями по поводу их реализуемости.
Контроли версий (в какой-то мере) и контроль конфигураций (довольно плотно) — тоже активности аналитика.
Поэтому кстати у нас в России разделяют аналитиков на "бизнес" и "системных", хотя я бы не стал, потому что связь между рассматриваемыми проблемами довольно плотная.
А у нас обычно все эти активности размазываются тонким слоем по куче людей, включая разработчиков, менеджеров и даже сейлзов. Логические связи рвутся. В итоге получается "испорченный телефон" и в разы выросшие издержки.
VGn>>Господа, давайте общаться. Графики хорошо, но погружение намного лучше. S>Можно практический пример? Возможно я не совсем понимаю о чём идёт речь.
Всё о том же. Плотное общение и погружение в процесс даёт больше эффекта. Время, выделенное на подсчёт метрик, гораздо эффективнее можно потратить на логический анализ. Так что здесь нужно продумывание эффективности. (Я не имею в виду, что метрики вообще не нужны но при прочих равных они не могут быть так эффективны в этом случае, как хотелось бы.)
VGn>>(-) VGn>>Зависимость эффективнности от квалификации растёт нелинейно и довольно значительно. Так что проекту будет только выигрыш, если конечно изначально не закладывались на принцип "программисты — винтики".
S>Пркатический пример (из жизни) Некий программист пришёл на проект изучил технологию, применил её. Сам работает нормально. Внимание вопрос -- как часто руководство компаний замечает своих сотрудников? Зачастую приходится напоминать о себе и доказывать свою состоятельность для повышения зп. Есть2-й вариант.. Подучиться и уйти "туда где ценят". А именно принцип "программисты — винтики" -- применяем 90 процентами компаний. Да и не только программисты. Мнение "а что мы специалиста не найдём дешевле да лучше?" очень часто используем. И по этому рассматривать оторванную от реальности ситуацию не очень хотелось бы. Возможно у вас примеры другие есть Но у меня имено такие. т ч несогласие не понятно.
Ну так это проблема эффективности работы менеджера, а не каких-то там качеств разработчика.
VGn>>Более того, если вы берёте людей, которые не развиваются, то значит вы изначально ошиблись в своей оценке их квалификации. S>Нет Дело тут не только в развитии. S>Например S>1. есть чел мегаквалификации, но решает задачи ниже уровня своей квалификации т к по проекту большая и не требуется. Куда и на чём ему развиваться? Если конечно не самостоятельно в отрыве от производства.
Ну так двигайте его. Ротация — хорошая штука.
Врядли человек может развиться за время разработки одного проекта и джуниора в гуру.
Так что тут могут быть только такие проблемы:
— сразу взяли overqualified
— затянули проект до безобразия
— неверная мотивация
S>2. Наша ситуация. Есть чел низкой квалификации. Большая не требуется -- куда ему развиваться? S>3. пришёл чел с низкой квалификацией. Развился и выполняет задачи. Он хотел бы далее расти, но его не пускают ибо это потеря человека именно с данного проекта. Результат или он уйдёт по компании или из компании но точно с проекта. Может конечно остаться на проекте с передвижением по иерархии, но на моей памяти такие случаи единичны.
Честно говоря видел мало проектов, где действительно нужна низкая квалификация. В рамках одного проекта может быть такая роль, но она обычно составляет малую часть объёма работ. И тут ротация, кстати, вполне возможна.
Зато видел несколько проектов aka "давайте нагоним студентов, они нам толпой быстро всё сваяют", что кончалось печально.
S>>>2. если программист должен обучаться, то явно не на живых проектах (как это часто делается). VGn>>- В чём не согласие? Да я знаю что практика как раз такова, что обучение как раз на живых пректах и происходит. Но тогда надо и риски соответствующие закладывать.
А на чём ещё?
В теории рекомендуют заниматься такими делами на этапе прототипирования aka Технического проекта. Но в российском бардаке этапы размазывают, как кому вздумается, а значит и активности размазываются так же.
Так что корень проблемы не в том, что программист хочет учиться, а в том что ему не дают этап, где он может этим активно заниматься.
Здравствуйте, VGn, Вы писали:
VGn>Зато видел несколько проектов aka "давайте нагоним студентов, они нам толпой быстро всё сваяют", что кончалось печально.
А я до сих пор вижу И заканчивается оочень печально и потом начинается поиск крайних
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Игорь Ткачёв, Вы писали:
PD>Целью проектирования является уменьшение сложности, для чего, собственно, и вводится понятие компонента (в широком смысле этого слова). Внутрення сложность компонента может быть сколь угодно высока, но его внешняя сложность должна быть небольшой. При работе с компонентом нас его внутрення сложность не интересует, он для нас (в идеале) black box. А внутри него — те же правила для его подкомпонентов.
PD>И это не только к программированию относится.
Я бы сюда добавил что развитие цивилизации вообще, и программирования в частности идет в направлении создания новых категорий, упрощающих представление объектов. Так могу привести пример изобретения слова "дифференциал", которое спровоцировало массу исследований в математике. Хотя суть была известна задолго до этого. Просто формулировка "отношение приращения функции к приращению аргумента" заставляла расходовать мысленные усилия заслоняя собой истиную природу явления. Можно опуститься еще в ранние времена когда было изобретено сложение, и затем умножение. Ведь и этих понятий когда-то не было. Более близкие и понятные нам времена когда были "изобретены" процедуры и затем процедурное программирование. Может кто и помнит волшебные времена, когда такого понятия не было, и каково было вдохновление програмистов узнавших новый метод "процедурное программирование".
затем изобретение полиморфизма, изобретение типов, затем классов это все значительно уменьшает сложность решения задачи, а иногда и вообще изобретение новых категорий делает возможным решение задачи не решаемой (из-за сложности) другими методами.
Сюда же необходимо отнести способность применить новую категоризацию (это не обязательно разбиение на классы) которая может значительно уменьшить сложность задачи. Чисто теоретически задача вообще может быть неалгоритмизована в одних категориях и алгортимизована в других.
К этому могу добавить рассуждения о логической сложности. К этой категории сложности необходимо отнести количество условных операторов и их вложенности. Задача может быть и легко формулируема, но огромное количество условных операторов может сделать ее даже нереализуемой. Не говоря уже о том, что такие программы чрезвычайно не гибки, и сложны как в учебе, так и в сопровождении. Видя перед собой большое количество If-ов, голова начинает буксовать конкретно.
Вообще нужная статья. Мне часто приходится говорить что мои решения менее сложны. Но вот даже сослаться не на что. Четких цифр и определений нет.
Кстати, есть способ уменьшить логическую сложность.
Здравствуйте, batu, Вы писали:
B>Я бы сюда добавил что развитие цивилизации вообще, и программирования в частности идет в направлении создания новых категорий, упрощающих представление объектов. Так могу привести пример изобретения слова "дифференциал", которое спровоцировало массу исследований в математике. Хотя суть была известна задолго до этого. Просто формулировка "отношение приращения функции к приращению аргумента" заставляла расходовать мысленные усилия заслоняя собой истиную природу явления. Можно опуститься еще в ранние времена когда было изобретено сложение, и затем умножение. Ведь и этих понятий когда-то не было. Более близкие и понятные нам времена когда были "изобретены" процедуры и затем процедурное программирование. Может кто и помнит волшебные времена, когда такого понятия не было, и каково было вдохновление програмистов узнавших новый метод "процедурное программирование".
Эти времена не помню, но помню, как впервые узнал про структурный подход. Нас ему не учили. Прочитал книгу (до сих пор жалею, что ее потерял) и с удовлетворением отметил, что интуитивно я эти принципы и ранее применял — еще один г-н Журден.
Ну а как ООП внедрялось — помню хорошо.
B>затем изобретение полиморфизма, изобретение типов
Можешь себе представить программирование без типов ? Нет, базовые типы, конечно, есть, а вот структур нет. Вообще нет. Фортран-4. И ничего — жили, хотя и не сказать, что очень хорошо. С типами я столкнулся, когда перешел на Паскаль, и поначалу они меня напрягали — мало мне того, что я должен помнить имена переменных, так еще и типы я должен помнить . Ничего — привык.
А вот ООП никакой отрицательной реакции не вызывало. Принял сразу.
Статья в целом неплохая. Ибо программисты и менеджеры часто оперируют понятием "сложно", "не сложно", и делают вид, что понимают друг друга. На самом деле, первые говорят о своем субъективном восприятии "геморроя", связанного с задачей, а вторые чаще всего имеют в виду трудоемкость (напрямую связанную с длительностью).
Термин "сложность" давно пора раскрыть. А лучше всего — изъять нафиг из обращения, как противоречивый, путающий людей, и ничего не говорящий. Русский язык велик и могуч, да и в английском много других слов .
По факту же, у тебя написано, как бы это сказать, очень сложно. По своей сути все гораздо проще.
Если вещи, которые в процессе разработки ПО объективно и точно поддаются измерению. Их, в целом, немного.
1) Объем. В строках кода, количестве классов, количестве функций — это не принципиально. Это — объем.
2) Время. С этим вопросов нет, не так-ли?
3) Количество ошибок.
4) И, как тебе вероятно известно, есть метрики "сложности". Это, например, Cyclomatic Complexity, которая косвенно характеризует количество тестов, необходимых для вылова тех самых ошибок, которые в п.3.
То есть. Очевидно, что 10000 строк кода написать и отдалить дольше, чем эти 100, если не брать маргинальные примеры, конечно. Другими словами, налицо корелляция объема и трудозатрат. Объем — какая это "сложность"? Речь о "трудоемкости", а не "сложности", и не надо их смешивать. Это раз.
Далее. Пусть у нас имеется код объемом (1), скажем, в 100 строк за вычетом комментариев.
Код такого объема, очевидно, может быть написан за разное время — задачи-то разные. Отношение строки кода/время называется "продуктивностью". Очевидно, что для "сложной" задачи коэффициент "продуктивность" будет меньше, чем для простой, не так ли? Что также объективно наблюдаемо — для "сложной" задачи мы в целом пишем меньшее количество строк кода за одно и то же время, чем для "простой".
А почему так получается? Потому, что для "сложной" задачи мы допускаем больше ошибок (3). Иногда мы сразу видим, что не знаем, как написать правильно (без ошибок). Иногда — мы понимаем, что допустили ошибку, когда начинаем писать код. Иногда — понимаем при тестировании. А иногда — когда программой начинают пользоваться клиенты.
То есть, сложность состоит в том, чтобы написать без ошибок. Какие классы ошибок бывают? Разберем по видам технических решений, которые мы принимаем. В каждом из них мы можем ошибиться.
0) Требования. Ошибочные предстваления о том, что надо сделать.
1) Архитектурная. Неверный выбор базовых технологий и/или общих принципов построения системы.
2) Дизайн. "Структурная" ошибка. Неверная нарезка функциональности на компоненты.
3) Детальный дизайн. Ошибка в алгоритмах или структурах данных.
4) Кодирование. Здесь понятно.
Понятно также, что чем выше уровнем техническое решение, тем дороже ошибка.
Но при внесении изменений в существующий код эта стройная картина ломается, и уже начинает играть ведущую роль цикломатика (метрика 4). Систему с множеством режимов (спагетти) тяжело удержать в голове, и не допустить ошибок при внесении в нее изменений. Элементарные правки уровня (4) зачастую вызывают непредсказуемые ошибки, дорогие в диагностике и исправлении. Такой код называется "хрупким".
"Рефакторинг" — есть приведение ее в состояние, когда начинает выполняться указанная выше закономерность.
Вот и вся "сложность". Все, как видишь, очень просто.
PD>Можешь себе представить программирование без типов ? Нет, базовые типы, конечно, есть, а вот структур нет. Вообще нет. Фортран-4. И ничего — жили, хотя и не сказать, что очень хорошо. С типами я столкнулся, когда перешел на Паскаль, и поначалу они меня напрягали — мало мне того, что я должен помнить имена переменных, так еще и типы я должен помнить . Ничего — привык.
PD>А вот ООП никакой отрицательной реакции не вызывало. Принял сразу.
Я Паскаль хорошо принял. Аккуратно слепленый, рекурсия, структуры.. ООП это песня. Хотя я на VB его принял. Сначала было ущербно. Особенно события буксовали. Вот с того момента мне и захотелось развить эту тему. Доразвивался.. Хотя приятно видеть свои задумки реализоваными, но до серьезных изменений MS не додумался еще. А я все толкусь. Надоело, если честно, агитировать..
Здравствуйте, Gaperton, Вы писали:
G>Если вещи, которые в процессе разработки ПО объективно и точно поддаются измерению. Их, в целом, немного. G>1) Объем. В строках кода, количестве классов, количестве функций — это не принципиально. Это — объем. G>2) Время. С этим вопросов нет, не так-ли? G>3) Количество ошибок. G>4) И, как тебе вероятно известно, есть метрики "сложности". Это, например, Cyclomatic Complexity, которая косвенно характеризует количество тестов, необходимых для вылова тех самых ошибок, которые в п.3.
А как тут учитывается "сложность" связанная с необходимым объемом знания для написания кода.
Гипотетический пример — написать парсер языка без специальных инструментов. Влоб такая задача решается крайне плохо, используя некоторые теоретически знания — гораздо лучше.
Многие современные языки как раз торгуют объем-время на эту самую сложность понимания.
Здравствуйте, Gaperton, Вы писали:
G>Статья в целом неплохая. Ибо программисты и менеджеры часто оперируют понятием "сложно", "не сложно", и делают вид, что понимают друг друга. На самом деле, первые говорят о своем субъективном восприятии "геморроя", связанного с задачей, а вторые чаще всего имеют в виду трудоемкость (напрямую связанную с длительностью).
Согласен, есть такое дело.
G>По факту же, у тебя написано, как бы это сказать, очень сложно. По своей сути все гораздо проще.
G>Если вещи, которые в процессе разработки ПО объективно и точно поддаются измерению. Их, в целом, немного. G>1) Объем. В строках кода, количестве классов, количестве функций — это не принципиально. Это — объем.
А что даёт такая метрика?
G>2) Время. С этим вопросов нет, не так-ли?
Вопросов есть. Допустим, Вася решает задачу A за один день, а Коля решает ту же задачу за два дня. При этом задача A — это маленькая часть задачи B. Но, Вася решает всю задачу B за два месяца, а Коля за один. Парадокс? Возможно, но только не в программировании.
Вопрос. Что даст такая метрика без учёта способностей Васи и Коли?
G>3) Количество ошибок.
Кстати, Вася за два месяца сделал в два раза больше ошибок, чем Коля за один.
G>4) И, как тебе вероятно известно, есть метрики "сложности". Это, например, Cyclomatic Complexity, которая косвенно характеризует количество тестов, необходимых для вылова тех самых ошибок, которые в п.3.
G>То есть. Очевидно, что 10000 строк кода написать и отдалить дольше, чем эти 100, если не брать маргинальные примеры, конечно. Другими словами, налицо корелляция объема и трудозатрат. Объем — какая это "сложность"? Речь о "трудоемкости", а не "сложности", и не надо их смешивать. Это раз.
А что такое трудоёмкость? Мы её будем мерять в человеках? А может гораздо точнее будет в Васях или Колях?
G>Вот и вся "сложность". Все, как видишь, очень просто.
Даже слишком просто. Мало знать, что один код сложнее, чем другой. Сам по себе этот факт с практической точки зрения совершенно не интересен. Интересно знать — почему, т.к. зная почему уже можно принимать конкретные решения. А чтобы знать, нужно понимать детали. Вот как раз о деталях эта статья.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
G>>Если вещи, которые в процессе разработки ПО объективно и точно поддаются измерению. Их, в целом, немного. G>>1) Объем. В строках кода, количестве классов, количестве функций — это не принципиально. Это — объем.
IT>А что даёт такая метрика?
Дает объективную характеристику объема кода.
А еще — дает неплохие корелляции с количеством ошибок и временем, для каждого отдельно взятого Васи, и Коли.
G>>2) Время. С этим вопросов нет, не так-ли?
IT>Вопросов есть. Допустим, Вася решает задачу A за один день, а Коля решает ту же задачу за два дня. При этом задача A — это маленькая часть задачи B. Но, Вася решает всю задачу B за два месяца, а Коля за один. Парадокс? Возможно, но только не в программировании.
IT>Вопрос. Что даст такая метрика без учёта способностей Васи и Коли?
Такая метрика объективно даст время решения задачи Васей и Колей. Никакого учета их способностей для измерения времени, которое они на задачу потратят, очевидно, не требуется.
G>>3) Количество ошибок.
IT>Кстати, Вася за два месяца сделал в два раза больше ошибок, чем Коля за один.
Бывает сплошь и рядом.
G>>4) И, как тебе вероятно известно, есть метрики "сложности". Это, например, Cyclomatic Complexity, которая косвенно характеризует количество тестов, необходимых для вылова тех самых ошибок, которые в п.3.
G>>То есть. Очевидно, что 10000 строк кода написать и отдалить дольше, чем эти 100, если не брать маргинальные примеры, конечно. Другими словами, налицо корелляция объема и трудозатрат. Объем — какая это "сложность"? Речь о "трудоемкости", а не "сложности", и не надо их смешивать. Это раз.
IT>А что такое трудоёмкость?
Штука такая, сводится к оценка объема работы в человекочасах. Очевидно, определяется сочетанием задачи и человека. Парадокс? Наверное, только для программистов.
Никто не ждет от школьника на уроке труда, что он сделает табурет за то же время, что и столяр первого разряда, да еще такого, у которого на табуретках рука набита.
IT>Мы её будем мерять в человеках?
Не, не будем.
IT>А может гораздо точнее будет в Васях или Колях?
Очевидно, "гораздо точнее" будет в человекоминутах.
G>>Вот и вся "сложность". Все, как видишь, очень просто.
IT>Даже слишком просто.
Ты слишком много уделил внимания вводной части, в которой просто перечислялись известные объективные метрики, и пропустил часть, в которой была суть.
Ничего сложного в таком прочтении, естественно, нет.
IT>Мало знать, что один код сложнее, чем другой. Сам по себе этот факт с практической точки зрения совершенно не интересен.
Мысль в моем комментарии чуточку посложнее этой банальщины. Но не понял, и ладно.
Здравствуйте, gandjustas, Вы писали:
G>>Если вещи, которые в процессе разработки ПО объективно и точно поддаются измерению. Их, в целом, немного. G>>1) Объем. В строках кода, количестве классов, количестве функций — это не принципиально. Это — объем. G>>2) Время. С этим вопросов нет, не так-ли? G>>3) Количество ошибок. G>>4) И, как тебе вероятно известно, есть метрики "сложности". Это, например, Cyclomatic Complexity, которая косвенно характеризует количество тестов, необходимых для вылова тех самых ошибок, которые в п.3.
G>А как тут учитывается "сложность" связанная с необходимым объемом знания для написания кода.
Она учитывается _взаимосвязью_ элементарных метрик. Более того, вся эта "сложность" будет _наблюдаема_ по совокупности элементарных метрик, дополненных классификатором ошибок.
Объясняю. Если бы ты _вообще_ не совершал ошибок (честно попытайся представить себе такое), ты бы сразу годный исходный текст со скоростью машинистки печатал, и тебе не надо было бы его тестировать. Все время по сути тратится на поиск ошибок и путей их устранения.
Т.е. ошибаться будешь чаще, не имея необходимого знания. Ошибок будешь больше исправлять. Времени в результате больше потратишь. Возможно, сдуру нафигачишь больше кода, чем было бы со знаниями и опытом. И потому — сделаешь еще больше ошибок, и потратишь еще больше времени.
G>Гипотетический пример — написать парсер языка без специальных инструментов. Влоб такая задача решается крайне плохо, используя некоторые теоретически знания — гораздо лучше.
Знание позволяет делать меньше ошибок. А если ошибок совсем не будет, то что? Правильно — со скоростью машинистки.
G>Многие современные языки как раз торгуют объем-время на эту самую сложность понимания.
Это к делу не относится. Что вы все к элементарным метрикам цепляетесь? Сами по себе они ничего не значат, — они наблюдаемы и объективно измеримы, в этом вся их суть. Смысла потаенного в них нет, не надо его искать.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>Вот эти 3 метрики + количество строк кода дают вполне пригодную оценку "качества кода", при минимизации метрик качество растет.
IT>Ну допустим мы получили три числа: 25, 42 и 18. Что с ними дальше делать?
Считать производные метрики, сравнивать с историей по предыдущим проектам, делать выводы, принимать решения.
IT>>>Чего — например, ООП. Можно квантануть до наследования, инкапсуляция, полиморфизм. Какова будет метрика? G>>Связность.
IT>Связность может быть сильная, а может быть слабая. Я вовсе не против этого, но это не количественная метрика.
Это совсем несложно выразить в виде количественной метрики, посчитав количество связей.
IT>>>Разная у всех не только сложность понимания, но ещё и обучаемость и предел алгоритмической сложности. Это всё тоже нужно как-то включать в формальное определение. G>>Субъективные факторы, типа сложности обучения, лучше не учитывать в формальных выкладках.
IT>Ну да. А может лучше сразу не заниматься такой бесполезной фигнёй как формальные выкладки?
Бесполезной фигней являются общие рассуждения о "сложности". Никаких полезных выводов из этого сделать нельзя. You can't control what you can't measure.
T>>>>Это исследование надо проводить, на это я пойтить не могу. IT>>>А зря. G>>Не очень получится, в зависимости от задачи одни метрики могут быть более приоритетные, чем другие.
IT>Включи в свои формулы приоритетность, в чём проблема?
Здравствуйте, IT, Вы писали:
T>>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, поэтому не можешь сформулировать и закона сохранения
IT>Не определил по одной простой причине — её не существует.
По одной простой причине — ты не настолько хорошо понимаешь проблему, чтобы определить количественную меру.
T>>Хотя бы сложность по Колмогорову упомянул, что ли.
IT>Блин, ещё один измеряльщик. Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста.
Техника работы с метриками основана на измерениях, сравнениях, анализе истории и поиске статистических закономерностей, а не "универсальных формулах для любого программиста". Последнее — глупость.
Для твоего случая — время на объем, плюс процентная раскладка времени на каждый этап. Вводи по очереди разные факторы, и проведи статистическое исследование, если тебе интересно. Мне предложенное тобой сравнение кажется лишенным какой-ли практической пользы. Так, абстрактное умствование.
Здравствуйте, Sinclair, Вы писали:
M>>Так бы и продолжалось дальше, но увы, экспоненциальное развитие скорости компьютеров практически закончилось. И просто увеличение количества уровней абстракции (вроде применения более высокоуровневых языков программирования) уже не поможет — железо не потянет. S>И это тоже неправда. Простой пример: запись вида int a = b + c / d — e; находится на совсем другом уровне абстракции, чем набор из mov EAX, .... Тем не менее, производительность программы будет ничуть не хуже.
Более того. На современных суперскалярно-конвейерных процах производительность будет на практике не то что не хуже, а лучше.
Пример про то, как тупенький gcc компилирует два подряд идущих умножения для тупенького MIPS я уже раньше приводил. Одно делается как умножение, второе — на сдвигах-сложениях. Выполняется такое _быстрее_.
Здравствуйте, Gaperton, Вы писали:
G>>>1) Объем. В строках кода, количестве классов, количестве функций — это не принципиально. Это — объем. IT>>А что даёт такая метрика? G>Дает объективную характеристику объема кода.
Был у меня один случай лет пять назад. В Банке Оф Америка. Достался мне в наследство один недавно начатый проект от одного индуса. Объёма кода море, баги, глюки, тормоза, в общем всё как положено. После нескольких недель рефакторинга объём рукописного кода сократился раз в пять, баги, глюки, тормоза куда-то сами собой подевались, а тот же самый объём кода был достигнут только месяца через четыре, когда проект представлял собой уже не просто демку из формочек, а приложение под завяз напичканое функционалом.
С тех пор веру в объём кода как в объективную характеристику я окончательно потерял. Да и в дальнейшем не раз приходилось в этом убеждаться. Сейчас, кстати, работаю над проектом, вротой его версией. Искренне надеюсь, что удастся сократить объём кода раза в два по сравнению с первой версией.
G>А еще — дает неплохие корелляции с количеством ошибок и временем, для каждого отдельно взятого Васи, и Коли.
Количество ошибок безусловно как-то коррелирует с объёмом кода, но гораздо сильнее оно коррелирует с количеством мозгов у ошибающегося.
G>>>2) Время. С этим вопросов нет, не так-ли? IT>>Вопрос. Что даст такая метрика без учёта способностей Васи и Коли? G>Такая метрика объективно даст время решения задачи Васей и Колей. Никакого учета их способностей для измерения времени, которое они на задачу потратят, очевидно, не требуется.
Т.е. это постфактум?
IT>>А что такое трудоёмкость? G>Штука такая, сводится к оценка объема работы в человекочасах. Очевидно, определяется сочетанием задачи и человека. Парадокс? Наверное, только для программистов.
Есть такая штука... точнее была когда-то в СССР, сейчас уже не уверен — сметные нормы на строительные работы, которые всячески пытались учитывать производительность труда. Так вот, правильные командиры и мастера строй-отрядов абсолютно безошибочно выбирали для отряда те виды работ, которые наиболее хорошо оплачивались при минимальных затратах ресурсов, учитывая особенности конкретных бойцов. Неправильные командиры брались за любую работу. В результате при примерно одинаково выполненных объёмах работ и человекочасах зарплата в разных отрядах отличалась в разы. Хотя делалось всё по одним сметным нормам, учитывающим одну и туже производительность труда.
Под ресурсами здесь, кстати, понимается в основном грубая физическая сила имеющихся в наличии индивидуумов. Мы же здесь толкуем о работе мозгами. Если бы мы тогда работали мозгами, то разница была бы не в разы, а на порядки.
Такая вот оценка производительности труда. Над которой, кстати, трудились много учёных и прочих специалистов из разных научных заведений и ведомств.
G>>>Вот и вся "сложность". Все, как видишь, очень просто. IT>>Даже слишком просто. G>Ты слишком много уделил внимания вводной части, в которой просто перечислялись известные объективные метрики, и пропустил часть, в которой была суть.
Ты плохо читал статью. Я тщательно старался избегать любое упоминание о каких бы то ни было метриках. Метрики нужны менеджерам, особенно плохим, им без них никак. Мне метрики не нужны, мне нужно распознать и предотвратить появление проблемных мест в приложении. А для этого мне вполне достаточно вещей вроде "больше"/"меньше".
IT>>Мало знать, что один код сложнее, чем другой. Сам по себе этот факт с практической точки зрения совершенно не интересен. G>Мысль в моем комментарии чуточку посложнее этой банальщины. Но не понял, и ладно.
Сложность твоей мысли из той же серии что и сложность в доставшемся мне проекте, о котором я говорил выше. Если её (мысль) правильно отрефакторить, то возможно она станет простой и понятной не только одному тебе. И возможно, у неё даже будет шанс когда-нибудь стать банальной
Если нам не помогут, то мы тоже никого не пощадим.
IT>А что такое трудоёмкость? Мы её будем мерять в человеках? А может гораздо точнее будет в Васях или Колях?
С Васями и Колями хорошо, когда у тебя есть один Вася и один Коля и ты интуитивно представляешь, что будет за результат если каждый возьмется за работу.
А для случаев более серьезных, придется искать способ численно выразить Васю чрез Колю, потому ты снова приходишь к численным характеристикам.
Здравствуйте, IT, Вы писали:
IT>С тех пор веру в объём кода как в объективную характеристику я окончательно потерял. Да и в дальнейшем не раз приходилось в этом убеждаться. Сейчас, кстати, работаю над проектом, вротой его версией. Искренне надеюсь, что удастся сократить объём кода раза в два по сравнению с первой версией.
А что ты хочешь от такой метрика как количество строк кода ? Сама по себе она почти ничего не значит.
С численными характеристиками одна проблема, их нельзя рассматривать по отдельности.
Нужна оценочная функция, которая у тебя вобщем то уже есть, только ьы пользуешься ею интуитивно.
IT>Количество ошибок безусловно как-то коррелирует с объёмом кода, но гораздо сильнее оно коррелирует с количеством мозгов у ошибающегося.
Если когда нибудь можно будет измерить характеристи мозга, динамику из изменения, то можно будет пользоваться именно этим способом.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, AndrewVK, Вы писали:
AVK>>Маленькое дополнение. То, что ты называешь IQ-сложностью стоит разделить на два вида: AVK>>1) Алгоритмическая сложность. Т.е. сложность логики, алгоритмов. Она, собственно, напрямую определяется той логикой, которая в итоге реализуется программой. AVK>>2) Структурная сложность. Т.е. сложность архитектуры программы, структуры обрабатываемых данных, сложности, количества и противоречивости требований.
IT>Пожалуй это будет тем самым недостающим кирпичиком
Самое большое влияние на алгоритм и его сложность оказывает выбор концепции. При не правильно выбраной концепции сложность может оказаться и бесконечной. Классическая ситуация разбор текста вручную (я называю такое написание программ "в длинну") If-ами или парсером. Пусть даже самодельным. И качество и сложность программы даже трудно сравнивать. В длину вроде проще писать, но результат очень "тупой" и не гибкий. С другой стороны написать парсер.. Не то, что бы проще..Но в опытных руках окажется быстрее. Ну, вообщем понятно.
И заканчивается оочень печально и потом начинается поиск крайних 
Если нам не помогут, то мы тоже никого не пощадим.
