Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, hrg, Вы писали:
hrg>>Преложи еще способ достоверно убедиться, что ты не накосячил при hrg>>рефакторинге?
VD>Провести его с помощью средств гаратнитующих это. Собственно об этом я с самого начала и говорил.
VD>Более того. Тут уже не раз поднимался вопрос о применимости юнит-тестов для разных областей программирования и вроде как пришли к общему мнению, что юнит-тесты пригодны далеко не везде. Например, в создании компиляторов они довольно бесполезны. А вот автоматизация и обычное тестирование дает хорошие результаты.
Средства — не телепаты, что имелось в виду при написани кода они не знают. При рефакторинге могут быть допущены ошибки в бизнес-логике. Юнит тесты это легко накроют.
Что они не везде применимы — это правда, но это не повод сбрасывать их со счета.
Автоматический рефакторинг — свойство среды, а не языка. C# в своей второй эпостаси вовсю приблежается к C++ — уже и generic'и введены. Скоро он C++ по сложности не только догонит, но скорее всего и перегонит. Однако поддержку рефакторинга никто из инструментов убирать не спешит. Поскольку C++ не менее популярен чем C# то думаю вопрос о появлении средств для автоматического рефакторинга кода для него — вопрос времени, причём относительно не большого.
Здравствуйте, hrg, Вы писали:
hrg>После причесывания тоже тестирование?
Незачем. Ни одно сбоя ни разу небыло. Автоматизированные средства обеспечивают качество. Ну, а тестирование и так постоянно производится. Но не модульное, а обычное. Открыл проектик по больше и вот тебе тест (парсер все таки).
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, StanislavK, Вы писали:
SK>Средства — не телепаты, что имелось в виду при написани кода они не знают. При рефакторинге могут быть допущены ошибки в бизнес-логике. Юнит тесты это легко накроют. SK>Что они не везде применимы — это правда, но это не повод сбрасывать их со счета.
Чтобы не повторяться...
VD>>Провести его с помощью средств гаратнитующих это. Собственно об этом я с самого начала и говорил.
VD>>Более того. Тут уже не раз поднимался вопрос о применимости юнит-тестов для разных областей программирования и вроде как пришли к общему мнению, что юнит-тесты пригодны далеко не везде. Например, в создании компиляторов они довольно бесполезны. А вот автоматизация и обычное тестирование дает хорошие результаты.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hrg, Вы писали:
V>> Дык гарантии дают только в сбербанке. 98-ой понминшь?
hrg>Я конечно могу ошибаться, но если рассмотреть проблему со всех сторон, а hrg>также принять во внимание всевозможные поправки, то с определенной долей hrg>вероятности, учитывая все факторы, можно сделать предположение, что оппонент hrg>увел разговор от главной темы (гонит ).
Ну, если намек не понятен, скажу открытым текстом. Юнит-тесты тоже 100%-ой гарантии дать не могут. Подними тему посвещенную юнит-тестам и погляди обсуждение. Там даже полные фанаты сошлись, что применение юнит-тестов для проверки компиляторов занятие для камикадзе. То что ты с ними дальше бизнес-объектов не отходил еще не значит, что они применимы всюду.
Представь себе компилятор. Все множество конструкций языка можно представить в идве набора приблизительно 160 классов. Но их комбинации дают комбинаторный взрыв и чтобы описать все мыслемые и не мыслимые конструкции (а проверять нужно и ошибки) потребуется вся жизнь, а то и сумма жизней небольшой страны. При этом есть море кода на котором можно легко проверить 99% случаев. А остальные прийдут из багрепортов. Так что вместо юнит тесто проще програть парсер по доступному коду. Вся методология юнит-тестов тут идет лесом, так как достаточно просто брость тестовые файлы в один каталон и натравить на них парсер.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, serg_mo, Вы писали:
_>Здравствуйте, VladD2, Вы писали:
VD>>Дык гарантии дают только в сбербанке. 98-ой понминшь?
_>Э, ну я все-таки стараюсь не подражать этой глубоко прогнившей конторе и давать более правдоподобные гарантии .
Да контора то ничего. Вот только 100% гарантии нигде не бывает. Я к тому, что в некоторых областях можно создать набор тестов который покрывает основную массу проблем. А где-то невозможно физически. В итге гарантия — это всего лишь большая или меньшая вероятность.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Автоматический рефакторинг — свойство среды, а не языка.
Дык среда сама по себе является от части свойством языка.
AF> C# в своей второй эпостаси вовсю приблежается к C++ — уже и generic'и введены.
Э... мы тут уже выяснили, что по некоторым критериям сложности С++ проще чем Шарп. Только для создания средств рефакторинга важны отдельные критерии влияющие на такие банальные критерии как сложность и скорость. Так вот для рефакторинга нужно очень качественное разрешение имен, а этот процесс для С++ очень сложне и ресурсоемок. Граматика и семантика Шарпа написана так, чтобы минимизировать эти факторы. Так любая неоднозначность в языке четко описана в стандарте и даны простые пути решения этих неоднозначностей. Области видимости, модульность и многие другие аспекты специально внедрены в язык (и от части в платформу) для того, чтобы не наступить на грабли С++.
AF> Скоро он C++ по сложности не только догонит, но скорее всего и перегонит.
Тут дело не в сложности. Тут дело в безпроблемности. А тут тут С++ догнать еще долго догнать неудастся.
Скорее процессоры вырастут до тех вершин, что рефакторинг С++ станет не таким уж и трудным делом.
Потенциально конечно никаких проблем нет. Но сложность этой задачи очень велика.
AF> Однако поддержку рефакторинга никто из инструментов убирать не спешит. Поскольку C++ не менее популярен чем C# то думаю вопрос о появлении средств для автоматического рефакторинга кода для него — вопрос времени, причём относительно не большого.
Я бы сказал так. Вопрос времени и необходимости. В принципе конечно задача решаемая. Нужно только найти желающих убить на это кучу времени.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> AF>Автоматический рефакторинг — свойство среды, а не языка.
> Дык среда сама по себе является от части свойством языка.
-1
> AF> Однако поддержку рефакторинга никто из инструментов убирать не спешит. Поскольку C++ не менее популярен чем C# то думаю вопрос о появлении средств для автоматического рефакторинга кода для него — вопрос времени, причём относительно не большого.
> Я бы сказал так. Вопрос времени и необходимости. В принципе конечно задача решаемая. Нужно только найти желающих убить на это кучу времени.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> AF>Автоматический рефакторинг — свойство среды, а не языка.
>> Дык среда сама по себе является от части свойством языка.
ПК>-1
На самом деле прав человек. После того как пересел с С++ на java, я это ощутил.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, hrg, Вы писали:
hrg>>После причесывания тоже тестирование?
VD>Незачем. Ни одно сбоя ни разу небыло. Автоматизированные средства обеспечивают качество. Ну, а тестирование и так постоянно производится. Но не модульное, а обычное. Открыл проектик по больше и вот тебе тест (парсер все таки).
1. А как ты определяешь, что он это "проект побольше" именно правильно распарсил?
2. А как же диагностика синтаксических ошибок? То что, парсер сработал на априори валидном документе это ж ещё полдела, может там при малейшей ошибке NullReferencы начнут сыпаться пачками...
Оба правы.
Павел — в том, что задача уже решена и думаю скоро окажется обычным свойством средств разработки на C++. И её сложность отнюдь не так велика, как описал её Влад. Всё таки C++ — это не "естественный язык".
Влад — прав в том, что в C# (да и Java тоже) — многие проблемные вещи решены, что делает рефакторинг для данных языков более простым и естественным.
НО! При появлении каждого языка — всегда начиналось с плясок с саблями, по поводу новых возможностей, которые он привносит и проблем — которые он решает. Потом — если язык оказывается успешным — в него добавляются новые фичи, которые порождают новые проблемы — эволюционные — частенько уже на более высоком уровне, а иногда и на том же самом. И вся история программирования — сплошное тому подтверждение. И ни одному языку — будь то C# или Java — этих проблем не избежать.
А рефакторинг — это такая штука — которая может применяться практически на любом логическом уровне — и если на уровне системы команд ЦП её научились делать давно (это называется оптимизацией при компиляции кода) — то вот на уровне даже простых конструкций в исходном коде — научились делать совсем недавно — в последние 5 лет, а возможно — и того меньше. А ведь есть ещё куча архитектурных уровней...
Здравствуйте, VladD2, Вы писали:
VD>Да контора то ничего. Вот только 100% гарантии нигде не бывает. Я к тому, что в некоторых областях можно создать набор тестов который покрывает основную массу проблем. А где-то невозможно физически. В итге гарантия — это всего лишь большая или меньшая вероятность.
Посмотрел на ветку и заметил, что мы как-то отошли от начального предмета: рефакторинг и С++. Возвращаясь к вопросу, выскажу свое мнение: не вижу препятствий к проведению рефакторинга в проектах на С++. Да, вследствие отсутствия автоматизированных средств рефакторинг: 1) треюует больших трудовых затрат и 2)есть больший риск внесения ошибок.
Трудовые затраты можно снизить, если сделать рефакторинг неотъемлемым процессом разработки. В самом деле, ведь средства рефакторинга предлагают в основном автоматизацию простых рефакторингов (уровня Rename <something> или Extract Method), и проведение таких рефакторингов вручную не представляет большой сложности, если не запускать этот процесс.
Риск внесения ошибок также может быть сведен к минимуму, если проект имеет хорошее покрытие unit-тестами. Тут, на мой взгляд, (имеющиеся на сегодняшний день) автоматизированные средства играют меньшую роль, особенно в статически типизированных языках.
Безусловно, существуют проекты, в которых юнит-тестирование затруднено или вообще невозможно.
Более того, в одном проекте могут существовать плохо поддающиеся unit-тестам части (пример — UI).
В этом случае, видимо, придется делать акцент на приемочном (интегральном) тестировании работающей программы целиком.
Здравствуйте, eugals, Вы писали:
E>1. А как ты определяешь, что он это "проект побольше" именно правильно распарсил?
Пока визуально. Дальше будем компилировать сгенерированный код. Это тоже не 100%, но очень неплохая проверка.
E>2. А как же диагностика синтаксических ошибок? То что, парсер сработал на априори валидном документе это ж ещё полдела, может там при малейшей ошибке NullReferencы начнут сыпаться пачками...
Натравливаем на список стандартных ошибок (из Моно).
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, serg_mo, Вы писали:
_>Трудовые затраты можно снизить, если сделать рефакторинг неотъемлемым процессом разработки.
Да в том-то и дело, что сделать это можно только если от траха испытываешь исенное наслождение. Мне, например, не составляет труда рефакторить код с использованием автоматических средств, но на ручной рефакторинг я решаюсь с боьшим камнем на сердце.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
В смысле? Ты высказал тезис, что для C++ нет средств автоматизации рефакторинга, и не скоро появятся. Я привел контрпример. Средства есть, даже не одно. Есть и плагины к Visual Studio, и самостоятельные приложения. Выбирай, какое нравится.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК>Ты можешь найти в спецификации обсуждавшихся языков (C++ и C#) что-то о средах разработки?
> А надо? Я вижу среды, и понимаю почему для С++ они столь убоги, а для Шарпа и Явы наворочены.
Дык, это не делает их свойством (частью) языка. А среда VC++ от C# отличается весьма незначительно
>>> ПК>http://www.google.com/search?q=C%2B%2B+Refactoring
>>> Сам то этим пользовался?
> ПК> В смысле?
> В прямом.
Когда-то немного использовал SlickEdit. Но обычно мне если нужен, то более сложный рефакторинг, который автоматические средства делать не умеют.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали: VD>Да в том-то и дело, что сделать это можно только если от траха испытываешь исенное наслождение. Мне, например, не составляет труда рефакторить код с использованием автоматических средств, но на ручной рефакторинг я решаюсь с боьшим камнем на сердце.
Это точно. Самое противное, что тратится большое количество времени на совершенно нудную работу, в результате которой
а) нет удовлетворения, т.к. ничего нового софт уметь не стал.
б) где-то внутрях копошится червь сомнения — "а не сломал ли я чего ненароком?"
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Это точно. Самое противное, что тратится большое количество времени на совершенно нудную работу, в результате которой S>а) нет удовлетворения, т.к. ничего нового софт уметь не стал. S>б) где-то внутрях копошится червь сомнения — "а не сломал ли я чего ненароком?"
Э, народ, это вам кажется, что ручной рефакторинг — это трах, потому что вы знакомы с автоматизированными средствами. А если человек их в глаза не видел (как я например, когда только начинал рефакторинг применять), то эта нудная работа кажется совершенно естественной, и не представляешь, как может быть иначе . Мне, например, сильно помогало то, что я видел, что код становится лучше.
Но согласен, после того, как привыкнешь к автоматизации рутины, делая эти же операции вручную, начинаешь беситься
Однако поддержку рефакторинга никто из инструментов убирать не спешит. 
