Как я могу убедить моего босса, что ANSI C не подходит для нашего нового проекта? [закрыто]

64

Несколько месяцев назад мы начали разработку приложения для управления собственным испытательным оборудованием и записи набора измерений. Он должен иметь простой пользовательский интерфейс и, вероятно, потребует потоков из-за непрерывной записи, которая должна иметь место. Это приложение будет использоваться в течение нескольких лет, и в течение этого периода его будут поддерживать некоторые студенты, изучающие информатику.

Наш начальник получил высшее образование около 30 лет назад (не считая его оскорблением; у меня больше половины этого времени тоже на спине) и поручил нам разработать это приложение в ANSI C. Обоснование заключается в том, что он единственный, кто будет вокруг все время, и поэтому он должен быть в состоянии понять, что мы делаем. Он также постановил, что мы не должны использовать абстрактные типы данных; он даже дал нам список с именем глобальных переменных (вздох), которые он хочет использовать.

Я на самом деле пробовал такой подход некоторое время, но это действительно замедляло меня, чтобы убедиться, что все операции с указателями безопасны и все строки имеют правильный размер. Кроме того, количество строк кода, которые на самом деле связаны с рассматриваемой проблемой, составляло лишь небольшую часть нашей кодовой базы. Через несколько дней я полностью пересмотрел и начал использовать C #. Наш начальник уже видел, как работает программа, и ему нравится, как она работает, но он не знает, что она написана на другом языке.

На следующей неделе мы встретимся, чтобы обсудить исходный код, чтобы он «знал, как его поддерживать». Я немного напуган, и я хотел бы услышать от вас, ребята, какие аргументы я могу использовать в поддержку своего решения.

Трусливый твой,

стог
источник
220
«О нет, это не окончательная версия, это всего лишь версия C #, которую мы быстро написали за несколько дней для создания прототипа и тестирования, чтобы убедиться, что мы поняли требования и отладить пользовательский интерфейс. Реализация этого в ANSI C потребует еще X недель, потому что, вы знаете, мы должны работать вокруг , не имея всю эти фантазии структуры данных. ... Ну, да, теперь, когда вы упоминаете его, C # версия имеет уже делать все , что окончательная программа должна, но вы сказали , это нужно в ANSI C. ... Хорошо, если вы настаиваете, давайте останемся с этой версией ... "
Хайнци
8
@Heinzi: У меня был такой же опыт: я написал прототип C # библиотеки за 2 дня и потратил несколько недель на ее переписывание на C. К счастью, после этого проекта мне предложили перейти в другую команду с более разумный выбор языка.
Ден04
49
Глобальные переменные и потоки? У тебя неприятности, мой друг, независимо от того, какой язык программирования ты используешь.
Неманя Трифунович
16
Аргумент, который вам действительно нужен, заключается в том, почему вы должны продолжать работать.
2012 года
11
Ваше предположение неверно - ANSI C подходит почти для всех проектов. Вот почему он все еще популярен после всех этих лет. Является ли это оптимальным или нет, это другой вопрос.
Марк Рэнсом

Ответы:

108

Обратите внимание, что «Пожалуйста, сделайте это так, чтобы я был уверен, что смогу поддерживать его» на самом деле является очень хорошим требованием - большинство программ тратят гораздо больше времени на обслуживание, чем на написание, и поддержание решения в известной технологии обычно является хорошей идеей.

Представьте себе, если какой-то новый компьютерный парень, когда его попросили написать приложение на C #, написал его на Haskell в течение двух дней и сказал: «Эй, это работает, и я ушел, пока», оставив вам техническое обслуживание.

Представьте себе, если какой-то новый компьютерный ребенок, которого 15 лет назад попросили написать приложение ANSI C, написал его в Visual Basic 6 за два дня и оставил его. Теперь вы должны поддерживать его, и Windows 7 начинает жаловаться уже после установки установочного носителя .

Это может быть хорошей возможностью сказать - как намекал Хейнзи в комментариях - что «это быстрый прототип, написанный на C #, который очень похож на C - мы сделаем его готовым к производству или переопределим его в ANSI C, как вы спросил ", а затем принять обсуждение сейчас. Имея фактический источник информации, гораздо лучше, чем «Эй, разве мы не должны писать наше следующее приложение на Хаскелле, потому что оно быстрее».

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


источник
26
+1: за указание на требование «делай так, чтобы я был уверен, что смогу его поддержать». C #, безусловно, намного легче / быстрее, чем C, разрабатывать (в целом), но C изменился за последние 30 лет меньше, чем C # изменился за последние 15 лет. Таким образом, для продукта, который должен храниться в течение многих лет, C может быть более подходящим. Вы должны идти на компромисс между всеми требованиями: сложность проекта (C #, вероятно, лучший выбор), долгосрочное обслуживание (кажется, C более стабильный), кто будет выполнять обслуживание и т. Д.
Джорджио
4
@Ramhound Я говорю не о поддержке VB6, а о поддержке среды разработки Visual Basic 6 . Моя копия Windows 7 при вставке установочного носителя явно уведомила меня, что это не очень хорошая идея.
12
Хорошие моменты, но что, если босс попросил, чтобы это было написано на языке COBOL? Или 6502 сборка? В какой момент вы можете сказать своему боссу: «Этот язык устарел для этой цели, и как только вы уйдете, не останется никого, кто бы разбирался в этом»?
Муравей
6
@ Алекс: последовательность хорошая, правда. Но вы бы написали новую веб-систему на C, если бы все другое (не веб) программное обеспечение, написанное вашим отделом, было написано на C? Я думаю, что это сводится к балансу между выбором подходящих технологий для системы, которую вы пишете, и существующими навыками команды. Выбор языка без размышлений, потому что это то, что вы всегда используете, может быть вредным.
Муравей
8
@ant, тот, кто платит группе, выбирает музыку. (а мы магазин COBOL - не проблема, поддерживая это)
35

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

Таким образом, выбор состоит в том, чтобы сделать то, что он просит, или продемонстрировать, что вы можете завершить разработку И научить его, как поддерживать приложение C # в сжатые сроки и с меньшими затратами. Если вы не можете этого сделать, вы не соответствуете требованиям проекта.

Мэтью Флинн
источник
21
ФП явно проигнорировал требования без уведомления или обсуждения. Будучи начальником коммерческого клиента, он может отказаться от оплаты и, возможно, подать в суд на расходы, понесенные из-за потраченного времени. Поменяйтесь ролями, что если вы, например, заказали костюм на заказ и обнаружили, что портному не нравилось работать с тканью, которую вы указали настолько незаметно, какую он выбрал в своем выборе цвета? Проблема ОП сейчас заключается в том, что ему нельзя доверять проекты без строгого надзора, очевидно, что ему не хватает навыков людей и нет уважения к управлению.
2012 года
1
@epo Я полагаю, я понимаю ваше утверждение о том, что босс не может доверять ОП, поскольку они не делали то, что просили. Однако, если он разумный менеджер, этого не должно произойти. Если бы разработчик обратился к менеджеру с лучшим решением, чем первоначально предполагалось, я надеюсь, что менеджер будет открыт для него. Если я могу немного изменить ваш пример, это похоже на то, как портной делает костюм нужного цвета / рисунка с более новым, более прочным, более приятным на ощупь и более дешевым типом ткани, чем тот, о котором просили, даже если покупатель попросил тип ткани, с которой они были знакомы.
Тейлор Прайс
При этом я также согласен с тем, что в этом случае техническое обслуживание является важным требованием. ОП теперь обязан доказать менеджеру, что они выполнили остальные требования таким образом, чтобы менеджер мог быстро и эффективно научиться обслуживать.
Тейлор Прайс
26

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

Он быстрый, переносимый (я никогда не писал на C #, но я не думаю, что он работает без конкретной версии установленного фреймворка, и обычно он работает только на основе Windows).

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

Подводя итог, я бы сказал, что основной интерфейс с аппаратной частью C - это хороший выбор.

Matt
источник
7
Я добился большего успеха при переносе кода C # из Windows в Linux (используя Mono), чем с кодом C ++.
Dan04
8
@ dan04: Какие у вас были проблемы с C ++? Я думал, что C ++ будет вполне переносимым. Кроме того, C ++ - это не C. Я всегда находил использование C с библиотекой GNU C довольно переносимым, например, между GNU Linux и cygwin.
Джорджио
4
@ dan04 C! = C ++.
2
@ Джорджио: досадно большая часть этого была последовательностями. Нам пришлось убрать все TCHARдерьмо, характерное для Windows (которое мы все равно не использовали постоянно), и принять командный стандарт использования UTF-8 одновременно с переходом на Linux. К сожалению, для этого потребовалось повторно реализовать большую часть стандартной библиотеки в Windows, boost::nowideкоторой в то время не было.
Dan04
3
@ dan04: Как уже говорилось, C, конечно, не так выразителен, как C # (или C ++ в этом отношении), но я использую библиотеку GNU C ( gnu.org/software/libc ) с 1997 года, и она действительно стабильна и переносима. Для C ++ я бы посмотрел на Qt (или на boost и стандартные библиотеки), потому что они вполне переносимы. Если бы это было возможно, я бы избегал специфичных для Windows вещей: AFAIK никогда не было целью Microsoft выпускать портативное программное обеспечение, поскольку привязка клиентов является частью их маркетинговой стратегии.
Джорджио
24

О, Боже. Это приложение в реальном времени? Управление оборудованием в реальном времени? Сбор данных в режиме реального времени? Использование языка с сборщиком мусора? О, Боже.

Хотя я согласен с тем, что вы, вероятно, сможете сделать приложение на более современном языке за меньшее время, это, вероятно, не главный критерий. ПРОСТОТА ВАШЕГО ПРОГРАММИРОВАНИЯ ВЕРОЯТНО МНОГО МЕНЬШЕ ВАЖНО, ЧЕМ ДРУГИЕ КРИТЕРИИ, такие как те, которые установил ваш начальник, И время отклика, и детерминированное поведение.

Я бы предложил вам создать прототип на C # или Python, просто чтобы проверить основные функциональные возможности и пользовательский интерфейс. ТОГДА тестируйте его, измеряя фактические задержки и время отклика, когда приложение получает большой объем данных в течение многих дней непрерывной работы. Скорее всего, приложение может оказаться слишком медленным или отстать в случайное время, когда включается виртуальная машина или сборщик мусора.

Я предлагаю вам представить, что вы сделали в качестве прототипа.

Кодирование на С не так сложно. Если вы не до этого, так и скажите. Нас достаточно, чтобы принять вызов. (Я занимался кодированием на C в реальном времени уже десятилетия).

Гампи Гус
источник
3
Позволяет сформулировать первый немного по-другому. О, Боже. Это приложение в реальном времени? Управление оборудованием в реальном времени? Сбор данных в режиме реального времени? РАБОТАЕТ НА НЕРЕАЛЬНОЙ РЕЗЬБОВОЙ СРЕДЕ? О, Боже. Вам всегда придется пробовать, когда вы пересекаете границы устройства. «Реальное время» - это спорный вопрос и плохо сформулированное требование. C # в порядке.
Гусдор
Вы, очевидно, не слышали о работе Джо Даффи . Он занимается системным программированием на C # по крайней мере с 2013 года . Компилятор Roslyn может компилироваться в нативный код (именно так работает UWP), и сборка мусора не является проблемой, если вы обратите внимание на то, что делаете.
RubberDuck
14

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

Чем раньше вы справитесь с этим, тем лучше.

Во-вторых, я не думаю, что вы можете убедить его в том, что ANSI C неадекватен, что вам нужно сделать, это убедить его в нескольких других вещах (1), что c # является адекватным, (2) он может легко научиться поддерживать c #, (3 ) что вы были неадекватны для написания этого на C. Предполагая, что у вас все еще есть работа и роль для этого проекта, я бы сосредоточился на 2, подчеркивая сходство между c и c #.

Цитаты в ответ на комментарии ...

Несколько месяцев назад мы начали разработку приложения [...]. Через несколько дней я полностью пересмотрел и начал заново использовать C #

jmoreno
источник
Нигде он не упоминал, что строит версию C # месяцами?
Аноним
1
@ Аноним - Неважно, были ли это дни или месяцы, он все еще НЕ следовал инструкциям своих менеджеров. У автора явно не было навыков, необходимых для разработки приложения в ANSI C.
Ramhound
1
@Ramhound - я не оспариваю, что он не следовал инструкциям своих менеджеров, я просто говорю, что jmoerno разглядывал, как будто он потратил месяцы, уходя на касательные. Кроме того, если он собрал проект за пару дней, чтобы послужить рабочим прототипом, на котором может основываться указанная более стабильная версия C, то это имеет смысл. Это часть стадии планирования.
Аноним
@jmoreno - Извините, я неправильно понял вопрос.
Аноним
2
@jmoreno - Конечно. Я разместил свой последний комментарий после просмотра добавленной вами цитаты. Извинения еще раз.
Аноним
12

поручил нам разработать это приложение в ANSI C. Обоснование заключается в том, что он единственный, кто будет работать вокруг всего времени, и поэтому он должен быть в состоянии понять, что мы делаем.

Это довольно разумное требование.

Он также постановил, что мы не должны использовать абстрактные типы данных;

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

он даже дал нам список с именем глобальных переменных (вздох), которые он хочет использовать.

Хорошо, теперь это воняет. Теперь мы можем сказать, что ваш начальник имеет ограниченный опыт работы не только с различными языками программирования, но и с программированием в целом. Опытный программист-ветеран, независимо от языковых предпочтений, никогда не сделает такого заявления. (Единственное исключение, о котором я могу подумать, это то, что большая часть кода предназначена для запуска в довольно небольшой встроенной системе, и, следовательно, что вся необходимая рабочая память для кода должна быть предварительно выделена. Идея, что тот же самый код Ожидается, что пользовательский интерфейс на уровне экрана будет категорически против этого, однако).

Я предполагаю, что ваш босс никогда не участвовал в крупномасштабных, критически важных программных проектах, но он, скорее всего, ходил по разным некачественным.

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

C #, безусловно, имеет более симпатичный, чистый и менее неясный синтаксис, чем C. Он имеет много поддержки разработки программ, поскольку он имеет гораздо больше ключевых слов, связанных с OO, чем C. Но кроме этого, он не говорит вам, как писать свои программы. Если вы считаете, что все написанное на C ужасно по умолчанию, а все написанное на C # - небеса по умолчанию, я уверен, что вы пишете довольно ужасные программы на C #, даже не осознавая этого.

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

Сообщество
источник
1
+1 за «Вы можете легко писать одинаково непристойные программы и на C #».
Хавьер
11

Первый вопрос, который вам нужно решить, - это эмоциональный, иррациональный вопрос. ИТ-индустрия находится в состоянии постоянных изменений, и, хотя есть места для всего, отказ от улучшений или принятие изменений является проблемой.

Почему ваш босс цепляется за ANSI C? Если это единственный язык, который он или она знает, то, возможно, пришло время для перемен, но рационального аргумента может быть недостаточно. Будет ли ваш начальник чувствовать себя недооцененным или, возможно, уволенным, если его заставят работать на незнакомом языке? Подчеркните свой опыт и другие преимущества, которые он приносит.

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

Также рассмотрите это с вашей точки зрения. Почему вы хотите использовать C #? Насколько сильно это желание использовать что-то новое и классное? Будь честен с собой. Если вы узнаете это, это поможет вам более эффективно спорить.

Второй вопрос - это риск и стоимость. Написание программного обеспечения стоит дорого, и выбор языка является основным фактором в этом. Рассмотреть возможность:

  1. Сколько времени потребуется, чтобы написать в C # против C? С более легкой ориентацией объекта и лучшей сборкой мусора C # может быть проще. Однако, если приложение использует множество неуправляемых вызовов API, C может быть проще.
  2. Если вы используете C #, вам нужно приобрести дополнительные инструменты? Похоже, вы уже используете Visual Studio, но вам нужны дополнительные инструменты для локализации, проверки и анализа кода, отладки и так далее?
  3. Насколько легко поддерживать? Если вы нашли ошибку, как быстро ее можно исправить. C # может уменьшить эту ориентацию объекта. Автоматическая сборка мусора также позволяет избежать большинства проблем с утечкой памяти и указателями.
  4. Насколько это легко поддерживать? Если у вас есть вспомогательный персонал, он может знать, как читать аварийный дамп, но знают ли они, как использовать windbg с SOS? На целевых машинах уже установлена ​​соответствующая версия .Net framework?
  5. Рассмотрим штатное расписание. Сколько людей знают C против C #? Если вы или оба покинули организацию, насколько легко было бы заменить вас? Разработчики C дешевле или дороже разработчиков C #?

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

Возможно C - лучший выбор. C # не лучше автоматически для всех ситуаций. Может быть, вы делаете этот проект с использованием C, но создаете концепцию C # для следующего. Помните, что вы можете проиграть битву, но все равно выиграть войну тоже.

Актон
источник
5
Я не согласен с неявным предположением, что C # по умолчанию является лучшим выбором, чем ANSI C. Например, если вы хотите оставаться независимым от платформы, C #, скорее всего, плохой выбор.
@ ThorbjørnRavnAndersen Я согласен. Пожалуйста, смотрите последний абзац. Я также упоминаю такие случаи, как вызов неуправляемого кода. Я предполагаю, что независимость платформы исключила бы C # в OP. Возможно, это неверное предположение.
Актон
1
Независимость платформы была лишь одной из возможных причин. Формулировка «цепляться за ANSI C», на мой взгляд, указывает на предвзятость.
@akton - С каких это пор нельзя вызывать неуправляемый код из C #. Конечно, для этого требуется оболочка, что создает дополнительные проблемы со службой поддержки, но это возможно. Кроме того, вы можете поддерживать C # на нескольких платформах, если хотите. Mono - поддержка на всех основных настольных платформах (OS X, Windows и Linux). Учитывая, что .NET Framework на базе Microsoft Windows продвигает базу функций Mono, она не будет точно соответствовать (это уже имеет место в WPF), и, конечно, вы не сможете разрабатывать приложения Metro, работающие в Linux. Конечно, вряд ли это будет сделано в этом случае.
Ramhound
@ Ramhound Я не говорил, что вы не можете вызывать неуправляемый код из C #, просто большая его часть может причинять боль. Точно так же вы можете заниматься кроссплатформенной разработкой на C #, но C почти универсален, как сказал Торбьерн.
Актон
7

Возможно, еще один аргумент: вероятно, очень трудно найти студентов-информатиков, у которых достаточно опыта, чтобы писать код на C без ошибок. ANSI C - это не первое, что люди изучают сегодня.

Теперь все студенты информатики убьют меня.

Johnb
источник
ANSI C был фактически одним из первых вещей, которые я изучил в колледже. Я начал в 2004 году. Так что в течение последних 10 лет его все еще учили. Я провел много поздних ночей, подключенных через SSH к среде Unix, пытаясь скомпилировать мой код.
Ramhound
1
Забавно, я не изучал ANSI C до последнего года обучения в университете. Первым языком, который преподавали, был Паскаль, так что я защищен ...
Технит
Недавний выпускник здесь; у нас было знакомство с C и C ++, однако C был во встроенном контексте и минимален. Оба были в мой последний год - чисто C # и Java до этого.
Росс
2
C просто трудно программировать правильно, вероятно, лучший аргумент против использования C.
Пол Натан
7

Вы полностью не смогли убедить нас в том, что ANSI C был неадекватным. C - отличный язык, который, кажется, адаптирован для задач, которые вы описали. С кратким описанием задачи (кроме требований к языку) я бы также порекомендовал C (или, возможно, пойти).

Я думаю, проблема в том, что вы программировали на C, думая на C #. У меня похожая проблема, когда я переключаюсь с Perl на C или Java. Вы должны научиться адаптироваться к языку, а не учиться переводить с вашего мышления на язык дня.

Проблема не в вашем боссе и не в языке C, а в том, чтобы открыть свой разум для разных способов мышления. Смена языка программирования принесет вам пользу.

BOC
источник
4
Спасибо за ответ на ваш первый вопрос о программистах Stack Exchange. Тем не менее, вы можете захотеть сделать ваши будущие ответы немного менее личными, не используя фразы типа «вы полностью провалились», «проблема заключается в том, чтобы открыть свой ум». Пожалуйста, просмотрите часто задаваемые вопросы programmers.stackexchange.com/faq#etiquette . Я думаю, что вы можете сделать хорошее описание вашей точки зрения с нейтральным языком.
DeveloperDon
2

Прежде всего, вы должны сказать своему боссу, что это на другом языке, сейчас. Он будет (понятно) рассержен, если вы целенаправленно вернете что-то против требований без уведомления.

Теперь лучший способ объяснить это боссам / менеджерам - это с точки зрения времени и денег. Оцените, сколько времени займет такой проект в ANSI C, а затем оцените, сколько времени потребуется для чего-то более высокого уровня, такого как C #. Заметьте, я сказал более высокий уровень, а не современный. Это также может помочь сгладить ситуацию. Я имею в виду, что вы бы не занимались рисованием комнаты с помощью крошечной кисти, вы бы использовали валики и другие вещи, которые заставляют каждый штрих (строку кода) покрывать большую часть проекта. Кроме того, если вы или один из членов вашей команды не знаете C или не хотите делать большой проект на C, это отнимает еще больше времени, потому что им придется набирать скорость.

Это также звучит так, будто твой босс пытается микроуправлять. Я уверен, что один из других ответов попытается объяснить, как заставить вашего босса делать это меньше

Earlz
источник
Доступность кажется возможным аргументом. Хотя босс (как клиент, согласно предложению @ MatthewFlynn) утверждает, что он не может позволить себе не писать программу на C, OP может утверждать, что босс также не сможет позволить себе затраты на внедрение и обслуживание, связанные с программой. написано на C. В любом случае, компромиссы необходимы, чтобы все произошло.
Rwong
1

Отвращение супервизора к ADT было рассмотрено в другом месте, так как разработчик, по-видимому, не знал о затратах GC, поэтому я сосредоточусь на «потоках».

Возможно, вместо того, чтобы думать с точки зрения потоков .NET (или JVM, если так внушают), вам может потребоваться несколько процессов, использующих некоторый механизм межпроцессного взаимодействия (IPC) для связи между ними. Например, сообщения Windows, общая память, буфер файлов с отображенной памятью, именованный канал, что угодно. Выделите небольшие процессы для взаимодействия с устройством или аспектом устройства и проверки IPC для передачи обновлений и подтверждения запросов, а также несколько более сложный процесс для поддержки графического интерфейса пользователя и связи с «мониторами» оборудования с использованием любого IPC, который вы выбираете.

Roboprog
источник