Создание САПР⁠⁠

Движок - на смеси C и C++, высокий уровень (GUI и скриптинг) - на специфическом диалекте Lisp. IDE референсной нет, все пишут под чем хотят. В силу консервативности продукта, его Unix-происхождения, и ориентирования на лисп, многие кодят в Emacs. Но это только у нас. В других компаниях мб другие технологии

Подскажите, пожалуйста, как Вы и ваши коллеги реализуете логику работы своего приложения? Понятно, что по ТЗ, но кто составляет эти ТЗ?

Если хотелка идёт со стороны заказчика, то она попадает к Application engineers - нашим сотрудникам, являющимся продвинутыми юзерами продукта и обладающим знаниями предметной области - они непосредственно контактируют с заказчиком. В других компаниях название этих сотрудников может быть другое, например Business analysts (аналитики). Также предложения по изменению могут появляться не только у заказчика но и у нас самих, например на уровне менеджмента отдела ("Давайте сделаем фичу") или даже от обычного Application / Software engineer (например заметили баг). Далее тем сотрудником, от которого исходит требование, создаётся тикет. С тикета начинаются вообще любые действия. В простейших случаях, требуемое в тикете изменение в коде может напрямую внести Software engineer без всякой спецификации (если масштаб небольшой, например фиксится баг). Если же требуется нечто более масштабное, то усилиями Application engineers, с привлечением технического руководства отдела, создаётся Requirements spec - документ, описывающий требуемое поведение CAD системы со стороны её юзера. (В "правильных" командах эта спека пишется в формальной нотации (IDEF0 итд), у нас же она идёт в свободной форме. Естественно, там могут быть графики, куски скриптов итд. Например в нашем случае (eCAD/EDA - сапры по проектированию микроэлектроники) скажем в индустрии появляется техническая новинка - фотоника в интегральных схемах https://en.wikipedia.org/wiki/Photonics#Photonic_integrated_.... Клиенты хотят возможность добавлять в чип элементы фотоники, такие как волноводы, и высказывают своё понимание как эти новые элементы должны взаимодействовать со всем остальным. Это пример крупного проекта, от года и более. Далее техническое руководство отдела вместе с менеджментом отдела назначают Project team, в которую входят один или несколько: Project architect, Project manager, Project engineer, QA и прочие роли. Тот, кого назначили Project architect, на основании Requirement spec пишет техническую спеку - Functional spec, в которой описываются непосредственно изменения в коде, новые классы, диаграмма классов, модель данных итд.

Какого они объёма и что в них входит?

Что входит уже сказал, объём от двух до пары десятков страниц A4, хотя бывает и больше.

Реагируете ли на обратную связь от пользователей?

Конечно реагируем, есть система тикетов.

Задаю эти вопросы потому, что при работе с указанными мною САПР, меня не покидает мысль, что многие вещи можно было сделать по-другому, многое добавить, многое убрать/упростить (...)

Предложения по изменениям, возникающее внутри производителя САПР а не у клиента, как я уже сказал это нормальное явление

Я разработчик движка крупной CAD системы. Непонятен Ваш вопрос. Спроектировано всё так же как в любом большом/корпоративном софте наверное. Если нужен просто пример хорошего кода, их валом в книгах и других проектах. Знание же как устроены кишки условного оркада ничего вам не даст, если вы только не такой же разработчик движка.

вы как больной раком спрашиваете "как обучиться лечить людей?".

был бы спрос с деньгами подрядчик найдется.

Нужна команда квалифицированных в этом вопросе и мотивированных людей(деньги неплохая мотивация) и четко поставленное тз.

YouTube●19:42

Я разработчик движка крупной CAD системы. Непонятен Ваш вопрос. Спроектировано всё так же как в любом большом/корпоративном софте наверное. Если нужен просто пример хорошего кода, их валом в книгах и других проектах. Знание же как устроены кишки условного оркада ничего вам не даст, если вы только не такой же разработчик движка.