Я начал работать над передовыми инструментами для разработчика 9 лет назад. Когда я начинал, «инструменты программирования» означали средства просмотра форматов файлов, редакторы и, возможно, варианты grep. Отмечу, что существует большая проблема с определением целей внесения изменений, а еще у меня есть вопросы что у нее общего с поиском и заменой текста
Времена изменились. Меня больше не шокирует, когда я встречаю программиста, который слышал о синтезе программ или даже пробовал инструмент верификации. В настоящее время существует несколько популярных продуктов, основанных на исследованиях передовых инструментов, и достижения в области искусственного интеллекта в целом изменили ожидания. Facebook даже внедрила автоматическое нахождение и исправление ошибок для своих сервисов.
Несмотря на это, исследования все еще на световые годы опережают то, что внедряется. Нет ничего необычного в том, чтобы прочитать статью 20-летней давности про инструмент, который, как было показано эмпирически, позволяет программистам в 4 раза быстрее справляться с задачей, а основная идея все еще пылится в подвалах университетов.
Я хотел бы рассказать о том, чего ожидать от передовых инструментов, и о том, как мы возвращаемся в прошлое. В этой статье я представлю 3 своих любимых инструмента за последние 30 лет, все из которых я пробовал использовать, но ни один из них в настоящее время не работает.
Модели отражения (Reflexion models)
Мы часто думаем о программном обеспечении с точки зрения компонентов. Для операционной системы это могут быть: файловая система, аппаратный интерфейс, диспетчер процессов. Опытный инженер, работавший над проектом, которого попросили ускорить запись определенных файлов на диск, точно знает, куда нужно идти в коде; новичок увидит аморфный блок исходных файлов.
В 1995 году, будучи молодым аспирантом Вашингтонского университета, Гейл С. Мерфи придумала новый способ изучения кодовой базы, названный моделями отражения.
Во-первых, вы выдвигаете приблизительную гипотезу о том, что, по вашему мнению, представляют собой компоненты и как они взаимодействуют:
Затем вы просматриваете код и записываете, как, по вашему мнению, каждый файл соответствует компонентам.
Теперь инструмент запускается и вычисляет фактические связи файлов (например, наследование классов, граф вызовов). Вы сравниваете это со своей гипотезой.
Вооружившись новыми доказательствами, вы уточняете свою гипотезу и делаете свою ментальную модель все более и более детальной, а также все лучше и лучше согласованной с реальностью.
Примерно в это же время группа программистов в Microsoft проводила эксперимент, чтобы увидеть, можно ли перепроектировать кодовую базу Excel, чтобы извлечь некоторые высокоуровневые компоненты. Им нужно было хорошо разбираться в кодовой базе, но это было не так-то просто, потому что они не работали над этим проектом ранее. Одному из них понравился доклад Гейл о моделях отражения.
За один день он создал свой первый вариант модели отражения для Excel. Затем он потратил четыре недели на ее уточнение по мере того, как он больше углублялся в код. Работая по этому способу, он достиг такого уровня понимания, который, по его оценкам занял бы у него 2 года.
Сегодня оригинальный RMTool Гейл давно неработоспособна. Инструмент для анализа C++ от AT&T, на котором он основан, Ciao, также недоступен. Позже была написана версия на Java, jRMTool, но он работает только со старой версией Eclipse с совершенно другим API. Код написан на Java 1.4 и уже не является даже синтаксически корректным. Я быстро оставил попытки заставить его работать.
Программная инженерия 2021 года: все еще догоняет 1995 год.
The WhyLine
Примерно 10 лет спустя в Институте взаимодействия человека и компьютера (Human-Computer Interaction Institute) в Карнеги-Меллон Эми Ко подумала о другой проблеме. Отладка похожа на детектив. Почему программа не обновила кеш после выполнения выборки? Что здесь делает отрицательное число? Почему так много работы, чтобы ответить на эти вопросы?
У Эми была идея инструмента под названием Whyline, где можно было бы задавать вопросы вроде «Почему произошло ___?» в интерактивном отладчике? Она сделала прототип Alice, инструмента графического программирования CMU, который позволяет детям создавать 3D-анимации. Люди были впечатлены.
Воодушевленная успехом, Эми, ныне профессор, провела еще пару лет, усердно работая над созданием технологии на Java.
Было проведено исследование. Взяли 20 программистов и попросили их исправить две ошибки в ArgoUML, программе на Java объемом 150 тыс. строк. Половине из них была предоставлена ??копия Java WhyLine. Программисты с WhyLine были в 4 раза успешнее, чем те, у кого инструмента не было.
Пару лет назад я пробовал использовать Java Whyline. Он сломался при взаимодействии с современной Java.
MatchMaker
В 2008 году мой советник, Армандо Солар-Лезама, только что прибыл в Массачусетский технологический институт после того, как в одиночку возродил сферу программного синтеза. Он в основном сосредотачивался на сложных задачах в небольших системах, таких как оптимизация физических симуляций и бит-тидлинг. Теперь он хотел решать простые задачи в больших системах. Большая часть программирования — это написание «связующего кода», например, взятие большой библиотеки стандартных компонентов и выяснение того, как скрепить ее вместе с вашим кодом. На копание в документации могут уйти недели, чтобы понять, как что-то делать в сложной структуре. Может ли помочь технология синтеза? Куату Есенову, казахскому гению, было поручено выяснить, как это сделать.
Связующий код часто представляет собой игру, в которой нужно выяснить, какие классы и методы можно использовать. Иногда нетрудно догадаться: например, в Android виджет размещается на экране с помощью метода addView. Но чаще это бывает не так просто. При написании плагина для Eclipse, который подсвечивает синтаксис, вам понадобится цепочка из четырех классов для соединения объекта TextEditor с RuleBasedScanner.
Если вы можете определить две конечные точки функции, какой класс ее использует и какой класс ее предоставляет, то вы можете попросить компьютер выяснить, что находится между ними. Существуют и другие программы, реализующие нужные вам функции. Запустив их и проанализировав трассировки, вы можете найти код, ответственный за «соединение» этих двух классов (в виде цепочки ссылок на указатели). Затем вы сводите эталонную программу именно к тому коду, который делает это! Так родился инструмент MatchMaker.
В ходе исследования, восьмерых программистов попросили создать простой инструмент для подсветки синтаксиса в Eclipse, чтобы подсвечивать два ключевых слова на новом языке. Половине из них был предоставлен MatchMaker и краткое руководство по его использованию. Да, было несколько руководств о том, как это сделать, но они содержат слишком много информации и бесполезны. Группа без MatchMaker ковырялась в среднем 100 минут. Другая группа быстро поняла, что им необходимо, и на это потребовалось всего 50 минут. Неплохо, учитывая, что специалисту с 5-летним опытом потребовалось 16 минут.
Мне действительно удалось применить Matchmaker, поскольку меня попросили поработать над его преемником в первый месяц моего обучения в аспирантуре. Я бы хотел увидеть, как он работает на Android. Увы, мы скатываемся назад. Несколько лет назад мой консультант нанял летнего стажера для работы над MatchMaker. Он сразу же столкнулся с препятствием: он не работает на Java 8.
Выводы
Первый вывод заключается в том, что инструменты, которые мы используем, во многом определяются выбором выдающихся людей. Причина того, что Reflexion Models неизвестна, в то время как Mylyn является одним из самых популярных плагинов для Eclipse, буквально потому, что Гейл С. Мерфи, создательница Reflexion Models, решила пойти в академические круги, а ее ученик Мик Керстен, создатель Mylyn, занялся промышленностью.
Инструменты для программирования — это не та область, где прогресс — это «идея, время которой пришло». Это происходит, когда есть много людей, работающих над похожими идеями; если один человек не принимает их идею, то кто — то другой сделает это через несколько лет. В инструментах программирования такого рода конкуренция встречается редко. Для примера: Известный профессор ушел в творческий отпуск, чтобы основать компанию, создающую инструмент для создания веб-сайтов. Я спросил его, почему, если его идея должна была превзойти все предыдущие подобные инструменты, это не было сделано раньше. Его ответ был примерно таким: «Потому что это требует технологии, которую только я могу реализовать».
Второй вывод заключается в том, что есть что-то неправильное в том, как мы создаем инструменты для программирования. Другие области компьютерных наук, похоже, не имеют такого гигантского разрыва между достижениями исследователей и практиков. Я уже утверждал, что это связано с тем, что сложность создания инструментов зависит больше от сложности языков программирования (или чрезвычайно сложны; просто посмотрите на C++), чем от идеи, и что до тех пор, пока это не изменится, ни один инструмент не может возникнуть без достаточного количества продаж, чтобы оплатить большие затраты на его создание. Вот почему моя кандидатская диссертация была посвящена упрощению создания инструментов. Именно поэтому я отчасти обескуражен распространением бесплатных, но не очень продвинутых инструментов: они разрушают рынок и затрудняют выплату постоянных издержек.
А третий вывод заключается в том, что мы, разработчики, можем требовать от наших инструментов гораздо большего. Если вы когда-нибудь задумывались о создании инструментов для разработчика, у вас есть много впечатляющей работы, чтобы извлечь из нее пользу. И если вы жаждете лучших инструментов, это то, что вы должны с нетерпением ждать.
Наши VDS можно использовать для разработки.
Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!
adictive_max