Этого - нет, согласен. Разве что интегрированные UML средства .. но и они "не айс". Мне кажется, что в этом плане ДРАКОН - лучше охватывает часть вопросов по диаграммам действия.
P.S. Хвалить взялся, поскольку не была развернута претензия к современным ИДЕ. Можно совместить тезисы в защиту и первоначальные претензии:
IDE не облегчают, а затрудняют работу разработчиков в следующих важных случаях:
1. Маленькая программа, которая печатает "Привет, мир!", неплохо выглядит в Eclipse. А с большим, длинным файлом с тысячами строк кода работать трудно... значительно легче чем без ИДЕ .. (может есть где ещё лучше, но тогда требуется уточнение автора)
2. Чаще всего больших файлов еще и много, а со многими файлами работать еще труднее, чем с одним.. см. выше. труднее, как и со всяким бОльшим делом. Не зависит от ИДЕ или вообще средства, "общее утверждение" ..
3. Трудно понимать конструкции языка программирования, такие как if, if/else, if/if, try/catch/finally.. это не так ..
4. Трудно проследить вызовы методов.. это не так ..
5. Трудно проследить код и вызовы, относящиеся к данному use-case или тикету Jira.. зависит от точности формулировки в багтрекерах, самого багтреккера и авторах формулировок, вопрос шире чем претензия к ИДЕ ..
6. Трудно просмотреть результаты поиска кода, нужно нажать на каждое попадание, а их может быть много.. не обязательно. Можно рассмотреть "весь список", можно получить аннотации по найденному "где" оно найдено, без тыканий. Вчера замерил: PHP Storm выдача из 250 попаданий анализируется примерно за 1-3 минуты в незнакомом проекте, что полезно, что взято из сторонних библиотек и к вопросу не отностится". Как-то так.
7. Трудно взять трассировку стека исключительной ситуации и определить ее причинуОтладочные комплекты в разных ИДЕ могут существенно различаться как от ЯВУ, так и быть вообще заменены иным плагином. Тут не в курсе, ибо этой стороной ИДЕ давно не пользовался за ненадобностью (правильное написание кода практически исключает процесс отладки)
8. Трудно работать и с Java и с JavaScript в одном проекте.. это не так ВОВСЕ. Наиболее общие тут как раз PHP-IDE имеют одинаково развитые средства для: PHP, JS, JAVA, SQL, HTML, CSS, JSON, XML и др. Могут автоконтролировать изменения сторонних библиотек и выкачивать их обновления самостоятельно, поддерживая актуальную версию в разработке Composer, etc. ..
9. Трудно смотреть на значения переменных времени выполнения.. вопрос организации процесса отладки. С/С++ поддержка в ИДЕ меня устраивает "более чем". ..
10. Трудно осуществлять контроль над изменениями кода.. нет! Очень легко. Поддержка практически всех версий репозиториев от старых SVN до супер новых и распределенных типа GIT, сильная помощь в слиянии одновременных изменений merge, ведении и временном переключении веток, одновременная разработка в нескольких ветках (ой, а можно тут по-быстрому вставить - легко), а также кто делал, что делал, когда делал ..
11. Трудно производить обзор кода с коллегами программистами.. не понято что трудного с коллегами. Прямо сейчас работаю над очень небольшим проектом на ПХП из 10-ка каталогов по 10-30 файлов по 800-2000 строк кода. Простенькая CRM-система, Yii2.0 + angular1.5 + ещё 3-5 сторонних библиотек по мелочи (не входит в указанный объем, лежит отдельно), примерно 20-30 use-case "итого". Полноценный фасетный поиск по 28-и параметрам главной сущности и примерно половины подчиненных сущностей БД (около 10 таблиц) + подчинение 2-го уровня, реализовано на Yii + прямая табличная верстка без angular сделано за .. 3 дня, если не считать времени ознакомления с этой частью Yii 2.0 (+2 дня). Да, надо сказать что автор, то бишь коллега уволился не оставив в коде ни одного комментария. Разбор незнакомого исключительно силами ИДЕ и краткому "напутственному рассказу". Если бы не мощь ИДЕ .. в какой стадии "охвата проекта" я бы находился сейчас? Прошел месяц.
12. Трудно обсуждать код с не-программистами.. с не программистами КОД - обсуждать незачем. Вот так категорично. С ними можно обсуждать алгоритмы в самом общем виде, структуры данных, способы взаимодействия "входы/выхода" программы с внешними, "непрограммными устройствами", в т.ч. и "пользователями" и т.д.
В общем, складывается ощущение что
котята не нравятся из-за неумения их готовить.P.S. Даже больше скажу в защиту современных средств разработки ПО: я, начинавший когда-то давно в цифре, да ещё и двоичной, потом освоивший перфокарты и перфоленты .. клавиатур не было .. потом пересевший за клавиатуру и монитор .. во время моих трудовых будней появились и С++, и JAVA и много чего ещё ..
Сейчас, считаю что профессия программист практически полностью утрачена разрабами в возрасте от 30 лет и младше ИСКЛЮЧИТЕЛЬНО благодаря развитым инструментам и средствам поддержки процесса разработки. Современный программист - это просто пользователь таких систем, зачастую даже не вникающий ни в их организацию, ни в "сторонние библиотеки", которые сообщество программистов производит с просто чудовищной скоростью.
И это хорошо видно по вакансиям: посмотрите кто требуется? А ровно те, кто отлично знает и имеет опыт .. средства разработки, те или иные библиотеки и т.д. Кому сейчас нужны вопросы правильной алгоритмизации, оптимизации кода, правильного проектирования, написания программ не требующих тестирования, разве что на синт. ошибки, которые в ИДЕ и совершить то не так просто .. а НИКОМУ. Автоматика ПО для разработчиков сделает это всё за него. По сути разработку сейчас ведет само ИДЕ, а программист .. он так, кнопки жать. Да даже типовые интерфейсы crud можно ваять автоматически, тыкая кнопки "надо чтобы было это и то и связывалось с этим вот так"..
P.P.S. Извиняюсь за многа букв .. старею видимо. Наболело.