у меня javascript.

В последнее время я много занимался поддержкой javascript. В основном, дело касалось code completion. Расскажу немного о трудностях, которые возникают, когда в языке отсутствуют типовые аннотации. Как ни странно это звучит, с решарпером javascript становится языком с довольно внушительной системой типов. Еще более странно будет звучать то, что все эти типы не используются для резолва, но обо всем по порядку.
Первое, что надо делать при поддержке любого языка - это построить кэш деклараций. В javascript нелокальными являются только свойства объектов. Существует бесчисленное (в прямом смысле этого слова) множество способов определить свойство в объекте. Начать можно с функции конструктора, для разминки поддержать микрософтовский RegisterNamespace("Jetbrains.ReSharper"), после чего можно сделать jQuery.Extend(). Для любителей пособирать декларации самостоятельно в этом месте все расширяемо и можно писать свои провайдеры.
Декларации просто так собирать не интересно, для каждого свойства хорошо бы знать его объемлющий класс (для которого это свойство может быть статическим или свойством объекта). Тут же собираем информацию о наследовании классов. Инвертируем полученную информацию об объемлющих классах и имеем основной источник информации об объеках и их свойствах.
Второй источник - это выражение, которым было проинициализировано свойство. Опять же, здесь есть место для тех, кто знает про типы выражений какие-то свои тайны.
А теперь главное: как представляется тип. Он почти всегда является наборов из нескольких типов, свойства которых объединяются. Самих же свойств довольно много:
1. Собственно свойства объекта. Пример: x.
2. Сигнатура (в случае если объект можно вызывать). Пример: x(1,2,3).
3. Тип возвращаемого значентя. Пример тот же.
4. Тип создаваемого объекта. Это значит что функция была конструктором. Пример: new x().
5. Базовый тип. Пример: x.prototype.
Вычисление типов может залезать довольно далеко в код и кэши, поэтому в вычислялке есть механизм кэширования и защита от зацикливаний. На посчитанных типах работает только комплишен и информация о параметрах. Для резолва тип квалификатора не используется, что мне кажется правильным. В ближайшем будущем я сделаю киллер фичу: create property from usage, которая станет третьим клиентом моей типизации javascript, а провыйдеры свойств я обяжу уметь создавать свойства которые они распознают. И теперь представьте себе, что расширение для jQuery можно будет сделать нажав alt+enter!

Плюс десять процентов к карме

Код комплишен остался где-то позади. Нет, про него никто не забыл, просто теперь он может жить своей новой и прекрасной жизнью самостоятельно, а я могу лишь радоваться тому, что за пару недель количество правил выросло на 10% до 110. Значит есть жизнь после рефакторинга и есть смысл двигаться дальше. 

А дальше идет еще более чудесный JavaScript, в котором из комментариев мы пытаемся извлекать информацию о типах, которой так не хватает человеку, избалованному строгими языками, пытаемся воплотить тысячу и одну идею облегчения жизни пользователям jQuery, полируем код комплишен и активно работаем с чудо-листочком, пытаясь ужать безграничную фантазию в 3 месяца сроку... Не знаю, почему я пишу слово 'мы'.

И вот в этой суете я задумался над одной вещью. Допустим, мы удалим поддержку js. Да, прямо сегодня мы стираем всю поддержку js и начинаем писать все заново. Мы укладываемся в 3 месяца? Ах, черт, боюсь что нет. Хотя это я считаю на одного человека. Если их будет двое? Уже более реалистично. А было ли это так же реалистично полгода назад?

У меня утро!

Попробуйте сформулировать, что делает ваша фича или подсистема. Сделайте это письменно, на хорошем русском языке и Вы, возможно, увидите некоторые проблемы в архитектуре. Возможно, Вы увидите и некоторые достоинства Вашей реализации! Но то, что Вы увидите что-то, о чем раньше не думали - это факт.

Не спрашивайте меня ничего, я пишу!

Я сказал сегодня, что не могу вспомнить, чем именно примечателен некий персонаж из пьесы, которую мы читали на английском на прошлой неделе. Отчасти это была правда, отчасти я надеялся на сочувствие, говоря, что у меня в голову загружен code completion и потребуется некоторое время чтобы освободить немного ресурсов для других задач. Но сочувствия я не нашел. Оказалось, что по мнению Н., мой мозг не обладает должной эластичностью и это качество мне необходимо развивать. Черт возьми, я этого совсем не ожидал! Действительно ли, погружаясь с головой в решение некоторой проблемы, какой бы сложной она не казалась, мы убиваем способность мыслить шире? Возможно ли, без потери эффективности, научиться мгновенно переключаться между разными задачами? 

Я не знаю ответ, но code completion дописал. Осталось сделать так, чтобы он заработал. Или взглянем шире... нужен ли нам code completion?      

двигаю гору code completion

На этой неделе, уходя домой, я каждый день прикреплял к стенке бумажку с количеством некомпилирующихся файлов. В последний раз написал 19. А в течение недели это число временами превышало 100.
Теперь я знаю, как делается code completion, а точнее как он будет делаться, когда все взлетит. Вот некоторые предварительные итоги.
Теперь в решарпере 4 вида code completion: basic, automatic, import и smart.  И здесь у нас первое достижение - ничто не мешает сделать новый пятый вид, если кто-то придумает что он будет делать. Кстати, почему бы не сделать дважды умный или дважды импортирующий code completion? В коде такая гибкость выражается не только открытым множеством значений видов code completion, но и декларативным стилем проверок этих значений.
Автоматический code completion является обособленным видом, так как, в отличие от его родственников, он связан с некоторой сессией, время жизни которой определяется довольно сложно и зависит от печати кода, показаных lookup окошек и асинхронного построителя синтаксического дерева. Опять же, сейчас стало понятно, что управление этой сессией надо выносить в отдельную компоненту.
Теперь немного о дизайне. Программном.
Все просто: есть два набора компонент. Первый набор отвечает за создание контекста. Обычно на каждый язык приходится по одному такому контексту. Сложность контекста определяется серьезностью намерений реализовать хороший и быстрый code completion. Сейчас в c# контекст сложный, а в некоторых языках тривиальный. Но это мы исправим.
Имея набор контекстов, мы берем второй набор компонент - правила добавления и изменения списка completion item-ов. Каждое правило состоит из следующих стадий: подготовка, добавление новых элементов, редактирование списка элементов с возможностью удаления существующих и добавлением новых, декорация или изменение атрибутов элементов, определение стиля показа lookup окошка и опций автоматического применения. Все стадии выполняются последовательно для всех правил преобразования.
Некоторый примеры стадий:
1. С подготовкой все понятно.
2. Добавление ключевых слов или live template item-ов.
3. Собственно, замена ключевых слов на омонимичный live template item-ы.
4. Замена методов со скобочками на методы без скобочек в месте, где ожидается делегат.
5. Тоже нечего сказать.
Итого, мы имеем расширяемый по технологиям, изменяемый в пределах одной технологии и, к тому же, быстро работающий code completion. Правильно?

code completion

Что больше влияет на качество программного продукта? Продуманность и мощь ядра, или отполированная до блеска функциональность фич для конечных пользователей? Очевидно, что многие фичи Решарпера были бы невозможными без мощной поддержки со стороны ядра, но также очевидно, что все достоинства космической архитектуры могут быть сильно испорчены неаккуратной реализацией фич. Хорошим примером листовой фичи, требующей особой аккуратности, является код комплишен.

Трудно подсчитать количество времени, которое потребовалось для того чтобы реализовать комплишен в C#. Думаю, что это многие месяцы работы.

Сейчас в Решарпере поддерживается более десятка различных языков, и во всех них хочется иметь такой же отшлифованный код комплишен как и в C#. Да, реализовывать его в разных языках будут разные люди, и задача у них будет сложнее, так как многие технологии, которые мы поддерживаем сейчас напрямую не используются нами, а значит продумывать поведение нужно будет буквально в воздухе!

Возможно ли создать такую инфраструктуру, в которой качественный код комплишен получался бы автоматически? В общем случае, думаю, нет. Тонкая настройка нужна. Но хочется сделать так, чтобы реализация для конкретного языка сводилась бы исключительно только к такой настройке.

Собственно, созданием общей инфраструктуры код комплишена я и буду заниматься в ближайшее время. Посмотрим, что получится.

Conflicts page

Интересно, кто-нибудь читает что написано на страничке конфликтов при выполнении рефакторингов? Лично я их не читаю, и каждый раз расстраиваюсь, что опять надо нажимать 'next' и ждать. Да, я расстраиваюсь еще больше от осознания того, что к моменту показа странички с конфликтами рефакторинг уже отработал, но изменения не были применены к реальным файлам!

Объясняется все очень просто. Самый удобный способ найти возможные проблемы при выполнении рефакторинга - это попытаться его выполнить и в процессе выполнения запоминать, что и где не получилось поменять. В случае, если есть ошибки или предупреждения, необходимо откатить все изменения и показать отчет. Конечно, результаты самых тяжелых вычислений необходимо закэшировать, но в общем случае рефакторинг выполняется дважды.

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

мои студенты

У меня закончился осенний семестр, и я снова на работе по средам.
Курс, который я рассказываю, отличается наличием большого числа определений и теорем, что не свойственно большинству курсов по так называемому системному программированию. Да, называется этот курс: анализ потока управления программ.
Мне не нравится принимать экзамен. Я не умею ставить оценки и поэтому ставлю только зачет или незачет. Я не понимаю даже, что проверяется этим экзаменом? Ведь полне можно допустить, что у меня не получилось что-то рассказать или подготовить хороший конспект для тех, кто не ходит на пары? А значит я ставлю оценку самому себе?
В этом году студенты радовали меня. Несколько человек смогли до конца разобраться и в алгоритме Лэнгауэра Тарьяна и в расстановке фи узлов с использованием итерированной границы доминирования.
Сасибо всем, кто ходил на пары!
А вообще-то немного жалко, что мои студенты работают не в JetBrains. Интересно, почему?

Что не вошло в extract method?

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

Продолжаю выделять методы)

Ну вот, уже прошла неделя с того момента как я начал переписывать extract method. С одной стороны, это не так уж много, если брать в расчет относительную сложность рефакторинга, с другой стороны, мне немного обидно, что не удалось уложиться в одну неделю. Более того, для окончательной доводки требуется еще дня 3.
Модель этого рефакторинга очень проста. Все представляется в виде списка параметров, которые необходимо либо передать внутрь, либо возвратить, либо протащить через метод. Возвращаемое значение тоже является таким параметром. Бывают фиктивные параметры типа Boolean, которые необходимо возвратить из метода, чтобы восстановить поток управления в месте вызова. Из всего списка параметров выбирается наиболее подходящий кандидат для возвращаемого значения, остальные становятся обычными параметрами. В настройках, конечно, можно выбрать другое возвращаемое значение или сделать метод типа void. Именно от параметра, выбранного в качестве возвращаемого значения зависит то, как будет преобразован код выделенного фрагмента, и как будет сконструирован вызов нового метода.
Люблю, когда модель получается простой. Не могу сказать, что для меня сразу стало очевидно, что возможность выделить из кода подпоследовательность - это просто еще один 'out' параметр, который чаще всего по умолчанию становится возвращаемым значением.
В ситуации когда в настройках можно что-то менять, возникает вопрос - как тестировать поведение при различных параметрах? У меня есть любимый алгоритм для таких ситуаций. Не самый оптимальный, конечно, но работает на ура! Называется - полный перебор. Да, выбор возвращаемого значения, выбор сущности, которую создать, передавать или нет конкретные параметры - вариантов довольно много, но не смертельно. Нет ничего невозможного в том, чтобы перебраться все комбинации и посмотреть что получится. И никаких больше настроек для конкретного теста!

Что переписать?

Каждый программист по-своему представляет, в какой момент следует закончить думать и необходимо написать код. У всех есть свое мнение о том, когда этот код надо переписать. Ну а в процессе переписывания возникает третий вопрос: когда же закончить переписывать и сделать, наконец-то, что-то полезное?

Я пишу extract method

Вы когда-нибудь писали extract method? Я мечтал написать его с первого дня моей работы в жетбрэйнс. И до этого тоже мечтал, так что теперь чувствую как моя мечта постепенно начинает сбываться.

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

В первый же день написал решение глобальной задачи анализа потока данных дня определения того, что надо передать в метод и что оттуда возвратить. Думаю, каждый когда-нибудь слышал про чудесный алгоритм dfa. Я счастлив, мне удалось его использовать! Немного повозиться с лямбдами, не забыть про ref out параметры объемлющего метода, еще не забыть тысячу мелочей и уже проходят полторы сотни тестов! На третий день, как раз сегодня, рисовал формочку с кнопочками и галочками. Нарисовалось с десяток различных настроек. Может быть диалог не нужен вовсе? Нет... Мир к этому еще не готов. Со скрипом удается разместить все на том же пространстве на котором были и старые опции, но с одной оговоркой. Не удивляйтесь теперь если до странички с выбором параметров у вас спросят, а что, собственно, вы хотите получить? Метод, свойство или может быть конструктор?

Еще немного из задуманного... Возможность создать сразу статический метод. Да, да! а не зафигачить ли туда третью страничку ака make static, где и позволить почтенному пользователю насладиться всем разнообразием способов избавится от использований 'себя'? А как вам методы с yield return? Наверное только ленивый не пытался выделить подпоследовательность, разочароваться, написать баг... А любую ли подпоследовательность можно вынести в новый метод? А если там yield break? А если yield return есть, то иногда можно обойтись без ienumerable. Кстати, определить это в общем случае довольно интересная задача. И к тому же довольно простая. Добавим анализ yield return в чудесный dfa, и будем проверять, что каждый yield return выполняется ровно один раз. Люблю язык c# - с ним такая проверка делается за 2 строчки кода! В первой проверяем что на любом выходе мы прошли через какой-нибудь yield, во второй для никакой yield не предшествует никакому и даже самому себе!

Думаю, extract method может дать фору любому рефакторингу по количеству частных случаев, а сколько мы их нашли можно будет увидеть совсем скоро! Я говорю мы, так как большинство из них имеют свои корни в нашем багтрекере, где, между прочим, можно посмотреть и состояние дел в других рефакторингах. Extract method сейчас чемпион. 45 реквестов! А кто следующий?