私たちの各プログラムには共通点があります。
これは時間と心の無駄です。
共通部分が単純な場合は問題ありませんが、常にそうであるとは限りません。
誰かがこの種の質問を考えたことがありますか?
目標は次のとおりです。
コーディングを行うときは、新しい、たとえば、以前に行われたどの部分とも類似していない部分のみを行います。
良い解決策があれば、それは多くのプログラマーにとって大きな安心になるでしょう!
私たちの各プログラムには共通点があります。
これは時間と心の無駄です。
共通部分が単純な場合は問題ありませんが、常にそうであるとは限りません。
誰かがこの種の質問を考えたことがありますか?
目標は次のとおりです。
コーディングを行うときは、新しい、たとえば、以前に行われたどの部分とも類似していない部分のみを行います。
良い解決策があれば、それは多くのプログラマーにとって大きな安心になるでしょう!
これは、ライブラリ、プログラミング言語、またはデザインパターンのポイントです。解決された問題を抽象化して、再度解決する必要がないようにすることです。
もちろん、解決すべき新しい、より複雑な問題は常にあります。そして人々はそれらを解決する正しい方法について意見が分かれています。ですから、やるべきことはまだたくさんあります。
はい、私は毎日それについて考え、考えています-解決策は単純ではありませんが、達成可能です:常にコードに共通するものを再利用可能なアーティファクトに分解するようにしてください。それが解決策ですが、それは偶然ではなく、日々の努力です。
gotosから関数、クラス、モジュールまたはコンポーネント、ライブラリに至るまで、ソリューションはたくさんあります。これらすべてにより、コードを再利用できます。
最も単純なhelloworldアプリでさえ、それを多用しています。すべての出力機能を自分で作成する必要はありません。言語の標準ライブラリと、画面にテキストを印刷するためのOSルーチンを利用できます。
たとえば、Cのような原始的な言語でもprintf
、画面にテキストを印刷する機能を備えているため、自分でテキストを書く必要はありません。
もちろん、コードの再利用は理想的ですが、邪魔になる実際的な障害がたくさんあります。たとえば(ここでは主にライブラリの再利用について考えます):
既存の機能について知らない場合や、ニーズを満たしているかどうかがわからない場合があります。再利用可能な機能を見つけるために必要な時間は、それを自分で実装するために必要な時間よりも長い場合があります。
既存のコードは、必要なものとわずかに異なる場合があります。コードの再利用に取り掛かるまで、違いが明らかにならない場合があります。
既存のコードには、アプリケーションで使用した場合にのみ明らかになるバグが含まれている可能性があります(#2の特殊なケース)。他の人のコードをデバッグすることは、特に変更可能なソースが利用できない場合は、多くの場合、実際の課題です。
既存のコードには、プロジェクト全体に不適切なライセンス制限が含まれている場合があります。
既存のコードには、実行可能ファイルを肥大化させたり、脆弱にしたり、一部の環境にデプロイする機能を制限したりする、他のライブラリやコードへの多くの依存関係が伴う場合があります。
既存のコードは、アプリケーションとリンクしたい他のライブラリと競合する可能性があります。