Здравствуйте, gandjustas, Вы писали:
G>>>Ну так поробуй формализовать понятия "не делать ошибок" и "заведомо плохие варианты", получишь те самые метрики. IT>>Я не знаю как формализуются понятия "не делать ошибок" и "заведомо плохие варианты". G>Ну если можешь оценить — видимо знаешь.
Оценить на больше меньше, наверное, могу. Формализовать, чтобы получить метрики — сомневаюсь.
IT>>Вообще-то речь не о планировании, а о выборе наиболее оптимального варианта. G>Что значит "оптимального"? Критерий "оптимальности" приведи.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>>>Ну так поробуй формализовать понятия "не делать ошибок" и "заведомо плохие варианты", получишь те самые метрики. IT>>>Я не знаю как формализуются понятия "не делать ошибок" и "заведомо плохие варианты". G>>Ну если можешь оценить — видимо знаешь.
IT>Оценить на больше меньше, наверное, могу.
Отлично. Что будешь оценивать на "больше меньше" для понятий "не делать ошибок" и "заведомо плохие варианты".
IT>Формализовать, чтобы получить метрики — сомневаюсь.
Поможем
IT>>>Вообще-то речь не о планировании, а о выборе наиболее оптимального варианта. G>>Что значит "оптимального"? Критерий "оптимальности" приведи.
IT>Наиболее приемлемый, самый благоприятный, наилучший для чего-либо.
Спасибо, КО. А критерий оптимальности варианта в твоем случае.
Здравствуйте, gandjustas, Вы писали:
S_>>Почему LINQ for SQL не оправдал ожиданий MS (судя по всему ожидания были гораздо выше)? Наверно не из-за того что не смогли вовремя индуса вычислить который выпал из среднеквадратического отклонения по числу багов. И не из-за того что неправильно определили сроки. На пути образовался тупик, которого не было сразу видно. G>Мне кажется что Linq2SQL придумали как proof of concept для IQueryable, и потом забили потому что пытались развивать "взрослый ORM" EF, который в итоге еле дотянул до сугубо практичного Linq2SQL, построенного по принципу 80\20.
Дело вобщем не в функционале. Реально основная масса девелоперов кроме как императивно, мыслить не могут, не хотят и сопротивляются.
G>Например надо разработать GIS. Простенькую, без кучи слоев. WPF или WinForm и почему?
У меня, например, простенькая у меня уже есть, я бы взял винформс потому что она уже винформс
Если переписывать заново, буде для этого причины какие то, я бы _попробовал_ ВПФ, тупо потому, что следить за кликами, отрисовкой мелкой, проще на ВПФ.
За исключением ввода и рендеринга разницы почти что нет, разве что асинхронную хрень и разные подлые биндинги лучшед елать на ВПФ но это уже не совсем простенькая
Здравствуйте, Ikemefula, Вы писали:
G>>Например надо разработать GIS. Простенькую, без кучи слоев. WPF или WinForm и почему?
I>Если переписывать заново, буде для этого причины какие то, я бы _попробовал_ ВПФ, тупо потому, что следить за кликами, отрисовкой мелкой, проще на ВПФ.
Что значит "проще"? В чем эта простота выражается?
Здравствуйте, gandjustas, Вы писали:
I>>Если переписывать заново, буде для этого причины какие то, я бы _попробовал_ ВПФ, тупо потому, что следить за кликами, отрисовкой мелкой, проще на ВПФ. G>Что значит "проще"? В чем эта простота выражается?
Проще значит
1. готовый функционал
2. отсутствие побочных эффектов, как например косяки GDI+
3. отсутствие некоторых рисков, например в случае с GDI+ для решения некоторых проблем, как z-bufer, может понадобиться вагон времени
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Если переписывать заново, буде для этого причины какие то, я бы _попробовал_ ВПФ, тупо потому, что следить за кликами, отрисовкой мелкой, проще на ВПФ. G>>Что значит "проще"? В чем эта простота выражается?
I>Проще значит
I>1. готовый функционал I>2. отсутствие побочных эффектов, как например косяки GDI+ I>3. отсутствие некоторых рисков, например в случае с GDI+ для решения некоторых проблем, как z-bufer, может понадобиться вагон времени
Ну вот уже напрашиваются метрики: время выполнения и количество багов. Причем не важны абсолютные цифры, важно что ты можешь подходы упорядочить по этим метрикам.
Здравствуйте, Silver_s, Вы писали:
I>>Вообще говоря дело именно в том, сколько ошибок на единицу кода делает основная масса программистов. I>>Косяки и возможности фреймворков — это уже второстепенное.
S_> Неправильный выбор фреймворка или библиотеки, или крупные архитектурные ошибки, это к тем же ошибкам причисляется о которых идет речь? Или механические ошибки-описки имеются ввиду?
Да вобщем то нет разницы. Разница между этими ошибками всего лишь в цене вопроса. Т.е. все ошибки можно привести к общему знаменателю чз оную цену.
Здравствуйте, gandjustas, Вы писали:
IT>>Оценить на больше меньше, наверное, могу. G>Отлично. Что будешь оценивать на "больше меньше" для понятий "не делать ошибок" и "заведомо плохие варианты".
Буду оценивать предыдущий опыт и анализировать какие из используемых решений приводят к наименьшему количеству проблем.
IT>>Формализовать, чтобы получить метрики — сомневаюсь. G>Поможем
Здравствуйте, gandjustas, Вы писали:
G>Ну вот уже напрашиваются метрики: время выполнения и количество багов. Причем не важны абсолютные цифры, важно что ты можешь подходы упорядочить по этим метрикам.
Как можно упорядочить баги, если один является орфографической ошибкой в строке и требует 2 секунды на фикс, а другой является следствием архитектурной ошибки и требует для фикса переписать 2/3 приложения?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
S_>>Там было про график работ, распределение задач, оценку производительности, управление сроками. G>А откуда планирование загруженности взял?
Ничего ниоткуда не брал. Просто все это обозвал (наверное ругательным выражением) планирование и оптимизация загрузки производственного конвеера.
Поскольку вопросы о внутренности приложения практически не затрагиваются. А больше вопросы на тему кто будет делать за сколько дней и сколько будет багов.
S_>>А если это все неактуально, а нужно в первую очередь узнать нужно ли вобще такую-то задачу решать, или лучше совсем другую. G>Как это относится к теме разговора?
К теме о сроках это относится мало. Но к вопросам о сложностях софтостроения это имеет прямое отношение. Если надо реализовать маленькую задачку с четкой спецификацией, ни шагу в сторону. Тогда конечно можно сказать — есть ли смысл в этой задачке или фигня какая-то никому не нужная, это все проблемы заказчика. Раз заказал пусть сам и расхлебывает. Наше дело написать и забыть.
S_>>[описание недостатков WPF] G>Меня это мало интересует. Меня больше инетресует основываясь на чем ты будешь делать выбор.
Выбор лучше делать на основе "описания недостатков WPF", можно еще взять "описание достоинств". Хотя в предыдущем посте у меня было скорее не полное описание недостатков, а просто предположения откуда у WPF тормоза и почему его было сложно сделать без тормозов.
Да что WPF, он уже написан кем-то. А когда сам пишешь, приходится самому и подбирать и оптимизировать эти списки недостатков и достоинств. (от списка недостатков полностью избавиться не получится)
G>Например надо разработать GIS. Простенькую, без кучи слоев. WPF или WinForm и почему?
Если эта GIS с довольно простым GUI, что даже сошел бы и веб интерфейс на j скриптах и html, то можно и на WPF.
Но GIS это на та система, где куча форм которые надо быстро нашлепать. И механизмы data binding, Layouts,XAML много времени врядли сэкономят — уже несколько достоинств WPF не так востребованы в таком приложении.
Если что-то более сложное и с рисованием. Лично для меня(раз там "ты" жирно выделено) к сожалению пока WPF очень непрозрачный. Если риски на мне висят, то не рискнул бы связываться с WPF. Взял бы WinForms+Direct2D(D2D можно добавить если не напрягает ограничение на Windows 7). Работы может это прибавит, но меньше риск попасть в засаду, когда наполовину сделаное отправится в помойку. Может это от недостаточного знания WPF, может от недостатков WPF.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
IT>>>Оценить на больше меньше, наверное, могу. G>>Отлично. Что будешь оценивать на "больше меньше" для понятий "не делать ошибок" и "заведомо плохие варианты".
IT>Буду оценивать предыдущий опыт и анализировать какие из используемых решений приводят к наименьшему количеству проблем.
То есть как минимум минимизировать баги, возможно еще какие-то метрики.
IT>>>Наиболее приемлемый, самый благоприятный, наилучший для чего-либо. G>>Спасибо, КО. А критерий оптимальности варианта в твоем случае. IT>Вариант, который по сумме всех критериев, устраивает меня больше других.
Вот уже лучше. Критерии == метрики.
Что за критерии?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>Ну вот уже напрашиваются метрики: время выполнения и количество багов. Причем не важны абсолютные цифры, важно что ты можешь подходы упорядочить по этим метрикам.
IT>Как можно упорядочить баги, если один является орфографической ошибкой в строке и требует 2 секунды на фикс, а другой является следствием архитектурной ошибки и требует для фикса переписать 2/3 приложения?
Можно считать взвешенную сумму.
Гапертон уже говорил что базовые метрики мало что дают, а вот производные уже позволяют делать выводы.
Кстати орфографическая ошибка это даже не баг. Баги считаются когда их найдут тестеры или пользователи, то что исправляет на месте программист до того как другие увидят результат его работы — не баг.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Gaperton, Вы писали:
G>>Вот у тебя кусок кода. У него "высокая сложность", что означает крайне дорогие правки в этот код, даже если правки сами по себе незначительные. Но! Код отлажен, изолирован за годными интерфейсами, отлично работает, и никаких правок туда в ближайшие 5 лет не ожидается. G>>Тебя волнует его сложность? Ты будешь тратить время на то, чтобы его "рефакторить", понижая "сложность"?
IT>О, блин! Только что ответил выше Повторюсь здесь. Да, буду править, если сложность восприятия этого кода будет для меня проблемой. Сразу оговорюсь, буду править не потому, что заглядывая в него я буду тратить лишнее время (ты же всё равно к этому всё сведёшь, правильно ), а потому что я очень расстраиваюсь, когда вижу плохой код и моё хорошее настроение мне дороже любого времени.
Совать руки в отлаженный работающий механизм, куда не ожидаются правки, внося туда новые баги, просто потому, что случайно заглянул туда не в том настроении?
Здравствуйте, Gaperton, Вы писали:
IT>>О, блин! Только что ответил выше Повторюсь здесь. Да, буду править, если сложность восприятия этого кода будет для меня проблемой. Сразу оговорюсь, буду править не потому, что заглядывая в него я буду тратить лишнее время (ты же всё равно к этому всё сведёшь, правильно ), а потому что я очень расстраиваюсь, когда вижу плохой код и моё хорошее настроение мне дороже любого времени.
G>Совать руки в отлаженный работающий механизм, куда не ожидаются правки, внося туда новые баги, просто потому, что случайно заглянул туда не в том настроении?
Бывает, что время на то, чтобы разобраться в отлаженном работающем механизме требуется больше, чем время чтобы его нормально переписать, отладить, откоментировать и обложить тестами.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gaperton, Вы писали:
G>Вот у тебя кусок кода. У него "высокая сложность", что означает крайне дорогие правки в этот код, даже если правки сами по себе незначительные. Но! Код отлажен, изолирован за годными интерфейсами, отлично работает, и никаких правок туда в ближайшие 5 лет не ожидается. G>Тебя волнует его сложность? Ты будешь тратить время на то, чтобы его "рефакторить", понижая "сложность"?
Вообще говоря — да.
Код не должен просто работать.
Если в код никто не лазит, то, как правило, его никто и не знает, следовательно, никто не знает ни возможностей, ни особенностей этого кода.
Следовательно, новый функционал с большой вероятностью будет дублировать уже имеющийся.
ПОтому код надо пересматривать регулярно. А если у кода "высокая сложность", то обычно с этого все и начинается.
Как правило, корень проблем, на мой взгляд, это как раз код который работает годами и туда никто не лазит
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Все генераторы парсеров учитывают ассоциативность, что в этом случае делает твой?
AVK>Генераторы парсеров обычно никакой ассоциативности не учитывают. Ассоциативность задается грамматикой.
А генераторы на вход что получают?
Мы видимо об одном и том же разными словами говорим.
Здравствуйте, Ikemefula, Вы писали:
G>>Вот у тебя кусок кода. У него "высокая сложность", что означает крайне дорогие правки в этот код, даже если правки сами по себе незначительные. Но! Код отлажен, изолирован за годными интерфейсами, отлично работает, и никаких правок туда в ближайшие 5 лет не ожидается. G>>Тебя волнует его сложность? Ты будешь тратить время на то, чтобы его "рефакторить", понижая "сложность"?
I>Вообще говоря — да.
I>Код не должен просто работать.
Код должен просто работать. Когда у тебя возникает _резон_ вносить туда правку, ты можешь рассматривать его рефакторинг.
I>Если в код никто не лазит, то, как правило, его никто и не знает, следовательно, никто не знает ни возможностей, ни особенностей этого кода.
Вообрази ситуацию, что твоему продукту 10 лет, и объем исходников составляет миллион строк кода, и он при этом постоянно развивается. Систему такого объема один человек не в состоянии понимать и удерживать в голове целиком, и ситуация, когда ты знаком и работаешь с ее фрагментом — естественна.
Нет ни необходимости, ни практической возможности лазить в места, которые давно написаны, отлажены, и отлично работают. У тебя на практике не будет на это ни времени, ни возможности — рефакторинг такого кода слишком сложен и затратен, чтобы делать его пробегая мимо. Тому, кто так будет делать, коллеги с тестерами довольно быстро руки вырвут.
I>Следовательно, новый функционал с большой вероятностью будет дублировать уже имеющийся.
Не следует, и не будет. Ни единого резона на то нет. С какого дуба очередь коллцентра должна дублировать хоть что-то из функциональности перевода звонка? У тебя это просто не получится.
Для меня вообще загадка, о каких системах вы думаете, когда говорите подобное.
I>ПОтому код надо пересматривать регулярно. А если у кода "высокая сложность", то обычно с этого все и начинается.
Скорость просмотра незнакомого кода, на которой ты в состоянии более-менее его понять, и найти там какие-то ошибки — 200 строк кода в час. Это измеренный темп кодревью свежего (т.е. довольно неплохого) кода. Переписывание обойдется куда дороже.
Теперь. У тебя миллион строк, из которого активная разработка затрагивает, допустим, 200 тысяч строк. Остальной код — стабилен, и там иногда находят баги.
И у тебя, естественно, полный бэклог багов и фич, на год вперед, и жопа в мыле. Валяй, считай, сколько времени ты готов потратить на "просматривание" остальных 800 тысяч.
Знаешь, от программеров всего ожидать можно, но от тебя не ожидал. Я ведь типовую ситуацию описываю, не какую-нибудь экзотику.
I>Как правило, корень проблем, на мой взгляд, это как раз код который работает годами и туда никто не лазит
Это нормальная ситуация, и ты никуда от нее не денешься — хочешь или не хочешь.
Если нам не помогут, то мы тоже никого не пощадим.
