ANSI Cが新しいプロジェクトには不十分であることを上司にどのように説得できますか？
数か月前、社内で開発したテスト機器を制御し、一連の測定値を記録するアプリの開発を開始しました。シンプルなUIである必要があり、継続的な記録を行う必要があるため、スレッドが必要になる可能性があります。このアプリケーションは数年間使用され、この期間中、多くのコンピュータサイエンスの学生によって維持されます。
私たちの上司は約30年前に卒業しました（犯罪と見なさないでください。私もその半分以上の時間を背負っています）、ANSI Cでこのアプリケーションを開発することを義務付けています。理論的根拠は彼が唯一のずっといるので、彼は私たちがしていることを理解できなければなりません。彼はまた、抽象データ型を使用してはならないと決定しました。彼は私たちに使用してもらいたいグローバル変数（ため息）の名前のリストもくれました。
実際にしばらくその方法を試しましたが、すべてのポインター操作が安全で、すべての文字列が正しいサイズであることを確認するのが本当に遅くなりました。さらに、実際に手元にある問題に関連するコードの行数は、コードベースのほんのわずかな部分でした。数日後、私はすべてを廃棄し、C＃を使用して新たに始めました。私たちの上司はすでにプログラムが実行されているのを見てきましたが、彼はそれがどのように機能するかを気に入っていますが、別の言語で書かれていることを知りません。
来週、私たち2人はソースコードについて話し合うために会い、彼が「それを維持する方法を知っている」ようにします。私はちょっと怖いので、私の決定を裏付けるためにどのような議論ができるかを皆さんから聞きたいと思います。
臆病なあなたのもの、
「このようにしてください[〜＃〜] i [〜＃〜]それを維持できる」は実際には非常に良い要件です-ほとんどのプログラムは通常、既知のテクノロジーでソリューションを記述し、維持することは良い考えです。
C＃アプリケーションの作成を依頼された新しいコンピューターの子供がHaskellで2日間でそれを作成し、「おい、それで動作するのでさようなら」と言ってメンテナンスを任せたと想像してみてください。
15年前にANSI Cアプリケーションを作成するように依頼された新しいコンピュータの子供がVisual Basic 6で2日間それを作成し、それを残したと想像してみてください。今、あなたはそれを維持する必要があり、Windows 7はインストールメディアが挿入されたときのときに既に不平を言い始めます。
これは、Heinziがコメントでほのめかしたように、「これはC＃で書かれたクイックプロトタイプであり、たまたまCに非常によく似ている-プロダクションの準備を整えるか、あなたのようにANSI Cで再実装するべきか」と尋ねた後、今すぐディスカッションを受けてください。実際のソースを表示することは、「次のアプリケーションをHaskellで作成するほうが速いので、そうするべきではない」よりもはるかに優れています。
つまり、新しいプラットフォームを検討できることを実証する機会が与えられます。プロトタイプを作成したことを確認してくださいbeforeコードレビュー-これは、レーダーの下にC＃を潜入させようとしている印象を取り除くのに役立ちます。 ANSI Cで記述されたすべての既存のコードがC＃内から使用できることも示すことをお勧めします。個人的には、ターゲットは単一プラットフォームにとどまるANSI Cのままであると言われると思います。
この場合、あなたの上司はあなたの顧客であるように思われ、彼の主要な要件は、次に進むときにアプリケーションを維持できることです。これはかなり合理的なようです。
したがって、選択は、彼が要求することを行うか、または開発を完了し、時間の制約内で低コストでC＃アプリケーションを維持する方法を彼に教えることができることを示すことです。それができない場合は、プロジェクトの要件を満たしていません。
あなたは多くの情報を提供していませんが、Cは完全に正しい選択だと思います。私は工業プラントのエンジニアとして働いており、私たちのコードの（すべてではないにしても）ほとんどがCで書かれています。デバイス（ここでは、流量計または熱電対などを想定しています）を表示し、ほぼリアルタイムのCで表示することをお勧めします。
高速で移植性があります（C＃で記述したことはありませんが、特定のバージョンのフレームワークがインストールされていない場合は機能しないと思います。通常はWindowsベースのみです）。
必ず、別の言語を使用してGUIを実行できます。しかし、労力を節約して、既存のトレンドパッケージを使用することもできます（利用可能な優れたオープンソースパッケージがいくつかあります）。
まとめると、ハードウェアパーツCとの基本的なインターフェイスは良い選択です。
まあ。これはリアルタイムアプリケーションですか？機器をリアルタイムで制御していますか？リアルタイムでデータを収集していますか？ガベージコレクターで言語を使用していますか？まあ。
あなたはおそらくより短い時間でより近代的な言語でアプリを実行できることに同意しますが、それはおそらく主要な基準ではありません。プログラミングのしやすさIS上司が設定したもの、応答時間、決定論的な動作など、他の基準よりも重要ではない可能性があります。
主な機能とUIをテストするためだけに、C＃またはPythonでプロトタイプを作成することをお勧めします。次に、アプリを大量のデータにヒットしたときの実際のレイテンシと応答時間を測定し、何日もの継続的な実行で、その全体をテストします。 VMまたはガベージコレクターが作動すると、アプリが遅くなりすぎたり、ランダムなタイミングで遅れたりする可能性があります。
あなたがプロトタイプとして行ったことを提示することをお勧めします。
Cでのコーディングはそれほど難しくありません。あなたがそれに気づいていないなら、そう言ってください。挑戦する私たちがたくさんいます。 （私は何十年もの間リアルタイムCコーディングを行ってきました）。
さて、最初にすることはあなたの上司に行って騒ぐことです。あなたは彼の明確な要求を無視しました、そしてさらに悪いことに何ヶ月もそうしています。あなたがこれにどれだけの時間を費やしたかは分かりませんが、それがプロジェクトを完了するために割り当てられた時間のほとんどであると仮定すると、あなたはすぐに新しい仕事を探しているかもしれないという事実に直面しなければなりません。
これに早く対処すればするほどよいでしょう。
第二に、ANSI Cが不十分であることを彼に納得させることができないと思います。あなたがする必要があるのは、他にもいくつかのことを彼に納得させることです（1）c＃が適切である、（2）彼は簡単にc＃を維持することを学ぶことができる、（3 ）そのあなたは、Cで書くには不十分でした。このプロジェクトでまだ仕事と役割を果たす部分があると想定して、2に集中し、cとc＃の類似点を強調します。
コメントに応じた引用...
数か月前に、私たちはアプリの開発を始めました[...]数日後、私はすべてを廃棄し、C＃を使い始めました
私たちはこのアプリケーションをANSI Cで開発することを義務付けています。理論的根拠は、彼が常に存在する唯一の人物であり、したがって彼は私たちが何をしているかを理解できなければならないということです。
これはかなり合理的な要件です。
彼はまた、抽象データ型を使用してはならないと決定しました。
これは意味がありません。これはプログラムの設計要件であり、言語要件ではないため、少し疑わしい匂いがし始めています。コードの保守が容易な場合は、ADTを実装するか、十分にテストされた既存のコードを使用することが優先されます。
彼は私たちに使用してもらいたいグローバル変数（ため息）の名前のリストもくれました。
さて、今では悪臭を放ちます。上司は、さまざまなプログラミング言語だけでなく、プログラミング全般の経験が限られていることがわかります。熟練したベテランプログラマは、言語の好みに関係なく、そのような発言をすることは決してありません。 （私が考えることができる唯一の例外は、ほとんどのコードがかなり小さな組み込みシステムで実行することを意図している場合であり、そのため、コードに必要なall必要な作業メモリは事前に割り当てられると予想されていました。ただし、同じコードに画面レベルのUIが必要であるという考えは、そうではないことを強く主張しています。
あなたの上司は大規模でミッションクリティカルなソフトウェアプロジェクトに関与したことはないでしょうが、彼はさまざまな低品質のプロジェクトに浮かんでいる可能性が高いです。
したがって、これはプログラミング言語Cとは何の関係もありません。C＃でも同じように厄介なプログラムを簡単に作成できます。優れたプログラム設計は言語に依存すると信じるのは、よくある間違いです。それは単に本当ではありません！
C＃は確かにCよりも洗練されていて、簡潔で、あいまいではありません。Cよりもオブジェクト指向に関連するキーワードがはるかに多いため、プログラム設計を十分にサポートします。しかし、それ以外は教えてくれませんhow =プログラムを作成します。 Cで記述されたすべてがデフォルトでひどいものであり、C＃で記述されたすべてがデフォルトで天国であると信じている場合、私はあなたが現在気付かずにかなりひどいC＃プログラムを書いているに違いない。
私が提案するのは、何よりもまず、言語に依存しない抽象的なプログラム設計を作成することです。通常のオブジェクト指向のアプローチを使用します。どのようなオブジェクトが存在し、どのように相互に通信するか、必要な依存関係は何かなど。プログラムの設計を十分に検討し、それを紙に書き留めたら、上司も上司もそれほど重要ではありません。実装するために選択した言語。
あなたが対処しなければならない最初の問題は、感情的で非合理的な問題です。 IT業界は絶え間ない変化の1つであり、すべてのための場所はありますが、変化の改善または採用を拒否することは問題です。
上司がANSI Cにしがみついているのはなぜですか？それが彼または彼女が知っている唯一の言語である場合、多分それは変化の時ですが、合理的な議論は不十分かもしれません。見慣れない言語での作業を余儀なくされた場合、上司は過小評価されたり、解雇されたりすることがありますか？彼の経験と彼がもたらすその他の利点を強調します。
この問題を解決しないと、持ち込むことができるすべての合理的な議論が無駄になります。部下として、あなたは彼とこの議論を持つことができる人ではないかもしれません。おそらく、もしあれば、他のマネージャーの1人にこの件についてブローチします。
また、あなたの視点からそれを考慮してください。なぜC＃を使いたいのですか？これのうちどれが新しくてかっこいいものを使いたいという欲求ですか？あなた自身に正直であれ。これを認識すれば、より効果的に議論するのに役立ちます。
2番目の問題は、リスクとコストの1つです。ソフトウェアの作成は高価であり、言語の選択がその主な要因です。検討してください：
- C＃とCで書くのにどれくらい時間がかかりますか？オブジェクト指向が簡単になり、ガベージコレクションが改善されるため、C＃の方が簡単な場合があります。ただし、アプリケーションがアンマネージAPI呼び出しを多数使用する場合は、Cの方が簡単な場合があります。
- C＃を使用している場合、追加のツールを購入する必要がありますか？ Visual Studioを既に使用しているようですが、ローカリゼーション、コードのレビューと分析、デバッグなどのために追加のツールが必要ですか？
- メンテナンスは簡単ですか？バグを見つけた場合、どれだけ早く修正できますか？ C＃では、このオブジェクトの向きを減らすことができます。自動ガベージコレクションは、ほとんどのメモリリークとポインタの問題も回避します。
- サポートはどれくらい簡単ですか？サポートスタッフがいる場合、彼らはクラッシュダンプの読み方を知っているかもしれませんが、SOSでwindbgを使用する方法を知っていますか？ターゲットマシンには、適切なバージョンの.Netフレームワークがすでにインストールされていますか？
- 人材配置を検討してください。 CとC＃を知っている人はどれくらいいますか？あなたのどちらかまたは両方が退職した場合、あなたを置き換えることはどれほど簡単ですか？ C開発者はC＃開発者よりも安いですか、それとも高価ですか？
私は続けることができますが、要点は、言語の技術的なメリットだけで議論するのをやめることです。技術的なメリットは、あなたとあなたの上司だけが理解できることです。ビジネスへの影響について話し始めると、はるかに広い範囲の人々を引き込み、はるかに説得力のある議論をします。
たぶんCの方が良い選択です。 C＃は、すべての状況で自動的に優れているわけではありません。たぶん、あなたはCを使用してこのプロジェクトを行いますが、次のプロジェクトのためにC＃の概念実証を行います。あなたは戦いに負けても、戦争に勝つことができることを覚えておいてください。
ANSI Cが不十分であると私たちを説得することに完全に失敗しました。 Cは優れた言語であり、あなたが説明した種類のタスクに適応しているようです。タスクの短い説明（言語要件を除く）があれば、Cを推奨します（または、多分行ってください）。
問題は、あなたがC＃で考えることを念頭に置いてCでプログラミングしていたことだと思います。 PerlからCまたはJavaに切り替えると、同様の問題が発生します。あなたはその言語に順応することを学ぶべきであり、あなたの考え方からその日の言語に翻訳することを学ぶべきではありません。
問題は上司やC言語ではなく、さまざまな考え方に心を開くことです。プログラミング言語を変えることはあなたに利益をもたらすものです。
多分別の議論：間違いをせずにCコードを書くのに十分な経験を持つコンピュータサイエンスの学生を見つけるのはおそらく非常に難しいでしょう。 ANSI Cは、人々が今日最初に学ぶことではありません。
今、すべてのコンピュータサイエンスの学生が私を殺します。
まず、上司に別の言語であることを伝える必要があります。通知なしに要件に対して意図的に何かを持ち帰った場合、彼は（当然のことながら）怒ります。
今、上司やマネージャーにこれらのことを説明する最良の方法は、時間とお金の観点から説明することです。 ANSI Cでこのようなプロジェクトにかかる時間を見積もり、C＃などのより高いレベルでかかる時間を見積もります。現代ではなく、より高いレベルを言ったことに注意してください。これは、物事をスムーズにするのにも役立ちます。つまり、小さなペイントブラシだけで部屋を描くことに取り組むのではなく、ローラーなどを使用して、各ストローク（コードの行）がプロジェクトのより多くの領域をカバーするようにします。また、あなたやあなたのチームメンバーの1人がCを知らない場合、またはCで大規模なプロジェクトを作成することに抵抗がない場合は、スピードに慣れる必要があるため、これは時間の問題にさらに影響します。
また、上司が細かく管理しようとしているようです。他の答えの1つは、上司にそれを少なくする方法を説明しようとするでしょう。
ADTへの監督者の嫌悪感は、開発者がGCコストを認識していないように、他の場所で対処されたので、「スレッド」に焦点を当てます。
おそらく、.NET（または、もしそうなら、JVM）のスレッドについて考えるのではなく、いくつかのプロセス間通信（IPC）メカニズムを使用してプロセス間で通信する複数のプロセスが必要な場合があります。例：Windowsメッセージ、共有メモリ、メモリマップファイルバッファ、名前付きパイプなど。デバイスまたはデバイスの側面とのやり取りとIPC=更新の通信と要求の確認のために確認するための小さなプロセス専用であり、GUIを維持して機器の「モニター」と通信するためのやや大きなプロセスがあります。 "IPC選択したものを使用します。