MuseScore действительно достойный инструмент. Я перепечатывал некоторые ноты из книг и получал удовольствие. А вот в муз. колледжах используют всякую дичь для обучения, которая давно не поддерживается и с трудом совместима с Windows 10.
QtCreator умеет открывать отчёты анализатора в формате TaskList. Специальных плагинов пока нет. В плане анализа много диагностик прокачены для поиска специфичных ошибок для Qt. Cходу могу вспомнить только QString, но там много разных классов.
Записали. Про отсутствие анализатора понимаю. У многих вендоров собственные типы проектных файлов, что ничего хорошего не подключишь. Тем не менее, мы обошли эту проблему. Хотите попробовать PVS-Studio одним из этих способов? Ещё зависит от компилятора и платформы. Если ARM-компилятор, то шансы запустить нас велики.
Наc это не удивляет, т.к. существует объяснение эффекту. Вспомогательные инструменты IDEA и других IDE относятся к Productivity Tool. Они помогают улучшать код, но не обязывают этого делать. Мы же позиционируем себя как классический статический анализатор кода. Правильное применение методологии способствует реальному контролю качества.
А так да, бывает руководитель видит похожую пользу от IDE, видит, что она есть у всех и принимает это за «контроль качества». А вот нельзя доверять на 100% программистам в плане качества, и хороший руководитель знает это.
если подключить статический анализатор, то он тоже выдаст кучу предупреждений о потенциально опасном коде
Типичный проект без какого-либо контроля качества выглядит примерно так, как вы написали. Но это только первый запуск будет таким. На этот случай есть отключение выдачи предупреждений на существующий код. А на новом коде предупреждения уже появляются в приемлемом количестве. И есть возможность вернуться к техническому долгу.
То, что Вы перечислили, вовсе не фантастика. А часть этапов вообще автоматизируется и не «кушает» ресурсы компании. Клиентоориентированность всегда будет цениться. Тут всё зависит от того, как компания позиционирует фидбек пользователей: как обузу или источник информации.
Я считаю это не удобным при локальном хранении и редактировании. А в случае сайта/форума с редактором md меня, например, не беспокоит, где хранятся картинки и как они версионируются.
Я предложил практичную идею в контексте статьи, а не готовое решение. На самом деле многие компании делают именно плагины для Word, т.к. это достаточно просто. Может кто-нибудь ещё подсмотрит. Я бы не стал называть пользователей GitHub массовым пользователем документов в целом. Всё-таки, большинству не IT пользователей комбинация VS Code + MD + Git + Image Dir будет слишком сложной.
У Word есть встроенное версионирование, которое запускается диффером Git или SVN. Очень редко пользуемся.
У нас много совместной работы с документами, поэтому был разработан специальный конвертер, но вот чтоб мы чувствовали ограничение от коллекстивной работы — не было такого.
Был период, когда можно было внести изменения в нашу работу, я смотрел на md, но так и не понял, куда деть картинки. Сейчас они запакованы в .docx. Каталог с документами выглядит удобным и понятным. Как бы вы хранили картинки, если они используются в нескольких тысячах документов?
Код нашего плагина закрыт, т.к. это только малая часть всей внутренней «кухни» по управлению документами в компании.
Думаю, мухи тут не причём. Если они, конечно, не слетелись на код :D
Я хотел сказать, что за 10 лет существования такого формата мы выяснили, что кто-то воспринимает критику кода, а кто-то нет. Это всё зависит от конкретного человека, а не материала или какой-то морали.
Вы не дали ответ на вопрос, потому отмазка. А Ваши реальные пользователи — достаточно продвинутая технически аудитория, особенно из бесплатного сегмента, т.к. всё приходится настраивать самим.
Нам стоило, конечно, объяснить свою позицию по этому поводу сразу.
Именно! Надо было просто выйти на связь. Как мы уже обсудили с vorozcov выше, общение с внешним миром проблема многих IT компаний. Причём тематика вообще не важна. Это фундаментальная проблема.
А так да, бывает руководитель видит похожую пользу от IDE, видит, что она есть у всех и принимает это за «контроль качества». А вот нельзя доверять на 100% программистам в плане качества, и хороший руководитель знает это.
Я считаю это не удобным при локальном хранении и редактировании. А в случае сайта/форума с редактором md меня, например, не беспокоит, где хранятся картинки и как они версионируются.
У нас много совместной работы с документами, поэтому был разработан специальный конвертер, но вот чтоб мы чувствовали ограничение от коллекстивной работы — не было такого.
Был период, когда можно было внести изменения в нашу работу, я смотрел на md, но так и не понял, куда деть картинки. Сейчас они запакованы в .docx. Каталог с документами выглядит удобным и понятным. Как бы вы хранили картинки, если они используются в нескольких тысячах документов?
Код нашего плагина закрыт, т.к. это только малая часть всей внутренней «кухни» по управлению документами в компании.
Я хотел сказать, что за 10 лет существования такого формата мы выяснили, что кто-то воспринимает критику кода, а кто-то нет. Это всё зависит от конкретного человека, а не материала или какой-то морали.