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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему ваш босс цепляется за 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 # для следующего. Помните, что вы можете проиграть битву, но все равно выиграть войну тоже.

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

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

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

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

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

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

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

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

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

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