Flashの人を雇うよりも、Cの開発者にFlashを学ばせた方がいいですか？

昨年、私の部門はWebベースのゲームを開発し、Flashを必要としていました。管理が難しかったです。フラッシュの連中は、オフィスでのスキルや人気に関係なくうまくいかなかった。多分それはAS 2.0の日からの偏見であるか、またはCプログラマーは私の部門で別様に物事を行います。わかりません！

例
彼らは悪いフラッシュを雇ったフラッシュガイはツイナーとキーフレームを使用しました（彼らは彼を嫌っていました）。次に、AS 3.0のエキスパートであり、最高のOOP標準に準拠したGOOD Flash Guyを採用しました（彼は彼を気に入りました）。結果は同じで、Cプログラマーはコードのすべてを上書きし、GOOD Flash Guyのコードも上書きしました。

質問
Flash開発者を雇うよりも、C開発者にFlashを学ばせる方が良いですか？Flashの人には害はありません。プロジェクト管理レベルでこれを理解しようとしています。

おかげで、

それは大きな理由になるでしょう既存のC開発者がすべてのコードを書き直しました。一方では、アーキテクトがさまざまなソフトウェア層で構築する必要がある機能を決定する必要がある場合があります。たとえば、Cの開発者が再利用する必要のあるロジックをFlashに埋め込んでいる場合、それはおそらく貧弱なアーキテクチャであり、Cの開発者がさまざまなAPIを引き出すためにコードを書き直す必要があった理由を説明できます。一方、既存の開発者が過度に領土を広げ、新しい言語の学習に抵抗している可能性もあります。一方で、おそらくFlashは、ユーザーが持つ要件と活用する必要のあるフレームワークにとって、テクノロジーとしてはあまり適していませんでした。以前のプロジェクトがチームのメンバーや関係者と一緒に失敗した理由に対処しなければ、問題に対処することは非常に困難になります。

ActionScript 3に関しては、学ぶことはあまりありません。これは基本的に、JavaScriptと初期のJavaとの間の不十分な組み合わせです。

Flash Player自体については、知っておくべきかなりのAPIです。
Flash Playerのパフォーマンスクリティカルなコード（通常はゲームの場合）を記述する場合、多くのことを知る必要があります。すべての組み込みクラスを知る必要があります（独自のコードがVMで実行され、組み込みクラスがネイティブマシンコードのラッパーであるため、桁違いに高速です）。
あなたが自分の道を知っているなら、あなたがフラッシュ開発者コミュニティの一部であるなら、あなたのツールセットとあなたのリソースがあれば、それらの資産がなくても、どんなに巧妙なプログラマーであれ、簡単に他のプログラマーを打ち負かすでしょう。

したがって、特定のツール（プラットフォーム/テクノロジー）で最先端のことを本当に実行したい場合は、多くの経験が必要であり、時間がかかります。ただし、これはフラッシュに固有のものではなく、プログラミングに固有のものでもありません。あなたのCプログラマーがそれを理解していない場合、おそらく彼らは結局それほど良くないでしょう。

これはあなた自身のプロジェクト管理について語ります。開発者は、あなたがその理由を知り、その理由を知らない限り、他のコードを大幅に書き換えるべきではありません。あなたの開発者が専門外で振る舞っている場合、それはあなたがそれを許可しているからです。

Flashスペシャリストが必要かどうかは、Flashの作業がいかに複雑かによって異なります。

どうやらあなたの良いフラッシュas3開発者の定義には、開発者がすべてのプログラム/プロセス/ APIがプログラムと対話するもの、およびそれが展開される環境/条件に関して適切な要件収集を行うことは含まれていません。

他の人が指摘したように、これは本質的にプロセス管理とアーキテクチャの問題です。したがって、フラッシュガイにタスクを割り当てた人は、統合に関する情報を漏らすことなく、彼をブラックボックスに留めておかなければなりません。

しかし一般的には、純粋なc開発者にフラッシュを学習させて主要なプロジェクトに取り組むよりも、フラッシュの人を雇う方が良いです。Flash自体には、多くのニッチとゴチャがあります。

しかし、私はあなた自身の言い回しの非常に違いを指摘したいと思います。c 開発者 vsフラッシュガイ。開発者は、既存のシステムについてより広い視野を持ち、自分のタスクをフローに組み込む方法を理解している人であると想定します。

まあ、私がそれを認めたくないのと同じくらい、Cの人たちはOOPコードからできるだけ遠ざけられるべきです。例外はありますが、Cの考え方は大きく異なり、これがおそらく問題になります。

Cは、多くのメモリ管理を備えた低レベルの関数/構造体指向の言語です。そしてCの専門家はそのスタイルを引き継ぐ傾向があります。多くのC開発者は、高レベルの構造と例外に恐れを抱いており、それらには正当な理由があります。

OOP環境の場合、これはあまり良い考えではありません。Cで人気のないものはたくさんあります。例外、ポリモーフィズムなど。Cの人は、クラスを使用してCから移行するまでにかなりの時間が必要です。そして、SOLIDとすべてでクリーンなOOPコードを開始します。

C ++開発者にとっては別の話になるでしょう。そこで議論が開かれます、IMHO。

Cなんか嫌いじゃない。Cは、C ++が得意とするものと、その逆の点で非常に優れています。ただし、クリーンなCはクリーンなC ++コードとは大きく異なり、どちらのスタイルにも大きな欠点と大きな強みがあります。