Eclipse 3.0

>необоснованным утверждением, что "рефакторинг - это зло"

обоснование выше.

>необоснованными наездами на разработчиков

Не было этого. Я говорил, что рефакторингом разработчик наказывает себя за непредусмотрение реализовавшихся изменений ТЗ. Где наезд?

Все таки я слишком стар (да, я стар, я очень стар, да я просто супер стар;-) для приписываемых мне ошибок. Кто-то неправильно читает:-)

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

Ну, блин, да это же и есть идеальная архитектура:-)

>Я не согласен с тем, что рефакторинг это зло

Проведем мысленный эксперимент. К Вам приходит заказчик, Вы решаете его проблему, потом он говорит, что вот сдесь и вот тут надо поправить, и сделать совсем наоборот, и вы видите, что такой вариант _не_ требует массовых изменений кода. Это хорошо? А если требует - это тоже хорошо? Я тоже хочу такой травки:-)

>изменение имени метода, суть рефакторинг.

Возникла мысль. (NB) Не для обсуждения (она слишком спорная, и я не готов ее отстаивать) но для обдумывания. Итак: Необходимость менять имя метода вызывается неправильным или неуместным применением языка программирования. Иначе это не необходимость(живет же юникс с вызовом "creat").

>если среда разработки позволяет сделать это легко, это хорошо.

А я разве утверждал обратное?

>> обоснование выше.

Я написал, почему это не зло для меня. Думаю, что с моей точкой зрения
согласится еще куча людей, начиная от кодеров и заканчивая менеджерами
проектов. То есть, даже если это зло, то как минимум не для всех. То
есть, следовало бы сказать так: "Рефакторинг - это зло для меня, потому
как я очень сильно комплексую, если не получается спроектировать
идеальную архитектуру с первого раза". Все вопросы бы отпали.

>> Я говорил, что рефакторингом разработчик наказывает себя...

Опять за всех говорите. Я - награждаю. Кроме того, вы однозначно ставите
изменчивость ТЗ и условий развития проекта в вину разработчику. Тогда
как это далеко не всегда обстоит именно так. Это я и имел ввиду.

>Возникла мысль. (NB) Не для обсуждения (она слишком спорная, и я не готов ее отстаивать) но для обдумывания. Итак: Необходимость менять имя метода вызывается неправильным или неуместным применением языка программирования. Иначе это не необходимость(живет же юникс с вызовом "creat").

А я вот не хочу. :) Мне проще один раз изменить название метода (например, метод изменил семантику или просто неудачно было выбрано название), чем потом постоянно об него глаза спотыкать.

Это, конечно, не необходимость, но когда таких не необходимостей набирается выше крыши - это неприятно.

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

Причем, постоянно упоминаемое тобой ТЗ тут не причем - код может полностью соответствовать ТЗ. Более того, можно написать код в совершенно худших традициях, но соответствующий ТЗ. Это будет считаться правильно архитектурой с твоей точки зрения?

>Я написал, почему это не зло для меня...Я - награждаю.

А согласились бы вы обслуживать клиентов, которые поставляют непротиворечивые и достаточно полные ТЗ в начале проекта и потом не меняют их кардинально? Рефакторинг не понадобится, значит только за дополнительные деньги? :-)

>вы однозначно ставите изменчивость ТЗ и условий развития проекта в вину разработчику.

Про поиск виноватого уже писал. Какая разница кто виноват в "изменчивости ТЗ и условях развития проекта", если разгребает всегда разработчик?

Я понял! Вы взяли на вооружение народную мудрость(-: Если рефакторинг неизбежен - постарайтесь расслабиться и получить удовольствие. :-).

>> Причем, постоянно упоминаемое тобой ТЗ тут не причем - код может >> полностью соответствовать ТЗ. Более того, можно написать код в >> совершенно худших традициях, но соответствующий ТЗ. Это будет >> считаться правильно архитектурой с твоей точки зрения?

Если это вопрос ко мне, то ответ, конечно же, "нет". Я про то и говорю, что рефакторинг помогает на разных уровнях видения проекта, начиная от кодера (переменная некрасиво названа) и заканчивая менеджером проекта (изменение названия метода/класса в общем интерфейсе).

>Проведем мысленный эксперимент. К Вам приходит заказчик, Вы решаете его проблему, потом он говорит, что вот сдесь и вот тут надо поправить, и сделать совсем наоборот, и вы видите, что такой вариант _не_ требует массовых изменений кода. Это хорошо? А если требует - это тоже хорошо?

Адназначна хорошо ;-) В обоих случаях. Я показываю заказчику ТЗ утверждённое, и показываю ему подпись его комиссии принявшей проект, после того как я его написал. После этого если он хочет бесплатных изменений, то он идёт нах.; если он платит, то я уже определяю новые сроки. Всё просто ;-)

>Возникла мысль. (NB) Не для обсуждения (она слишком спорная, и я не готов ее отстаивать) но для обдумывания. Итак: Необходимость менять имя метода вызывается неправильным или неуместным применением языка программирования.

Необязательно. Я элементарно мог придумать название метода неудачно отражающее его суть. Потом, окинув свежим взглядом код, я понимаю, что это неудачное название сможет стать причиной затруднений в понимании кода, кода я его в будующем буду просматривать, после того как успешно вообще полностью его забуду.

>> Я понял! Вы взяли на вооружение народную мудрость(-: Если рефакторинг
>> неизбежен - постарайтесь расслабиться и получить удовольствие. :-).

Неизбежен не рефакторинг, и изменения. Рефакторинг помогает с ними
справиться. Ну как же вы не можете понять, что рефакторинг - это
инструмент! То, что в книжках про него пишут - это руководство
пользователя этим инструментом. А поддержка в IDE - реализация.

>А согласились бы вы обслуживать клиентов, которые поставляют непротиворечивые и достаточно полные ТЗ в начале проекта...

Эта... клиенты ТЗ сами не пишут!!!

>если он платит, то я уже определяю новые сроки.

Ну, в таком случае, конечно:-).

Так вот где собака зарыта!

IMO суффикс "-ing" в refactor-ing переводится как "-ние". Т.о. если это название инструмента - это неудачное название и его надо порефакторить:-). Но мне все таки кажется, что это более похоже на определение типа деятельности. То, что в книжках пишут - описание этой деятельности. А подержка в IDE - поддержка в IDE:-).

Ну что за человек, а? Я вам про суть, а вы про слова. Да хоть горшком
назови, суть не изменится.

Тщательнее надо быть. Аналогия: копание(?digging?) - это процесс(деятельность). Инструмент для него - лопата. Ваши слова (2мя сообщениями выше) звучат так: копание есть инструмент (для попадания на глубину?) а лопата - реализация этого инструмента. Забористая трава:-)

То есть по сути вам сказать нечего? Ну, тогда и завязывать пора.

Копание - это средство для попадания в глубину как цели. Оно же -
процесс. Лопата - это инструмент, средство для копания как процесса.

Рефакторинг - средство для внесения изменений в код как цели. Он же -
процесс. Поддержка в IDE - это инструмент, средство для выполнения
рефакторинга как процесса.

Дотошность - это не всегда хорошо :-(

>Но я не знаю ни одной продуктовой >компании, где это бы работало.

КАк же . А IntelliJ ?

Релиз выложили на (некоторые) зеркала. Скажем, вот здесь:

http://eclipse-mirror.duvin.org/eclipse/downloads/drops/R-3.0-200406251208/in...

ftp://ftp.ibiblio.org/pub/packages/development/eclipse/eclipse/downloads/drop...

http://mirror.tiscali.dk/eclipse/downloads/drops/R-3.0-200406251208/index.php

http://eclipse-mirror.jab.fi/site/eclipse/downloads/drops/R-3.0-200406251208/...

Все качаем!

2 int19h:
Ога... спасибо... уже тещщу ;-).