Як я можу переконати мого шефа, що ANSI C є неадекватним для нашого нового проекту? [зачинено]

Кілька місяців тому ми почали розробляти додаток для управління внутрішньо розробленим тестовим обладнанням і записувати набір вимірювань. Він повинен мати простий інтерфейс користувача і, ймовірно, потребуватиме потоки через безперервну запис, який має відбуватися. Цей додаток буде використовуватися протягом декількох років, і його повинен підтримувати декілька студентів з інформатики протягом цього періоду.

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

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

Наступного тижня ми вдвох зустрінемось, щоб перейти до вихідного коду, щоб він "знав, як його підтримувати". Мені якось страшно, і я хотів би почути від вас, хлопці, які аргументи я можу використати, щоб підтримати своє рішення.

Боягузливий твій,

Зауважте, що "Будь ласка, зробіть це так, я впевнений, що я можу це підтримувати" - це насправді дуже гарна вимога - більшість програм витрачають значно довше, ніж пишуть, а зберігання рішення у відомій технології зазвичай є хорошою ідеєю.

Уявіть собі, якщо якийсь новий комп’ютерний хлопець, коли його попросили написати додаток на C #, написав його в Haskell за два дні і сказав: "Ей, це працює, і я пішов, до побачення", залишивши технічне обслуговування на вас.

Уявіть собі, якби якийсь новий комп’ютерний малюк, коли його просили написати програму ANSI C 15 років тому, написав це у Visual Basic 6 за два дні та залишив його. Тепер ви повинні підтримувати його, і Windows 7 починає скаржитися вже тоді, коли вставляється інсталяційний носій .

Це може бути гарною можливістю сказати - як натякав Хайнці в коментарях, - що "це швидкий прототип, написаний на C #, який, схоже, схожий на C - чи будемо ми готові до виготовлення, чи повторно впровадити його в ANSI C, як ти запитав ", а потім прийміть дискусію зараз. Маючи фактичне джерело, щоб побачити, це набагато краще, ніж "Ей, чи не слід писати наступну заявку в Haskell, тому що це швидше".

Іншими словами - тепер у вас є можливість продемонструвати, що можна розглянути нову платформу. Повідомте, що ви писали прототип перед переглядом коду - це допоможе зняти враження, що ви намагаєтесь прокрасти C # під радаром. Я б запропонував вам також продемонструвати, що весь існуючий код, написаний в ANSI C, можна використовувати зсередини C #. Особисто я вважаю, що вам скажуть, що ціллю залишається ANSI C, щоб залишитися на єдиній платформі.

У цьому випадку ваш бос, здається, буде вашим клієнтом, і його головна вимога полягає в тому, щоб він міг підтримувати додаток, коли ви рухаєтесь далі. Це здається цілком розумним.

Отже, вибір полягає в тому, щоб зробити те, що він просить, або продемонструвати, що ви можете завершити розробку І навчити його, як підтримувати додаток C # в обмежені терміни і за меншими витратами. Якщо ви не можете цього зробити, ви не відповідаєте вимогам проекту.

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

Це швидкий, портативний (я ніколи не писав на C #, але я не думаю, що він працює без встановленої конкретної версії фреймворку, і це, як правило, лише на основі Windows).

У будь-якому випадку ви можете використовувати іншу мову, щоб зробити GUI. Але ви можете заощадити зусилля і просто скористатися наявним пакетом трендів (є кілька хороших відкритих джерел).

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

Можливо, ще один аргумент: напевно, дуже важко знайти студентів з інформатики, які мають достатньо досвіду для написання коду С, не допускаючи помилок. ANSI C - це не перше, про що люди сьогодні навчаються.

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

Ви повністю не змогли переконати нас у тому, що ANSI C був неадекватним. C - це відмінна мова, яка здається пристосованою до типу завдань, які ви описали. З коротким описом завдання (крім вимог до мови) я також рекомендував би C (або, можливо, піти).

Я думаю, що проблема полягає в тому, що ви програмували на C, маючи на увазі мислення на C #. У мене є аналогічна проблема, коли я перемикаюся з Perl на C або java. Ви повинні навчитися адаптуватися до мови, а не навчитися перекладати зі свого способу мислення до мови дня.

Проблема не у вашому начальнику чи мові С, проблема полягає в тому, щоб відкрити свій розум на різні способи мислення. Зміна мови програмування - це користь для вас.

Спочатку потрібно сказати своєму начальникові, що це вже іншою мовою. Він буде (зрозуміло) злим, якщо ви повернете щось цілеспрямовано проти вимог без попереднього повідомлення.

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

Це також звучить, як ваш начальник намагається мікромініструвати. Я впевнений, що одна з інших відповідей спробує пояснити, як змусити вашого шефа зробити це менше

Відраза наглядача до ADT була розглянута в іншому місці, як і немовби невідомий розробник витрат GC, тому я зупинюсь на "потоках".

Можливо, замість того, щоб думати з точки зору .NET (або JVM, якщо це так індоктриновано) нарізування, то, що ви можете хотіти, - це декілька процесів, використовуючи якийсь механізм міжпроцесорної комунікації (IPC) для спілкування між ними. Напр. - вікна повідомлень, спільна пам'ять, файловий буфер з картографічною пам'яттю, названа труба, що завгодно. Виділіть невеликі процеси взаємодії з пристроєм або аспектом пристрою та перевірки IPC для передачі оновлень та підтвердження запитів, а також дещо більший процес для підтримки графічного інтерфейсу та спілкування з "моніторами" обладнання, використовуючи будь-який IPC, який ви вибрали.