InfoWorld, США
Время от времени неплохо помечтать о том, что мы могли бы сделать с инструментами, которые не воспринимают программу просто как набор строк текста
В последний раз на Java я писал довольно давно. Но на днях, обновляя установленную у меня версию Eclipse, мне пришлось «стряхнуть пыль» со старой программы на Java и я взглянул на это древнее произведение под новым углом.
Я никогда не пользовался интегрированной средой разработки, предпочитая работать с Emacs. Следует отметить, что среди моих коллег не я один такой. Даже сейчас программисты по-прежнему пишут код в текстовых файлах, и до тех пор, пока мы не изменим эту парадигму, редакторы кода, «вгоняющие» строки кода в текстовые файлы, трудно будет превзойти.
Eclipse 3.0 не смог привести к окончательной замене этой парадигмы, но его мощные средства рефакторинга предвещают, что это скоро произойдет. Для новичков возможность, к примеру, переименовать метод во всем проекте, во всех Java-файлах проекта, а также в соответствующих тестах весьма удобна. Конечно, на самом деле это всего лишь поиск с заменой. Более впечатляет возможность реструктуризации кода. Eclipse, например, может преобразовать фрагмент кода в метод и вызвать этот метод, переместить вверх или вниз члены класса в иерархии класса.
Это волшебство преобразования требует определенного анализа кода. Eclipse скрытым образом поддерживает синтаксическое дерево абстракций (AST) — «глубинную структуру» (как сказал бы лингвист Ноэм Хомский), находящуюся под той поверхностной структурой, которая записывается, читается и редактируется как строки Java-кода. При работе с Eclipse вы ощущаете, что работаете непосредственно с AST и что текст на Java — это лишь удобный способ визуализировать это дерево.
Увы, это только иллюзия. Когда вы анализируете свой проект, находящийся в хранилище, вы проверяете только строки кода, а не AST. Рефакторинг, который вы выполняли, будет видим остальной группе, работающей над проектом, в форме различающихся строк, а не как преобразования дерева.
В тот или иной момент времени каждый программист понимает, что было бы неплохо работать непосредственно с глубинной структурой кода. Лучшие умы в этой сфере стремятся к тому, чтобы так оно и было. Легендарный Чарлз Симонэ, пару лет назад ушедший из Microsoft для того, чтобы реализовать свое представление об «умственном программировании» (intentional programming), сказал, что глубинная структура — это основа набора инструментальных средств, который создает его новая компания Intentional Software.
Сергей Дмитриев разделяет точку зрения Симонэ, а его компания JetBrains, создатель IntelliJ IDEA, интегрированной среды разработки на Java, планирует сделать нечто аналогичное в следующем поколении своего инструментария.
Больше об этих двух проектах ничего не известно, но еще один специалист по глубинной структуре ничего не скрывает. Джонатан Эдвардс из Массачусетского технологического института создает прототипную систему, которую он демонстрирует в предварительном варианте.
Здесь реализуются великие идеи. В прототипе Эдвардса программирование, тестирование и отладка — это лишь различные способы взаимодействия с древовидной структурой программы. Статья «Программирование на примерах» (Example Centric Programming), опубликованная Эдвардсом в 2004 OOPSLA, рассказывает об одном из преимуществ такой организации. Примеры (или «случаи использования»), которые определяют архитектуру программы, вырабатываются в контексте существования и развития программы.
Мы все и раньше слышали о подобных системах. Время от времени неплохо помечтать о том, что мы могли бы сделать с инструментами, которые не воспринимают программу просто как набор строк текста.
Джон Уделл — ведущий аналитик InfoWorld Test Cen?ter. С ним можно связаться по электронной почте по адресу: Jon_Udell@ infoworld.com