技術的な質問は、手紙やメッセージでよく聞かれます。喜んでお答えします。 しかし、この場合、1人の人が答えを得るので、多くの人に役立つかもしれません。
そのため、1つの問題について、文字通り5分で毎週解析することにしました。
今日、開発についての質問はセルゲイからです、私たちの教師イゴール・アレクセーエンコは答えます：
Mankipatching-なぜそんなに悪いのか、それほど悪くないのか？
ホリバーを開始せずにこの質問に答えることは困難です。 Mankipatchingは機能するため、悪いとは言えませんが、足で撃つのは非常に簡単であることを覚えておくことが重要です。
マンキパッチとは、実行時、つまりプログラムの実行中にコードを変更することです。 たとえば、存在しないメソッドを配列に追加したり、グローバル関数を再定義したりします。
Array.prototype.shuffle = function() { const i = this.length; while (i--) { fisherYatesShuffle(this, i); } }; [1, 2, 3].shuffle();
Mankipatchingは、リバースエンジニアリングが必要な1回限りのタスクに最適です。 たとえば、問題の解決策をデバッグしたり、一部の分析を一度だけ収集したりする必要がある場合は、これで十分ですが、これらは明らかに一度限りのアプローチです。
産業用コードについて話し、セモリナパッチを誤って処理すると、プログラム全体で使用される組み込みオブジェクトの作業を中断できます。 何らかの理由で、setTimeout関数の動作を変更したと想像してください。 外見的には同じように機能しますが、さらにこの関数は他のいくつかのタスクを解決します。たとえば、コンテキストを保持します。
const initNewTimeout = function() { const initialTimeout = window.setTimeout; window.setTimeout = function(fn, timeout, ctx) { initialTimeout(function() { fn.call(ctx); }, timeout); } }; initNewTimeout(); setTimeout(tickInContext, 100, this);
もちろん、コードではsetTimeoutは必要に応じて機能しますが、setTimeoutが使用される他の場所ですべてが同じようにスムーズに機能することを保証することはできません。 より極端な例もあります。たとえば、JavaScriptの初期の段階では、未定義のウィンドウでもオーバーライドできました。
マンキッピングでは、細心の注意を払って特定のルールに従う必要があることがわかりました。
古いものを変更するよりも新しいものを追加する方が良い
すでに言語に組み込まれているメソッドの動作を変更するのは、コード内以外で使用できるため、悪いです。 しかし、他の誰かがほとんど使用するとは思わない新しい何かを追加することは比較的安全です。 たとえば、それらを配列に混在させる方法を追加します。 ただし、しばらくすると、そのようなメソッドが配列に表示される可能性があります。標準が開発されており、ブラウザはすぐにそれらを選択します。
パッチを徹底的にテストする必要があります。
これは開発者向けの一般的なアドバイスですが、ピックアップに関しては、二重の注意が必要です。なぜなら、ある場所では助けができ、別の場所では傷つけられるだけだからです。 mankatchを作成するときは、パッチ自体をテストするだけでなく、アプリケーション全体のレベルで何かが壊れているかどうかを確認することも必要です。
一時的な解決策としてパッチを使用することをお勧めします。
マンキパッチは有害である可能性があるため、できるだけ早く廃棄する必要があります。
これらのルールに従って、ポリフィールが作成されます-古いブラウザの新しい機能のサポートを追加するパッチ。 名前がアプローチに対する態度をどれほど変えるかについて同意します。 猿の修正がありましたが、普遍的なフィラーになりました。 組み込みオブジェクトに理解できない変更がありましたが、新しい標準のサポートに関する問題の修正になりました。
Polyphilesは良いアイデアのようです：あなたが持っているブラウザに関係なく、Polyphileを接続します。たとえば、HTTP要求のFetch、Promise、またはオブジェクトの反復処理のObject.entriesなど、コードに新しいものを使用できます。
<script src="./promise-polyfill.js"></script> <script src="./whatwg-fetch.js"></script> <script> fetch('/api/request') .then(resp => resp.json()) .then(json => render); </script>
しかし、このアプローチには問題があります。
パッチを適用したものをすでにサポートしているブラウザで何かをする必要があります。
この機能が既にサポートされているブラウザのパッチを無効にすることが理想的です。 通常、ポリフィルの開発者はそれを自分自身に引き受けますが、この点を確認する必要があります。
標準への準拠。
少なくとも1つのブラウザで動作する既に採用されている標準について話している場合、残りのサポートは時間の問題です。問題はありません。 しかし、まだ議論されている標準について話す場合、プログラマーはそれを使い始めて慣れることができ、標準開発者は標準を事実上修正するため、標準を改善することはできないため、親友を作成しない方が良いです。
そのような状況では、時々 ponyphilsと呼ばれるラッパー関数を使用することをお勧めします。 原則として、それらは、親友と同じことを可能にしますが、明示的に行います。 また、標準に関する問題もありません。たとえば、人気のあるLodashライブラリは、配列内の破損したイテレーターのラッパーから生まれただけです。 連中は、各ライブラリ、マップ、その他のライブラリをすべて追加しましたが、標準に準拠していなかったため、最初は手を離しました。 しばらくして、シャッフル、ユニーク、フラット化など、配列とコレクションに便利な他のメソッドを追加しました。 配列内のイテレーターは長い間サポートされてきましたが、Lodashは正常に開発されています。
また、性機能はテストが簡単です。 ポリフィルを完全にテストすることは非常に困難です。 テストを実行する場所と同じ場所に接続すると、パッチによってフレームワーク自体のコードが変更され、テストに影響する場合があります。 そして、多相性生物のロジックを個別にテストすると、それらが正しく接続されているかどうかは明らかではありません。
環境によっては、テストの動作が異なります。一部の環境ではパッチが機能し、他の環境では機能しないためです。 Ponifilsにはそのような問題はありません。テスト対象を常に把握しており、明示的に接続して動作します。
まとめると
マンキッピングは悪いですか？ それが機能するという事実から判断すると、それほど悪くはありませんが、それを使用するときは、他の人のコードを破る方が簡単であり、テストするのが難しく、使用されていることを忘れることができます。
関連資料
ビデオ版
ここで質問することができます 。