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

Редактирование: Я расширю это. Текущие системы репозиториев, такие как SVN или TFS, могут стать просто раздражающими при решении конфликтов. Если бы изменения, сделанные другим разработчиком, могли быть немедленно отражены в вашей системе, возможно, как-то выделены, тогда было бы проще понять, с чем не стоит связываться.

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

Эндрю Ко (бывший CMU, ныне профессор в U Wash) сосредоточил большую часть своей диссертации на том, чтобы позволить людям отлаживать, задавая вопросы "почему что-то произошло" или "почему не произошло". Проект назывался WhyLine, и у него даже была версия для Java.

Zero Button Testing - моя запись.

Я, наверное, ужасный человек, чтобы говорить об этом, так как я использую IDE, как программирование со свинцовыми грузами на руках, но я полагаю, что может быть полезно получить представление об этой стороне забор. Любые интересные или экспериментальные идеи, которые придумывают люди, по-прежнему должны удовлетворять базовые потребности инструментов разработчика.

IDE обычно представляет собой своего рода редактор, отладчик и компилятор. Так как это три отдельные части инструмента, я пропущу их по отдельности

Вот что я хочу от редактора

1. быть быстрым. Я никогда не хочу ждать, пока что-то загрузится. Когда-либо.
2. дают мне мощные способы манипулировать кодом и перемещаться по нему. Меня не волнуют кривые обучения, когда это инструмент, который я использую в среднем 10 часов в день, обратная сторона - я не хочу тратить свое время на то, чтобы научиться работать с инструментами, которые не являются мощными.
3. дают мне достойный способ открывать файлы. диалоговые окна открытия файлов недостаточно хороши, как и деревья проектов.
4. Хорошая поддержка для одновременного открытия множества вещей. У меня 27-дюймовый экран, вкладок недостаточно. В настоящее время я живу с разделениями, но было бы несложно придумать что-то лучшее.
5. никогда не заставляйте меня касаться мыши во время редактирования кода. Опять же, я не делаю этого. Меня не волнует кривая обучения, мне нужна скорость, эффективность и мощность.
6. Если вы дадите мне визуального дизайнера, он сделает меня более продуктивным, чем набор текста, при этом создавая код с таким же уровнем гибкости, как и я. возможность производить с текстом.Мне еще предстоит найти визуального дизайнера, который бы делал это, каждый из тех, что я когда-либо использовал, в основном снижает планку обучения тому, как что-то делать, но заставляет вас платить за ремонтопригодность и гибкость. Я рассматриваю каждый отдельный пример программирования, рисуя картинки, которые у меня есть, до тех пор, пока они не срабатывают, если они используются для серьезных целей (то есть не просто для того, чтобы что-то выбивать и не заботиться о качестве)
7. автоматические рефакторинги. Сейчас я использую vim, и единственное, что мне не хватает, - это возможность извлекать методы из других методов или нажимать кнопку, чтобы что-то переименовать и чувствовать себя в безопасности с тем, что будет делать инструмент.
8. анализ кода. Я хочу видеть синтаксические ошибки по мере их появления, видеть, набираю ли я избыточный код, или видеть предложения, есть ли лучший способ что-то сделать.
9. великий тестер. Я практикую TDD, и плохие тестировщики доводят меня до упора, так как это оказывает такое влияние на все, что я делаю.

то, что я хочу от отладчика

1. REPL. это сводило меня с ума, когда я застрял в визуальной студии, и я, вероятно, проводил больше времени в непосредственном окне, чем кто-либо другой в команде. Весь смысл отладчика - это способность исследовать, что происходит во время выполнения, если я не могу ввести произвольный код и посмотреть, что он оценивает, я чувствую, что у меня одна рука связана за спиной
2. способность изменять код «на лету», хотя и с приличным REPL и языком, он сам
3. позаботится о своей способности двигаться вперед и назад при выполнении.
4. скорость, не заставляйте меня ждать
5. хорошие способы прыгнуть в коде.если я нахожусь в строке 1 и хочу перейти на строку 500, чтобы увидеть, что происходит, я должен иметь возможность делать то

то, что я хочу от скорости компилятора

1. , по крайней мере, в режиме разработки. google go может скомпилировать 500 000 loc за миллисекунды на ноутбуке, вот о чем я говорю. Если язык нужно скомпилировать,каждая секунда просмотра вывода компилятора только усложняет выполнение того, что вы делаете (отслеживание ошибки, тестирование функции, запуск тестов и т. д.)
2. вам нужен какой-то способ подключиться к произвольным методам для pre и post выполнение или предварительная обработка файлов кода в более общем виде (подумайте о макросах для чтения lisp). если вы не можете сделать это с помощью языка, вам нужно уметь сделать это с помощью компилятора
3. хорошего анализа. скажите мне, где я напортачил во время компиляции, если вы не можете уловить это до прозрачности
4. . я действительно даже не хочу знать, что он там, если только я не взаимодействую с ним напрямую.

Что у меня есть

В настоящее время я использую vim, который дает мне 1, 2, 3 (с fuzzyfinder.vim / rails.vim), 4, 5 и очень плохой 8 (с syntastic.vim). У меня нет рефакторинга или анализа кода, и я очень скучаю по нему, но, IMO, это более чем стоит компромисса.

для отладки я использую ruby-debug, что на самом деле не так уж и хорошо. в основном вы получаете 1, 2 (больше причина рубина, чем рубиновая отладка) и 3, но это все.

Больше не использовать компилятор (слава богу), но отказ от него после использования его в течение 7 лет (по крайней мере, профессионально) действительно подчеркивает, какое ужасное влияние они оказывают на процесс разработки.