VladD2 -> "Re[33]: Мэйнстрим vs. Самосовершенствование "
hrg>>Преложи еще способ достоверно убедиться, что ты не накосячил при hrg>>рефакторинге?
V> Провести его с помощью средств гаратнитующих это. Собственно об этом V> я с самого начала и говорил.
т.е. ты настолько доверяешь этим средствам, что готов не проверять за нимим
код?
V> Более того. Тут уже не раз поднимался вопрос о применимости V> юнит-тестов для разных областей программирования и вроде как пришли к V> общему мнению, что юнит-тесты пригодны далеко не везде. Например, в V> создании компиляторов они довольно бесполезны. А вот автоматизация и V> обычное тестирование дает хорошие результаты.
При таком подходе тестеры ласты склеят при частом рефакторинге
Yury Kopyl aka hrg | Любой служащий должен строго выполнять свои
обязанности. А практически каждый занимается на работе чем хочет. (с)
Паркинсон
Здравствуйте, Undying, Вы писали:
U>Т.е. рефакторинг ты не используешь? Т.к. рефакторинг как раз означает модифицирование кода с целью уменьшения имеющихся хаков (в частности "лишних" наследований) к минимуму.
Гы. ПК у нас С++-программист до мозга костей. А рефакторинг и С++ пока, что плохо совместимы. Так что плоды прогресса ему знакомы только по слухам.
VladD2 -> "Re[35]: Мэйнстрим vs. Самосовершенствование "
V> Здравствуйте, serg_mo, Вы писали:
_>>Виртуоз . Но гарантий корректности работы программы после _>>рефакторинга все равно дать не сможешь
V> Дык гарантии дают только в сбербанке. 98-ой понминшь?
Я конечно могу ошибаться, но если рассмотреть проблему со всех сторон, а
также принять во внимание всевозможные поправки, то с определенной долей
вероятности, учитывая все факторы, можно сделать предположение, что оппонент
увел разговор от главной темы (гонит ).
Yury Kopyl aka hrg | Любой служащий должен строго выполнять свои
обязанности. А практически каждый занимается на работе чем хочет. (с)
Паркинсон
Здравствуйте, VladD2, Вы писали:
U>>Т.е. рефакторинг ты не используешь? Т.к. рефакторинг как раз означает модифицирование кода с целью уменьшения имеющихся хаков (в частности "лишних" наследований) к минимуму.
VD>Гы. ПК у нас С++-программист до мозга костей. А рефакторинг и С++ пока, что плохо совместимы. Так что плоды прогресса ему знакомы только по слухам.
Может быть, ты имел в виду автоматизированный рефакторинг? Обычный рефакторинг "ручками" совместим с с любым ЯП, если, конечно, этот ЯП совместим с программированием
Здравствуйте, Sinclair, Вы писали:
S>Это точно. Самое противное, что тратится большое количество времени на совершенно нудную работу, в результате которой S>а) нет удовлетворения, т.к. ничего нового софт уметь не стал. S>б) где-то внутрях копошится червь сомнения — "а не сломал ли я чего ненароком?"
Э, народ, это вам кажется, что ручной рефакторинг — это трах, потому что вы знакомы с автоматизированными средствами. А если человек их в глаза не видел (как я например, когда только начинал рефакторинг применять), то эта нудная работа кажется совершенно естественной, и не представляешь, как может быть иначе . Мне, например, сильно помогало то, что я видел, что код становится лучше.
Но согласен, после того, как привыкнешь к автоматизации рутины, делая эти же операции вручную, начинаешь беситься
Здравствуйте, VladD2, Вы писали:
VD>Я вот как-то делаю.
Виртуоз . Но гарантий корректности работы программы после рефакторинга все равно дать не сможешь
_>>В конце концов, не все IDE имеют такие средства, а некоторые языки вообще IDE не имеют.
VD>Ну, это их проблемы. Я выбираю языки и среды в которых рефакторинг имеется. Ручной рефакторинг — это суровая необходимость нежели оправданный выбор. И лучше чтобы суровостей было по меньше.
Здравствуйте, VladD2, Вы писали:
VD>Провести его с помощью средств гаратнитующих это. Собственно об этом я с самого начала и говорил.
Ну, автоматизированы далеко не все рефакторинги, к сожалению.
VD>Более того. Тут уже не раз поднимался вопрос о применимости юнит-тестов для разных областей программирования и вроде как пришли к общему мнению, что юнит-тесты пригодны далеко не везде. Например, в создании компиляторов они довольно бесполезны. А вот автоматизация и обычное тестирование дает хорошие результаты.
Не буду спорить, компиляторы не разрабатывал. И я бы не стал полностью доверять "обычному" (т. е. ручному? ) тестированию, т. к. тестеры — это люди, и как все люди имеют право на ошибку, неточность, порой даже небрежность. Кроме того, вряд ли тестеры смогут проверить всю функциональность программы. Как уже говорилось в этой ветке — повесятся.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, hrg, Вы писали:
hrg>>Преложи еще способ достоверно убедиться, что ты не накосячил при hrg>>рефакторинге?
VD>Провести его с помощью средств гаратнитующих это. Собственно об этом я с самого начала и говорил.
VD>Более того. Тут уже не раз поднимался вопрос о применимости юнит-тестов для разных областей программирования и вроде как пришли к общему мнению, что юнит-тесты пригодны далеко не везде. Например, в создании компиляторов они довольно бесполезны. А вот автоматизация и обычное тестирование дает хорошие результаты.
Средства — не телепаты, что имелось в виду при написани кода они не знают. При рефакторинге могут быть допущены ошибки в бизнес-логике. Юнит тесты это легко накроют.
Что они не везде применимы — это правда, но это не повод сбрасывать их со счета.
VladD2,
> AF>Автоматический рефакторинг — свойство среды, а не языка.
> Дык среда сама по себе является от части свойством языка.
-1
> AF> Однако поддержку рефакторинга никто из инструментов убирать не спешит. Поскольку C++ не менее популярен чем C# то думаю вопрос о появлении средств для автоматического рефакторинга кода для него — вопрос времени, причём относительно не большого.
> Я бы сказал так. Вопрос времени и необходимости. В принципе конечно задача решаемая. Нужно только найти желающих убить на это кучу времени.
Здравствуйте, VladD2, Вы писали:
VD>Да контора то ничего. Вот только 100% гарантии нигде не бывает. Я к тому, что в некоторых областях можно создать набор тестов который покрывает основную массу проблем. А где-то невозможно физически. В итге гарантия — это всего лишь большая или меньшая вероятность.
Посмотрел на ветку и заметил, что мы как-то отошли от начального предмета: рефакторинг и С++. Возвращаясь к вопросу, выскажу свое мнение: не вижу препятствий к проведению рефакторинга в проектах на С++. Да, вследствие отсутствия автоматизированных средств рефакторинг: 1) треюует больших трудовых затрат и 2)есть больший риск внесения ошибок.
Трудовые затраты можно снизить, если сделать рефакторинг неотъемлемым процессом разработки. В самом деле, ведь средства рефакторинга предлагают в основном автоматизацию простых рефакторингов (уровня Rename <something> или Extract Method), и проведение таких рефакторингов вручную не представляет большой сложности, если не запускать этот процесс.
Риск внесения ошибок также может быть сведен к минимуму, если проект имеет хорошее покрытие unit-тестами. Тут, на мой взгляд, (имеющиеся на сегодняшний день) автоматизированные средства играют меньшую роль, особенно в статически типизированных языках.
Безусловно, существуют проекты, в которых юнит-тестирование затруднено или вообще невозможно.
Более того, в одном проекте могут существовать плохо поддающиеся unit-тестам части (пример — UI).
В этом случае, видимо, придется делать акцент на приемочном (интегральном) тестировании работающей программы целиком.
Здравствуйте, serg_mo, Вы писали:
VD>>Это закат солнца вручную. И тут вполне с ПК можно согласиться. Ручная модификация объемного кода — это верный способ зашиться и нафигачить ошибок.
_>А юнит-тесты на что?
Они как-то связаны с рефакторингом? Или мне нужно будет писать юнит тесты чтобы проверить качество рефакторинга?
VD>>То ли дело в Яве или Шарпе... выделил участок кода... выбрал вариант рефакторинга и через несколько секунд пол проекта изменено без единой ошибки. Крысотыща!
_>Я делал рефакторинг в достаточно крупных проектах на Delphi, без каких-либо инструментов автоматизации.
Сочувствую.
_> Было, конечно, достаточно много ручной работы, но вполне приемлемо.
Это приемлимость из серии раков на безрыбье.
_> Так что осутствие автоматизированных средств — не повод отказываться от рефакторинга.
Это повод, чтобы не рассматривать рефакторин в качестве основы творческого процесса, а рассматривать его как неотвратимое мучение.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
_>>А юнит-тесты на что?
VD>Они как-то связаны с рефакторингом? Или мне нужно будет писать юнит тесты чтобы проверить качество рефакторинга?
На мой взгляд, делать рефакторинг кода без наличия юнит-тестов довольно опасно. Да, можно сказать, что юнит-тесты проверяют качество рефакторинга — что в процессе рефакторинга не было внесено багов. Конечно, автоматизированные средства помогают проводить рефакторинг грамотно, но, во-первых, далеко не все рефакторинги автоматизированы, а во-вторых, даже самые простые из них могут быть источником ошибок.
_>> Было, конечно, достаточно много ручной работы, но вполне приемлемо.
VD>Это приемлимость из серии раков на безрыбье.
В конце концов, не все IDE имеют такие средства, а некоторые языки вообще IDE не имеют.
VD>Это повод, чтобы не рассматривать рефакторин в качестве основы творческого процесса, а рассматривать его как неотвратимое мучение.
Не знаю, у меня никогда такого ощущения не было. Наоборот, всегда было приятно видеть, как в процессе даже ручных манипуляций код становится лучше
Здравствуйте, hrg, Вы писали:
hrg>Преложи еще способ достоверно убедиться, что ты не накосячил при hrg>рефакторинге?
Провести его с помощью средств гаратнитующих это. Собственно об этом я с самого начала и говорил.
Более того. Тут уже не раз поднимался вопрос о применимости юнит-тестов для разных областей программирования и вроде как пришли к общему мнению, что юнит-тесты пригодны далеко не везде. Например, в создании компиляторов они довольно бесполезны. А вот автоматизация и обычное тестирование дает хорошие результаты.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, hrg, Вы писали:
hrg>>После причесывания тоже тестирование?
VD>Незачем. Ни одно сбоя ни разу небыло. Автоматизированные средства обеспечивают качество. Ну, а тестирование и так постоянно производится. Но не модульное, а обычное. Открыл проектик по больше и вот тебе тест (парсер все таки).
1. А как ты определяешь, что он это "проект побольше" именно правильно распарсил?
2. А как же диагностика синтаксических ошибок? То что, парсер сработал на априори валидном документе это ж ещё полдела, может там при малейшей ошибке NullReferencы начнут сыпаться пачками...
Здравствуйте, VladD2, Вы писали: VD>Да в том-то и дело, что сделать это можно только если от траха испытываешь исенное наслождение. Мне, например, не составляет труда рефакторить код с использованием автоматических средств, но на ручной рефакторинг я решаюсь с боьшим камнем на сердце.
Это точно. Самое противное, что тратится большое количество времени на совершенно нудную работу, в результате которой
а) нет удовлетворения, т.к. ничего нового софт уметь не стал.
б) где-то внутрях копошится червь сомнения — "а не сломал ли я чего ненароком?"
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, mihoshi, Вы писали:
M>Может быть, ты имел в виду автоматизированный рефакторинг? Обычный рефакторинг "ручками" совместим с с любым ЯП, если, конечно, этот ЯП совместим с программированием
Это закат солнца вручную. И тут вполне с ПК можно согласиться. Ручная модификация объемного кода — это верный способ зашиться и нафигачить ошибок. То ли дело в Яве или Шарпе... выделил участок кода... выбрал вариант рефакторинга и через несколько секунд пол проекта изменено без единой ошибки. Крысотыща!
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>То ли дело в Яве или Шарпе... выделил участок кода... выбрал вариант рефакторинга и через несколько секунд пол проекта изменено без единой ошибки. Крысотыща!
Хм, ты это о чем? Если ты о переименовании чего-либо, то с этим и в С++ проблем нет. Компилятор сам ткнет носом в каждое место, где надо поменять идентификатор. Какие тут могут быть ошибки?
А если ты о рефакторингах типа выделения метода, то я не понял, с чего это поменяется пол проекта?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, mihoshi, Вы писали:
M>>Может быть, ты имел в виду автоматизированный рефакторинг? Обычный рефакторинг "ручками" совместим с с любым ЯП, если, конечно, этот ЯП совместим с программированием
VD>Это закат солнца вручную. И тут вполне с ПК можно согласиться. Ручная модификация объемного кода — это верный способ зашиться и нафигачить ошибок.
А юнит-тесты на что?
VD>То ли дело в Яве или Шарпе... выделил участок кода... выбрал вариант рефакторинга и через несколько секунд пол проекта изменено без единой ошибки. Крысотыща!
Я делал рефакторинг в достаточно крупных проектах на Delphi, без каких-либо инструментов автоматизации. Было, конечно, достаточно много ручной работы, но вполне приемлемо. Так что осутствие автоматизированных средств — не повод отказываться от рефакторинга.
VladD2 -> "Re[31]: Мэйнстрим vs. Самосовершенствование "
VD>>>Это закат солнца вручную. И тут вполне с ПК можно согласиться. VD>>>Ручная модификация объемного кода — это верный способ зашиться и VD>>>нафигачить ошибок.
_>>А юнит-тесты на что?
V> Они как-то связаны с рефакторингом? Или мне нужно будет писать V> юнит тесты чтобы проверить качество рефакторинга?
Преложи еще способ достоверно убедиться, что ты не накосячил при
рефакторинге?
Здравствуйте, serg_mo, Вы писали:
_>На мой взгляд, делать рефакторинг кода без наличия юнит-тестов довольно опасно.
Я вот как-то делаю.
_>В конце концов, не все IDE имеют такие средства, а некоторые языки вообще IDE не имеют.
Ну, это их проблемы. Я выбираю языки и среды в которых рефакторинг имеется. Ручной рефакторинг — это суровая необходимость нежели оправданный выбор. И лучше чтобы суровостей было по меньше.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
_>Не буду спорить, компиляторы не разрабатывал. И я бы не стал полностью доверять "обычному" (т. е. ручному? ) тестированию, т. к. тестеры — это люди, и как все люди имеют право на ошибку, неточность, порой даже небрежность. Кроме того, вряд ли тестеры смогут проверить всю функциональность программы. Как уже говорилось в этой ветке — повесятся.
В том то все и дело, что есть задачи где делать тесты повесишся, но можно взять готовые. Для компилятора таким тестом является компиляция больших (чужих) проектов. Тоже вроде как автоматизированный тест.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 -> "Re[35]: Мэйнстрим vs. Самосовершенствование "
hrg>>При таком подходе тестеры ласты склеят при частом рефакторинге
V> Представь себе не клеятся. Иногда можно делать десяток мелких V> рефакторингов за день.
V> Более того. Я часто пишу код по схеме — продавливаем проблему как V> выходит, а затем причесываем код рефакторингом. Очень эффективно V> выходит.
Здравствуйте, VladD2, Вы писали:
_>>Не буду спорить, компиляторы не разрабатывал. И я бы не стал полностью доверять "обычному" (т. е. ручному? ) тестированию, т. к. тестеры — это люди, и как все люди имеют право на ошибку, неточность, порой даже небрежность. Кроме того, вряд ли тестеры смогут проверить всю функциональность программы. Как уже говорилось в этой ветке — повесятся.
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
На самом деле прав человек. После того как пересел с С++ на java, я это ощутил.
Оба правы.
Павел — в том, что задача уже решена и думаю скоро окажется обычным свойством средств разработки на C++. И её сложность отнюдь не так велика, как описал её Влад. Всё таки C++ — это не "естественный язык".
Влад — прав в том, что в C# (да и Java тоже) — многие проблемные вещи решены, что делает рефакторинг для данных языков более простым и естественным.
НО! При появлении каждого языка — всегда начиналось с плясок с саблями, по поводу новых возможностей, которые он привносит и проблем — которые он решает. Потом — если язык оказывается успешным — в него добавляются новые фичи, которые порождают новые проблемы — эволюционные — частенько уже на более высоком уровне, а иногда и на том же самом. И вся история программирования — сплошное тому подтверждение. И ни одному языку — будь то C# или Java — этих проблем не избежать.
А рефакторинг — это такая штука — которая может применяться практически на любом логическом уровне — и если на уровне системы команд ЦП её научились делать давно (это называется оптимизацией при компиляции кода) — то вот на уровне даже простых конструкций в исходном коде — научились делать совсем недавно — в последние 5 лет, а возможно — и того меньше. А ведь есть ещё куча архитектурных уровней...
Здравствуйте, 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
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, serg_mo, Вы писали: _>Э, народ, это вам кажется, что ручной рефакторинг — это трах, потому что вы знакомы с автоматизированными средствами.
Ну, вообще-то 100% рефакторинга, который я проводил — именно ручной. Еще в те времена, когда я и слова-то такого не знал. И задалбывал он меня совершенно не потому, что я жаждал автоматики. Я искренне полагал, что такой и быть не может.
(Офф: вспоминается мне, как я пытался устроиться на работу в 1997. Позвонил по вакансии программера на Клиппере. Как только я назвал возраст, дядя начал ныть про нехорошесть современной молодежи, которая окромя виндов ничего учить не хочет, а на самом деле клиппер это очень даже гуд и все такое прочее. Мои робкие попытки вставить хоть слово про то, что я весь этот клиппер исползал вдоль и поперек с 1991 по 1993 так, как этому дяде присниться не могло, услышаны не были. О чем я, по прошествии лет, не жалею. К чему это я? Да к тому, что не надо заранее предполагать, чем и до чего собеседник разбалован.)
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Дык, это не делает их свойством (частью) языка.
Это делает их следствием качества дизайна языка. Другими словами, эти языки специально проектировались, чтобы вещи вроде рефакторинга делались проще.
ПК> А среда VC++ от C# отличается весьма незначительно
Это для тех кто упорно не хочет разуть глаза.
ПК>Когда-то немного использовал SlickEdit. Но обычно мне если нужен, то более сложный рефакторинг, который автоматические средства делать не умеют.
Ну, ты скачай все же демку и сравни с тем же ReSharper-ом или VS2005 и C#-ом.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
"
Или мне нужно будет писать юнит тесты чтобы проверить качество рефакторинга?
