フレームワークをパフォーマンスヒットと見なしている同僚と通信する方法

一般的な応答が「jquery」などの包括的ステートメントである場合、「高度に最適化され、クロスブラウザーと互換性があるためjQueryを使用する必要がある」または「エンティティフレームワークはクールであり、モデルが自動的に処理されるのでクールです」などのアイデアをどのように販売できますか。十分に機能しない」または「エンティティが必要なのは、10で十分な場合、エンティティはテーブルに12列を取り込む」でしょうか。

私は、経験を通して開発した公理を信頼する傾向がある実用的な人です（目に見える減速があるまではパフォーマンスの問題ではありません）。他の極端が当てはまる特定の「カテゴリ」があるかどうかはわかりませんが、他に証明されない限り、またはここで通信を開始する場所まで、すべてがパフォーマンスの問題です。

彼らに難しい事実を持ってきてください！

たとえば、ORMおよびJSフレームワークのパフォーマンスベンチマークがあります。その上、すべてのフレームワークとORMは、ホームページで優れた販売の議論を持っています。

あなたのコメントを読んだ後、私はあなたの場合、問題は適切な技術ではないと信じています新しい技術を学ぶことを拒否するのは人々です。

私は前にこの問題に直面しました、人々は車輪を再発明したいのです。私は通常、その下にあるものではなく、重要なものを完成させることに時間を費やせば、製品をより良く、より洗練させることができると彼らに説明します。さらに...理由はフレームワークが存在することを意味し、最近のパフォーマンスはそれほど問題ではありません。信頼性はより重要であり、フレームワークが優れたレビュー/評価を持っている場合、おそらく誰かがその場で補うことができるものよりも信頼性が高いでしょう。

誰もがあなたの同僚に反対しているようですが、彼の見解を理解する以外に理由がないなら、彼の議論を真剣に受け止めるべきだと思います。私はフレームワークを必要とするとき、または実際に最適化を提供するときのフレームワークを固く信じていますが、フレームワークへの過度の依存は、場合によっては弱い開発につながる可能性があると考えています。

同僚が間違っているという観点からではなく、考えているフレームワークの使用によって開発時間、パフォーマンス、メンテナンスなどが改善されるという観点から、問題にアプローチする必要があると思います。

私は常に、適切な仕事に適切なツールを使用するよう心がけています。写真を吊るすために釘を打ち込む（イメージスワップ）ために12ポンドのそり（jQuery）は必要ありません。しかし、壁に留めるために鉄道のスパイクが必要な画像をぶら下げている状況に遭遇した場合は、そりを準備しておくことをお勧めします。

彼は正しい、オーバーヘッドがある

しかし、フレームワークのオーバーヘッドが手動でコーディングされたソリューション以上であるという仮定は正しくない場合があり、それが正しい場合でも、オーバーヘッドは重要ではない場合があります。

テストを提案する：

• どちらも現実的だが比較的小さいものを書く
• あなたはjQuery（または何でも）を使用し、彼は何も使用できません
• 次の2つを測定します。
  1. 両方でソリューションをコーディングするのにかかる時間（コーディングスキルが同等であると想定）
  2. 各ソリューションの実行（フルライフサイクル）にかかる時間

可能性は、フレームワークのオーバーヘッドが非常に小さい- 非常に小さい- ソリューションのコーディング[およびデバッグ！]にかかる時間に大きな違いがある

その後、あなたの友人はあなたとではなく、事実について議論することができます

注：継続的な抵抗に備えてください。多くの場合、フレームワークに対するプッシュバックは技術的な用語で説明されていますが、実際には「ここで発明されていない」または「別のツールを学びたくない」ということに対する煙幕です

車輪を再発明している同僚に、彼がしていることはさまざまな時期尚早な最適化であることを思い出してください。これらのフレームワークが問題を引き起こすことが実証されるまで、これらのフレームワークが許容できないパフォーマンスヒットであることをどのようにして知ることができますか。その間、あなたの相互生産性は確かに、あなたがしなければならなかった余分な作業のすべてによって落ちてしまいます。

これらの時間を節約し、テストされたフレームワークをいくつか使用しない場合に、プロジェクトの配信時間に影響を与えるパフォーマンスを説明してみませんか？

1つのオプションは、彼がパフォーマンスの調整を担当するようになることを彼に伝えることです-それが示される場合、パフォーマンスの問題があります！または、リソースがある場合は、2つの概念実証を構築します。jQueryを使用して構築し、その他はすべて必要です。彼は彼自身の手巻きの超高速システムで彼を構築することができます。これが数日以上続くことを許可しないでください（これは概念実証です）、最後にパフォーマンスが向上する人を確認してください。

そしてもちろん、他の人が述べたように、議論の両側のいくつかのハードな数値とパフォーマンスプロファイルを入手してください。

まず、彼はあなたの特定の状況に適しているかもしれません。

彼にあなたの視点を見てもらうのに問題があるように見えるので、彼を説得するより良い仕事をする必要があります。

2人は、「ビルド」と「購入」の間にある2つの異なるポイントにいます。これはかなり長い行です。左側の「Build」にはSpaceXがあり、業界全体を構築する必要がありました。右側の「Buy」では、すべてのIT機能をIBMやHPなどに完全にアウトソーシングしており、企業はコーディングをまったく行っていません。真ん中、2mmほど離れたところに2人います。あなたはどちらも、フレームワークやオームなどの「構築vs購入」へのアプローチ、つまり「購入」とは「自社で構築されていない」ことを経営陣に説得する必要があります。 -期間。もし彼らがIBMに外部委託していたら、Twitterは死んでいたでしょう。彼らは彼ら自身を巻きました。それについて考えてください。

いずれにせよ、経営陣はゴルフコースを降りてそこに入り、仕事をする必要があります。

ORMの場合、答えは「クエリをそのように記述した場合のみ、SQLでも同じです」です。他の人が言ったように、難しい事実はあなたが必要とするものです。

また、彼が言っていることを掘り下げるために具体的な質問をしてください-「それは私の経験ではないのでJQueryが実行されていない例を教えてくれますか」。

3番目のオプション、そして賢明な古い開発者が私にこれを提案しましたが、とにかく「もの」を含めてください（悪い問題がないと仮定します）。

承認を求めることは、「いいえ」という答えにつながるだけです。そこに入ると、特定の領域を指すように依頼して、何が問題なのかを伝えるように依頼できます。

「ねえ、このEFコードは、そのテーブルから必要な2つのデータ項目だけを返します。何が問題なのですか」など。

明らかに、このアプローチを進める前に、自分自身と使用しているツールにかなりの自信を持つ必要があります。:-)

手に負えないそのようなライブラリを拒否するのは愚かであり、時には傲慢です。これらの製品に費やされた製品時間とそれらの背後にある考えは、それらを拒否することを単純に不思議にさせます。

設計の一部であるソフトウェアの要求を比較し、それを上回る必要があるため、同僚が正しいかもしれません。ORMソリューションまたはActiveRecordソリューションは、やりすぎの大部分であるか、それどころか、ソフトウェアにDBの本当に結合されたソリューションが必要であり、ORMはそれをカットしません。

これらを考慮することは、ソフトウェアを設計するたびに重要です。

クライアント側のライブラリーについては、ニーズに適したフレームワークをいつでも見つけることができるので、それは単純な愚かさであると言わざるを得ません。そして、一部の人が私の前に言ったように、戦いでテストされたフレームワークより優れているものは何ですか？

彼にすべてのクロスブラウザ問題からがらくたを取らせてください、彼はフレームワークをどのように使うかに関して喜んであなたのところへ行きます。

ところで、私にはかつてフレームワークについて説明しなかった上司がいました。関数を何度もコピーするのではなく、ajaxリクエストを作成するのがいかに簡単かを最初に示しただけです（そもそもそれはばかげたアイデアでした）。