Ну, во-первых, спасибо за содержательный ответ .
M>А можно ваше определение рефакторинга? Это то, что "делается перед внесением фичи, чтобы облегчить этот процесс"?. Просто если использовать, например, определение из wiki (которое более широкое, чем ваше), у меня получается, что как раз таки большая часть рефакторингов делается не перед внесением фичи а во время или сразу после внесения фичи, после изменения кода. Я в дальнейшем буду использовать термин "рефакторинг" для обозначения "изменения программы без изменения ее фунциональности (или внешнего поведения) с целью улучшения ее качества" (вольный перевод wiki). Если вас не устраивает — готов использовать другое название, только предложите Именно для того определения, которое я привел. Потому что такая активность существует и хочется как-то ее называть.
Время когда и для чего рефакторинг совершается никак не влияет на его определение. Я думаю на вопрос руководителю: "Я хочу здесь переделать, часы дашь?", будет вполне разумный вопрос: "А зачем тебе потребовалась переделка?" Т.е. упрощение кода служит довольно прагматичным целям, а вовсе не эстетическим чувствам программиста.
Ээээ.... И это все возможности что предоставляет IDE?
M>Про рефакторинги поговорили, теперь перейдем к месту IDE в этом процессе. Я полностью согласен, что все эти рефакторинги в рассматриваемых ситуациях делаются легко вручную (rename something может быть сложнее, но ничего экстраординарного там нет). Первые три можно даже попробовать в текстовом редакторе реализовать. Первые два даже и не слишком сложно будет сделать (для vim), и это покроет большинство случаев применения. Только вот не в сложности или скорости здесь дело. Если посмотреть то, что я написал выше, получается, что я использую операции "назвать результат формулы", "назвать константу", "назвать функцию", "исправить имя aka rename". Эти операции фактически являются (реализованы с помощью) соответствующими рефакторингами. Ну а рефакторинги в качестве механизма уже перемещают блоки текста или чего там еще использует IDE. Все четыре операции имеют соответствующие комбинации горячих клавиш. В результате на 4-х комбинациях я имею 4 операции. Высокоуровневых операции, описываемых в терминах конструкций языка. Т.е. я не просто куда-то переношу куски текста, я выполняю некоторую вполне осмысленную и "высокоуровневую" трансформацию программы. Да, я могу сам выполнить и все низкоуровневые операции с кусками текста, но зачем? Ведь в языках же, наоборот, стремятся к большей выразительности при меньшем количестве кода. Ну да, мы получаем большую выразительность и "высокоуровневые" термины для написания программ. Но в IDE я также получаю "высокоуровневые" операции для манипуляции над программами. Т.е. не просто скопировать блок кода, а именно "перенести метод", например. Или 4 указанных операции. Детали реализации этих операций меня не сильно интересуют. А манипуляции существующим кодом в ряде отраслей важны. На самом деле это практически вся автоматизация бизнеса с ее изменениями требований и прочим, когда важно не только то, что написано сейчас, но и как из того, что было вчера сделать то, что нужно сегодня. Из-за непредсказуемости требований это тоже имеет свой fun. И для решения этих задач используются соответствующие инструменты (те же IDE). Причем, что интересно, вполне может быть, что требования к возможности изменения кода как раз гораздо выше, чем требования к его выразительности. Т.е. требования меняются часто и нам важна вся инфраструктура, возможности найти места для изменений в огромной кодовой базе и т.п. Поэтому в данном случае вопрос о наличии и возможностях IDE будет очень и очень актуален.
Т.е. ты хочешь сказать что эти 4 приёма являются полным и непротиворечивым базисом для совершения любого рефакторинга?
M>Немного напишу про упомянутцй "expand selection", который используется для 1-го и 3-го рефакторингов. Это расширение существующего выделения на логические блоки кода, уже содержащего выделение. Возможный пример для ocaml'а: исходная конструкция let a = if b > 0 then c + d else let e = c-d in e * e, исходное выделение — первая e в выражении e * e. Выделения при очередных расширениях:
M> M> e * (для выделения метода или переменной, например) M> e * e M> let e = ... M> if b > ... M> let a = ... M>M>Опять же, мелочи, но для подготовки к рефакторингам очень удобно. Не нужно глазками искать начало блока, конец, тянуть выделение. Всего лишь контролируется, что "по дереву языка" мы пришли в то место, которое нам нужно и над которым выполняется операция. Опять же, я команды отдаю не в терминах "текстового редактора", а в терминах языка, его грамматики. Примерно того же рода копирование "фрагмента кода" в другой код. Мелочь, но import'ы для java тянутся и автоматически появляются в новом месте. А вот будет ли в OcaIDE что-нибудь сделано, когда я скопирую кусок из одного файла в другой (не помню, где собранная лежит дома, а для мелочей хватает и vim'а)? А и исходном файле у меня могли быть #open вначале, поэтому не все можно оставить как есть, нужно либо имя модуля дописать првы вызовах, либо директивы #open в целевом файле. Мне с "кодом" работать все же приятнее, чем с "текстовым представлением этого кода".
M>Ну и напоследок про «перераспределить обязанности между классами и один из них, возможно, выкинь». В таком виде рефакторинга нет. Он будет выполняться с помощью нескольких более простых. А вот в каких терминах мы будем работать при этих мелких рефакторингах — это большой вопрос. Можно таскать "куски текста" (понимая под этим перемещение метода, например). Только вот при этом нужно контролировать, что все зависимости утянуты и т.п. Возможно, метод менять (если часть методов осталось в одном классе, а часть уехала). А можно сказать, что "вот этот метод должен уехать в тот класс". При этом IDE может проверить зависимости (например, скажет, что ссылки остались на приватный метод и видимость ему нужно поменять), сама поменяет все ссылки на функции в исходном коде. При перемещении метода вверх в иерархии классов можно одним кликом сказать "добавить зависимости", проверить их и продолжить операцию. Ну да, наверное, все равно какие-то мелочи придется сделать "в тексте руками". Но если не все плохо, это будет малая часть. А большая часть будет в реорганизации структуры, фрагментов программы.
Т.е., в итоге, ты предлагаешь писать код так чтоб в IDE было удобно выделять этот код, а IDE было удобно с ним работать?
Когда ты говоришь что IDE тебе даёт "высокоуровневые операции для манипуляции над программой" ты не прав, все высокоуровневые манипуляции над программой тебе даёт твой мозг, а IDE тебе облегчает только маленькую часть из них, и самое плохое что набор операций маленький и нерасширяемый, т.е. ты, в итоге, начинаешь думать над переделкой дизайна в терминах того что предоставляет IDE. А если ты забиваешь на эти рамки, то получается что у тебя просто набор манипуляций над текстом программы, а в этом плане vim даст 100 очков форы.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, thesz, Вы писали:
T>Здравствуйте, MigMit, Вы писали:
MM>>Здравствуйте, thesz, Вы писали:
T>>>Есть у нас различие в подходах к разработке?
MM>>Ты никогда не делаешь библиотек, которыми будут пользоваться другие?
T>Будем бить авторитетом: The disadvantage is that pattern matching, which is so useful, cannot be used on abstract data types (страница 8).
А следующее предложение "Solutions to this problem are on the horizon" То, чего не было в Миранде circa 1987, есть в Scala и F#.
Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, thesz, Вы писали:
T>>Будем бить авторитетом: The disadvantage is that pattern matching, which is so useful, cannot be used on abstract data types (страница 8).
Z>А следующее предложение "Solutions to this problem are on the horizon" То, чего не было в Миранде circa 1987, есть в Scala и F#.
Зачем мне использовать view, если я могу использовать исходные типы, получив при этом проверку полноты разбора по образцу?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Здравствуйте, z00n, Вы писали:
Z>>Здравствуйте, thesz, Вы писали:
T>>>Будем бить авторитетом: The disadvantage is that pattern matching, which is so useful, cannot be used on abstract data types (страница 8).
Z>>А следующее предложение "Solutions to this problem are on the horizon" То, чего не было в Миранде circa 1987, есть в Scala и F#.
T>Зачем мне использовать view, если я могу использовать исходные типы, получив при этом проверку полноты разбора по образцу?
Чтобы не нарушать инкапсуляцию. В скале полнота проверяется, если иерархия "заперта".
Здравствуйте, Denom, Вы писали:
VD>>Да, как-то мелкие довольно редко попадаются. 200 файлов — норма. Были проекты в которых было файлов по 10000 файлов. Полная перекомпиляция — 40 минут.
D>на чем (какой язык)?
40 минут было только в С/С++. А проекты по 10К файлов были на разных языках, от Дельфи и C#-а до С++.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, thesz, Вы писали:
T>Но если у меня AST на 20+ типов, я его лучше так таскать буду.
А этот АСТ действительно нужен из вне?
Скажем если вы планируете расширения которые должны анализировать АСТ, то это одно. А если это отдельный проект, то его можно было бы оставить в рамках модуля.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, thesz, Вы писали:
T>>Зачем мне использовать view, если я могу использовать исходные типы, получив при этом проверку полноты разбора по образцу? Z>Чтобы не нарушать инкапсуляцию. В скале полнота проверяется, если иерархия "заперта".
А мы говорим угадай про что?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, thesz, Вы писали:
T>>Но если у меня AST на 20+ типов, я его лучше так таскать буду.
VD>А этот АСТ действительно нужен из вне?
VD>Скажем если вы планируете расширения которые должны анализировать АСТ, то это одно. А если это отдельный проект, то его можно было бы оставить в рамках модуля.
И внести все возможные анализы внутрь этого модуля.
Нет уж.
Модулей будет несколько, внутри они могут пользоваться всем богатством доступных анализов и типов данных.
Доступ извне может быть и закрыт. Это уже дело вкуса.
Иерархические модули Хаскеля отлично подходят для этой цели.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, VladD2, Вы писали:
M>> Я правильно понял, что до где-то года 96-го все поголовно решали слишком примитивные задачи, поскольку приличных IDE просто не было (ой, мне сейчас опять про VisualAge начнут напоминать...)?
VD>Ну, почему только про VisualAge. Смолток был в 80-ом и до IBM-а.
И много на том смолтолке писали? IDE были не нужны, и вдруг разом стали нужны, так что ли?
VD> А задачи, действительно реашалось более примитивные.
Это не так. Преимущественно куда как более сложные, чем сейчас.
VD> То что тогда казалось подвигом, сейчас обычное дело.
Примерчик можно?
M>> Это не вера, это практический опыт.
VD>Практический опыт бывает разный. То что для того же Хаскеля не могут 10 лет написать IDE — это тоже практический опыт.
Не "не могут", а не пытаются. Потому что те, кто мог бы написать IDE, уже давно все эти цацки и побрякушки переросли. А кому нужны IDE, те не осилят написать.
VD>Агащазблин. Проект может только загружаться в этот РЕПЛ по несколько минут.
Чего-то ты очень сильно не понимаешь. С какой это радости там что-то будет куда-то загружаться? Я, например, активно использовал REPL для отладки проекта, который только собирается от четырёх до шести часов, в зависимости от погоды на Марсе.
VD> А если РЕПЛ интерпретирующий, то загруженый проект может просто перестать предоставлять приемлемый отклик.
Какие занятные представления о REPLах. Интересно, откуда? Python, наверное?
VD> Если ты сайтики лепишь с посещаемостиью в 10 человек в день, то конечно все ОК. А если сложное приложение (GUI, сложная логика или высоконагруженное), то ты приплыл. При этом отладчик позволят находить ошибки и в огромных проектах.
Я имел дело с проектами, скажем так, очень неприемлемой сложности. И ничего, REPL всегда и везде не бывает лишним.
VD>Оптимально конечно иметь возможность править код прямо во время отлкадки и производить замену кода на уровне типов и функций. Чем это хуже РЕПЛа?
Тем, что это частный случай возможностей REPL. Весьма ограниченный.
VD>Это чушь.
Ну ну. Не тебе судить.
VD> Отладчика это не заменит.
Но ведь заменяет, вот в чём пафос.
VD> Да и само наличие "скрипта" уже говорит, что что-то не так.
Опять же, извини, но не тебе судить.
VD> В прочем, я понял что в данном случае речь идет скорее всего о неком диалекте лиспа.
Совершенно не обязательно. В разных случаях это были:
— IronPython
— Jython
— F#
— Lua
— даже Forth
M>> REPL распрекрасно рулит и заруливает и для ни разу не функциональных языков.
VD>Лисп?
См. выше, из них только один с большой натяжкой функциональный.
Здравствуйте, VladD2, Вы писали:
M>> Отличный пример функциональной декомпозиции был в журнале "Практика функционального программирования", про игру в шашки. Подробненько так, шаг за шагом.
VD>Можно ссылку?
Здравствуйте, VladD2, Вы писали:
VD>Это очередная выдумка.
Не стоит. Это глупо.
VD> REPL не встраивается в приложения F#.
Встраивается. Тривиально. И, что ещё интереснее, REPL от F# встраивается вообще в любое .NET-приложение. Его можно повесить ждать на какой либо порт, и подключаться по мере надобности.
VD> Если я имею запущенное приложение F#, то РЕПЛ к нему уже не подключить.
Ну так прикрутить не проблема, при сборке в отладочном режиме будет REPL, в релизе — на фиг REPL.
VD> А вот отладчик — можно.
Толку то до этого отладчика.
VD>Что до консолей в играх, то они позволяют что угодно, но не разрабатывать игры. Консоли там для настроек, для управления, для отладки (трассировки, переключения параметров), но никак не для разработки игр. Даже скрит из них не напишешь.
Здравствуйте, metaprogrammer, Вы писали:
VD>>Ну, почему только про VisualAge. Смолток был в 80-ом и до IBM-а. M> И много на том смолтолке писали?
Много.
M> IDE были не нужны, и вдруг разом стали нужны, так что ли?
Не совсем. До где-то середины 90-х сложные IDE были невозможны на x86 технически. Но даже простые IDE типа Turbo Pascal'а/Borland C++ уже в ту пору рулили.
Они просто подняли производительность труда и снизили планку входа.
VD>> А задачи, действительно реашалось более примитивные. M> Это не так. Преимущественно куда как более сложные, чем сейчас.
Какие?
VD>> То что тогда казалось подвигом, сейчас обычное дело. M> Примерчик можно?
Отладка кода в режиме ядра, к примеру. Сейчас я спокойно это делаю символьным отладчиком из IDE.
Здравствуйте, VladD2, Вы писали:
VD>Да, как-то мелкие довольно редко попадаются. 200 файлов — норма. Были проекты в которых было файлов по 10000 файлов. Полная перекомпиляция — 40 минут.
Ну, это ещё мелочёвка.
V>>Пошаговая отладка -- это просто какая-то безумная трата времени. Конкретный мелкий алгоритм отлаживается в repl. Более сложный -- задолбаешься шагать.
VD>Вы просто не умеете его готовить (с)
Видал я тех, кто "умеет готовить". Лучше бы я их не видел. Наихудший способ решения проблем из всех возможных.
Здравствуйте, VladD2, Вы писали:
VD>Другой пример с той же интеграцией. Интеграция использует код MS. Там натуральная инудусятина. Но нужно разбираться как он работает и как обходить проблемы которые он создает. Переписывать все с нуля не реально — это много человеколет. В итоге наличие отладочной информации позволило залезть отладчиком в их код и понять его логику. То же с кодом компилятора.
Занятно. А я логику интерфейсов MSVS изучал как раз из консоли F#. Без всяких отладчиков.
VD>Ваши сказки из серии "писать надо правильно" разбиваются о суровую действительность. Писать надо правильно, но к сожалению в жизни это не помогает полностью избежать проблем. А если проблема уже есть, то решить ее проще используя все доступные средсвта — отладчик, логи и т.п.
Для работы паталогоанатома отладчик конечно же незаменим. Только не стоит и переоценивать важность такой работы.
Здравствуйте, Cyberax, Вы писали:
VD>>>Ну, почему только про VisualAge. Смолток был в 80-ом и до IBM-а. M>> И много на том смолтолке писали? C>Много.
Не Smalltalk определят лицо индустрии. И сложные задачи решались в основном не на нём. Да, блин, сложные задачи решались (и сейчас решаются) даже на Фортране!
M>> IDE были не нужны, и вдруг разом стали нужны, так что ли? C>Не совсем. До где-то середины 90-х сложные IDE были невозможны на x86 технически. Но даже простые IDE типа Turbo Pascal'а/Borland C++ уже в ту пору рулили.
Да ну, какие это на фиг IDE? Редактор с запускалкой компилятора и хелпа и подсветкой ошибок. Ничего из того, о чём тут говорит Влад, там и близко не было. Никакого автоматизированного рефакторинга, никакого автокомплита и прочих сомнительных прелестей.
C>Они просто подняли производительность труда и снизили планку входа.
А всякие там emacs на пару с sed и awk на ещё большие высоты поднимали производительность труда. И что?
M>> Это не так. Преимущественно куда как более сложные, чем сейчас. C>Какие?
Библиотек мало было, все постоянно велосипеды сложные изобретали. Кодирования из готовых кубиков не существовало как класса, а сейчас 90% программирования — сборка из готовых кубиков.
VD>>> То что тогда казалось подвигом, сейчас обычное дело. M>> Примерчик можно? C>Отладка кода в режиме ядра, к примеру. Сейчас я спокойно это делаю символьным отладчиком из IDE.
Здравствуйте, metaprogrammer, Вы писали:
M>Здравствуйте, Cyberax, Вы писали:
VD>>>>Ну, почему только про VisualAge. Смолток был в 80-ом и до IBM-а. M>>> И много на том смолтолке писали? C>>Много.
M> Не Smalltalk определят лицо индустрии. И сложные задачи решались в основном не на нём. Да, блин, сложные задачи решались (и сейчас решаются) даже на Фортране!
C>>Не совсем. До где-то середины 90-х сложные IDE были невозможны на x86 технически. Но даже простые IDE типа Turbo Pascal'а/Borland C++ уже в ту пору рулили. M> Да ну, какие это на фиг IDE?
Такие.
M> Редактор с запускалкой компилятора и хелпа и подсветкой ошибок. Ничего из того, о чём тут говорит Влад, там и близко не было. Никакого автоматизированного рефакторинга, никакого автокомплита и прочих сомнительных прелестей.
Отладчики ещё были.
Однако, даже тогда мало кто любил без тех средств работать.
C>>Они просто подняли производительность труда и снизили планку входа. M> А всякие там emacs на пару с sed и awk на ещё большие высоты поднимали производительность труда. И что?
Не поднимали. Emacs лучше Borland C++, но уже хуже MSVS версии так седьмой.
M>>> Это не так. Преимущественно куда как более сложные, чем сейчас. C>>Какие? M> Библиотек мало было, все постоянно велосипеды сложные изобретали. Кодирования из готовых кубиков не существовало как класса, а сейчас 90% программирования — сборка из готовых кубиков.
И что? Это только те сложности, которые сами себе создавали, чтобы героически преодолевать.
M>>> Примерчик можно? C>>Отладка кода в режиме ядра, к примеру. Сейчас я спокойно это делаю символьным отладчиком из IDE. M> Это частности.
И их много.
Здравствуйте, Cyberax, Вы писали:
M>> Редактор с запускалкой компилятора и хелпа и подсветкой ошибок. Ничего из того, о чём тут говорит Влад, там и близко не было. Никакого автоматизированного рефакторинга, никакого автокомплита и прочих сомнительных прелестей. C>Отладчики ещё были.
И? Где там все эти рефакторинги с интеллисенсами? Не было их, и не надо было. Жили как-то.
C>Однако, даже тогда мало кто любил без тех средств работать.
В 80х? Да нет, много кто без всего этого прекрасно обходился.
C>Не поднимали. Emacs лучше Borland C++, но уже хуже MSVS версии так седьмой.
Да? Правда, что ли? Ничего себе новости.
C>И что? Это только те сложности, которые сами себе создавали, чтобы героически преодолевать.
Природа сложностей не важна. Важно, что они были, и что их прекрасно преодолевали без всякой IDE-шелухи.
M>> Это частности. C>И их много.
И все они никакого отношения к IDE не имеют, что характерно.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, metaprogrammer, Вы писали:
M>>Здравствуйте, Cyberax, Вы писали:
C>>>Не совсем. До где-то середины 90-х сложные IDE были невозможны на x86 технически. Но даже простые IDE типа Turbo Pascal'а/Borland C++ уже в ту пору рулили.
C>Однако, даже тогда мало кто любил без тех средств работать.
C>>>Они просто подняли производительность труда и снизили планку входа. M>> А всякие там emacs на пару с sed и awk на ещё большие высоты поднимали производительность труда. И что? C>Не поднимали. Emacs лучше Borland C++, но уже хуже MSVS версии так седьмой.
Чтот у меня не сходится: вроде речь про середину 90-х, а седьмая студия — это уже .Net (ещё без цифры) и 2002-й год. Кто-то что-то тут не то
Да даже 6.0 ито лишь в середине 98-го появилась.
А с емаксом, подозреваю, что вопросы были в том, насколько он был под винду юзабелен в то время (сам не в курсе).
Здравствуйте, metaprogrammer, Вы писали:
M>>> Редактор с запускалкой компилятора и хелпа и подсветкой ошибок. Ничего из того, о чём тут говорит Влад, там и близко не было. Никакого автоматизированного рефакторинга, никакого автокомплита и прочих сомнительных прелестей. C>>Отладчики ещё были. M> И? Где там все эти рефакторинги с интеллисенсами?
Были в некоторых IDE (для ST).
M> Не было их, и не надо было. Жили как-то.
Насчёт "не надо было" — не надо
В Дельфи навигация появилась где-то в 95-м году, это ОЧЕНЬ тогда помогало. Source navigator для С++ появился тогда же. А в VC6 уже был и неплохой индексатор.
C>>Однако, даже тогда мало кто любил без тех средств работать. M> В 80х? Да нет, много кто без всего этого прекрасно обходился.
Ну да. Вариантов-то не было.
C>>Не поднимали. Emacs лучше Borland C++, но уже хуже MSVS версии так седьмой. M> Да? Правда, что ли? Ничего себе новости.
Факт, однако. Популярность Emacs'а как раз после конца 90-х резко пошла вниз.
C>>И что? Это только те сложности, которые сами себе создавали, чтобы героически преодолевать. M> Природа сложностей не важна. Важно, что они были, и что их прекрасно преодолевали без всякой IDE-шелухи.
Нет, можно каналы выкапывать и ложками — я не спорю. Но лучше взять экскаватор.
M>>> Это частности. C>>И их много. M> И все они никакого отношения к IDE не имеют, что характерно.
Что характерно, имеют.
.
Ведь в языках же, наоборот, стремятся к большей выразительности при меньшем количестве кода. Ну да, мы получаем большую выразительность и "высокоуровневые" термины для написания программ. Но в IDE я также получаю "высокоуровневые" операции для манипуляции над программами. Т.е. не просто скопировать блок кода, а именно "перенести метод", например. Или 4 указанных операции. Детали реализации этих операций меня не сильно интересуют. А манипуляции существующим кодом в ряде отраслей важны. На самом деле это практически вся автоматизация бизнеса с ее изменениями требований и прочим, когда важно не только то, что написано сейчас, но и как из того, что было вчера сделать то, что нужно сегодня. Из-за непредсказуемости требований это тоже имеет свой fun. И для решения этих задач используются соответствующие инструменты (те же IDE). Причем, что интересно, вполне может быть, что требования к возможности изменения кода как раз гораздо выше, чем требования к его выразительности. Т.е. требования меняются часто и нам важна вся инфраструктура, возможности найти места для изменений в огромной кодовой базе и т.п. Поэтому в данном случае вопрос о наличии и возможностях IDE будет очень и очень актуален. 
