Каждый раз, когда я пишу новую фичу, я вытаскиваю из под стола новый листочек и начинаю записывать туда все то, что еще хочется сделать. Очень люблю такие листочки. Особенно люблю пачку таких листочков, посвященных языку JavaScript, которая в данный момент лежит у мення на столе.
В простых ситуациях хватает одного листочка. Реализованные или пересмотренные записи зачеркиваются, новые дописываются, а фича, тем временем, становится лучше, и это прогресс, который легко наблюдать.
И вот, фича готова, а незачеркнутые записи остались. Что же останется за рамками нового extract method?
Первое, что я счел излишеством - это возможность создавать статический метод в любых обстоятельствах. Существует несколько способов избавиться от использования this, и соответствующие настройки тяжело умещаются в и без того перегруженную страничку extract method.
Да, часто так получается что некоторая функциональность не попадает в продукт просто потому, что она трудно выражается в пользовательском интерфейсе. Именно такая история случилась с возможностью передавать в качестве параметров выделяемого метода не только переменные, но и целые выражения. Действительно, часто выделение метода сопровождается созданием параметров из выражений в новом методе с последующим удалением неиспользуемых параметров. Получается, что часть кода мы выделили зря, так как в дальнейшем все равно перенесли его обратно в место вызова с помощью 'introduce parameter'. Как решить эту проблему в настройках рефакторинга 'extract method' я не знаю.
Следующая задумка не дает мне покоя. Представьте себе большой метод. Надо разбить его на несколько, но как это сделать? Хорошо бы уметь применять extract method к методу вообще, и пусть он сам решит, что тут лучше выделить. Какие могут быть кандидаты в этом случае? Последовательности операторов, выдающие одно значение? Повторяющиеся несколько раз? Придумать эвристики и, опять же, удобный интерфейс для выбора и точной настройки кандидатов задача интересная. Надеюсь еще вернуться к ней, когда нибудь.
Очень хотелось добавить возможность возвращать из метода tuple из нескольких значений. Более того, можно было бы создать новый класс и использовать его в качестве типа возвращаемого значения. Несмотря на то, что фича кажется довольно простой, в ее реализации будет немало нюансов.
Напоследок хочется заметить, что, сам по себе, диалог рефакторинга выглядит, мягко говоря, немого старомодно. Я уверен, что необходимо двигаться в сторону уменьшения количества настроек и, в конечном итоге, полностью отказаться от диалогов в пользу темплейтов или какой-то другой технологии. Необходимо сделать так, чтобы писать и изменять код было бы удобно в редакторе, а не полагаться на то, что кто-то будет разбираться, что значат настройки в диалоге. Так как подавляющем большинстве случаев никаких дополнительных настроек для выделения метода не требуется, необходимо сделать так, чтобы изменения было бы легко делать уже после того, как рефакторинг завершен.
Я уверен, что я написал вовсе не обо всех недоделках. Надеюсь, новые прекрасные идеи будут легко реализовываться в новой инфраструктуре и радовать наших пользователей и нас.
В простых ситуациях хватает одного листочка. Реализованные или пересмотренные записи зачеркиваются, новые дописываются, а фича, тем временем, становится лучше, и это прогресс, который легко наблюдать.
И вот, фича готова, а незачеркнутые записи остались. Что же останется за рамками нового extract method?
Первое, что я счел излишеством - это возможность создавать статический метод в любых обстоятельствах. Существует несколько способов избавиться от использования this, и соответствующие настройки тяжело умещаются в и без того перегруженную страничку extract method.
Да, часто так получается что некоторая функциональность не попадает в продукт просто потому, что она трудно выражается в пользовательском интерфейсе. Именно такая история случилась с возможностью передавать в качестве параметров выделяемого метода не только переменные, но и целые выражения. Действительно, часто выделение метода сопровождается созданием параметров из выражений в новом методе с последующим удалением неиспользуемых параметров. Получается, что часть кода мы выделили зря, так как в дальнейшем все равно перенесли его обратно в место вызова с помощью 'introduce parameter'. Как решить эту проблему в настройках рефакторинга 'extract method' я не знаю.
Следующая задумка не дает мне покоя. Представьте себе большой метод. Надо разбить его на несколько, но как это сделать? Хорошо бы уметь применять extract method к методу вообще, и пусть он сам решит, что тут лучше выделить. Какие могут быть кандидаты в этом случае? Последовательности операторов, выдающие одно значение? Повторяющиеся несколько раз? Придумать эвристики и, опять же, удобный интерфейс для выбора и точной настройки кандидатов задача интересная. Надеюсь еще вернуться к ней, когда нибудь.
Очень хотелось добавить возможность возвращать из метода tuple из нескольких значений. Более того, можно было бы создать новый класс и использовать его в качестве типа возвращаемого значения. Несмотря на то, что фича кажется довольно простой, в ее реализации будет немало нюансов.
Напоследок хочется заметить, что, сам по себе, диалог рефакторинга выглядит, мягко говоря, немого старомодно. Я уверен, что необходимо двигаться в сторону уменьшения количества настроек и, в конечном итоге, полностью отказаться от диалогов в пользу темплейтов или какой-то другой технологии. Необходимо сделать так, чтобы писать и изменять код было бы удобно в редакторе, а не полагаться на то, что кто-то будет разбираться, что значат настройки в диалоге. Так как подавляющем большинстве случаев никаких дополнительных настроек для выделения метода не требуется, необходимо сделать так, чтобы изменения было бы легко делать уже после того, как рефакторинг завершен.
Я уверен, что я написал вовсе не обо всех недоделках. Надеюсь, новые прекрасные идеи будут легко реализовываться в новой инфраструктуре и радовать наших пользователей и нас.
No comments:
Post a Comment