多くの場合、「車輪を再発明しないでください」という推奨事項を満たす必要があります。 時には、 見かけ上 、良いアドバイスとして、無視や自己肯定をはっきりと示します。 しかし、たとえそれが善良なアドバイスであると呼ばれたとしても、多くの文脈において、それは話者の無能さを示すだけです。
フレーズの入れ子になった目的は、無駄な作業、タスクに既成のソリューションを使用するための呼び出しからあなたを救うことであり、外部の観察者の観点から、それは本当に合理的に見えます。
しかし、同時に、ソフトウェア開発だけでなく、問題を解決するための特徴である重要な要素も見逃さ れています。タスクが設定されているコンテキストを変更すると、ソリューションも変更されます 。
この原則を見失うことは、適用された問題を解決できないことを認めることと同じです。
いくつかのケースを考慮してください。
API over API
サイクリングの非難の一般的なケースの1つは、一部のサービスの自己記述APIラッパーです。その実装は既に利用可能です。
私の練習からのケース。
Facebookからサービスへのデータのアップロードを実装する必要がありました。 メインストリーム言語とFacebook自体のライブラリは2分でグーグルになりました。
ライブラリのドキュメントは現在のプログラムインターフェイスに対応していなかったため 、多くの不要なアクションが各操作に巻き込まれていました。 その図書館は質が非常に悪いことが判明した 。
結果：1.5時間操作した後、ログインすらできませんでした。
同僚がweb-api facebookの独自のラッパーを実装しました。 合計すると、サービス側でラッパーと関連機能を作成するのに約1時間かかりました。 「なぜここでサイクリングをしているのか」という質問に対して、彼は数日後に答えました。
これは、大規模なコミュニティを持つ主流言語で特に顕著です。「人間向け」および「簡単な方法」というスローガンの下で、APIラッパーを別のAPIに公開するという不健康な傾向があります。 このようなラッパーは、ラップされたインターフェイスが更新されるとすぐに廃止され、作成者はそのような「プロジェクト」を放棄し、それらを使用するコードを動作不能にします。
良い質問 ： そして、そのようなラッパーを手動で書くたびに何ですか？
回答： 大きいラッパーの場合、仕様を解釈するコードジェネレーターを使用するのがはるかに強力なソリューションです。
コードベースを制御し、他人の間違いに対する回答を拒否する
コンピュータゲームの開発における意欲的なサークルでは、このフレーズはあえてエンジンを実装する人を対象としています。 「なぜ車輪を再発明するのか？団結してください！」 。 または、ゲームメーカー、または、神は禁じられています。
dviglo \コンストラクターは、開発に必要なすべてのツールを提供しているように見えますが、それらの多くはクロスプラットフォームであり、一般的に生活を簡素化します。
独自のエンジンを作成する必要があるように、ここでコンテキストをどのように変更する必要がありますか？
少なくとも、これはコードベースとエンジン機能の制御です （たとえば、多くのコントローラーモデルでは、ゲームメーカーは常にバグが多いため、これを修正することは非常に問題になります）。 つまり、それ自体では修正が不可能または非常に難しい「外来バグ」に遭遇する可能性を減らす必要があります。
これは、グラフィックおよび/または物理的なベルやホイッスルで飽和していないゲームで特に顕著です-角質、条件付きエンジンがそれほどかかりません。
さらに、 その機能のごく一部がエンジン/コンストラクターから使用される場合、コードベースの総量を増やす必要はなく 、必要なツールを独立して追加する必要があり 、同時にエンジンでの作業の正確さを制御します。
たとえば、そのような前提に基づいて、 Tommy RefenesはSuper Meat Boy用に独自のエンジンを作成しました 。
誰かが反対します： 「しかし、倉庫\その他のストレージには、大量のプリセット\ツール\拡張機能があります！」 。
はい、それは素晴らしいことであり、2、3ポイント先を行きますが、大規模なアクティブユーザーベースのエンジンでは、前のセクションで説明したのと同じ「死ぬ」効果がかなり観察されます。 コンテキストと特定のタスクがなければ、 ストア内の豊富なユーザー拡張機能が手に入る と明確に主張することはできません 。
架空のアイデンティティ。 耳でタスクを引っ張る。
問題を定式化したときに、頭に浮かぶ既存のソリューションが適切でないことが判明することがあります。 その「脂肪含有量」またはタスクの主要な条件の1つに対する不満のために（ はい、いくつかあります ）。
良い例：CluNet。
彼の記事のクラスターは、スマートホームプロトコルを開発するときに彼が下した決定の理由を非常に詳しく説明しています。 この例は非常に明快で説明が充実しているため、自分で分解することをお勧めします。
おわりに
問題の解決策を探すとき、文脈とすべての与えられた条件を考えなければなりません 。
単純な場合でも、コンテキストの小さな詳細がソリューションを上下逆さまにし、 適用された問題を解決するスキルは、主に初期前提を確認および評価する能力に基づいています。
「車輪を再発明しない」というフレーズは、アドバイザーが問題を解決できないことを意味しますか？ 数分後、顧問がためらう前にバイクについて言及した場合、おそらくそうです。
または、船長の一般化では：
決定する前に、考えてください。
話す前に考えてください。
そして一般的に-と思います。