プログラマーとして、複数の言語に精通している必要があります

プロジェクトに着手するときに私たちプログラマーが行う必要がある重要な決定の 1 つは、システムの実装に使用する言語、または言語のセットを選択することです。この決定は、システムの実装だけでなく設計にも影響します。たとえば、オブジェクト指向言語を使用するべきですか? それとも手続き型言語を使用するべきですか? どの言語を選択するかは、プロジェクトとその一部であるプログラムのライフサイクルに大きな影響を与えます。言語を選択する: このタイプのシステムを実装するために通常使用する言語、私が最もよく理解している言語、この言語でのプログラミングを楽しんでいるなど。

この決定は重大かつ長期的な結果につながるため、この選択を行う際には、より現実的であるべきでしょうか? 多くの場合、私たちは選択した言語によって盲目的に偏見を抱くことになります。そして、場合によっては、その言語を選択したくない理由が、まさにその言語を選択する理由である可能性があります。

自分の偏見をオープンにして正直になれば、装飾するときに丸い穴に四角い釘をはめ込む苦労をいくらか和らげることができます。プロジェクトに最適な言語を選択するための秘訣はありませんが、より適切で適切な言語を選択するのに役立つ原則がいくつかあります。

完璧な言語などありません

これは初心者であっても誰にでも予想されることであり、私たちの多くは「もちろん、この言語は完璧な言語ではない」と認めますが、同時に、多くの人は私たちの中には今でも「この言語は最高のプログラミング言語だ」と言っている人がいます。ある言語がプロジェクトに最適な言語であると判断する鍵となるのは、プロジェクトのコンテキストです。つまり、最適な言語は特定の範囲内でのみ存在します。これが私たちの第一原則です:

完璧な言語はありません。どの言語にも長所と短所があります。

たとえば、通常 Java や Python などのランタイム言語を使用する多くの開発者は、メモリ管理などの低レベルの詳細に焦点を当てたり、コンパイル時の型を気にしたりするため、C や C++ は息が詰まると主張しています検査の粒度が厳しいその一方で、開発者には分散された責任が課せられます。これは、私たちが開発しているプロジェクトが、メモリ管理や単一ループで発生するコピー割り当ての数など、一見些細なタスクに焦点を当てていない限り当てはまります。

逆に、私たちがプロジェクトやプロジェクトの一部に取り組んでいる場合、コードがどれほど効率的であるべきか、プログラムがどれほど重要で安全であるべきかについて偏ったニーズがあるのは自然であり、これらの一見退屈な詳細はまさにそのレベルである可能性があります私たちが求めている粒度。この新しい状況では、Java や Python のランタイムの性質は、あまりにも無関心、またはあまりにもぼんやりしているように見えます。代わりに、メモリの割り当てと解放時に実行される移動代入とコピー代入の数を厳密に制御し、ランタイムにエラーを漏らすのではなく、コンパイル時にできるだけ多くのエラーをキャッチできるようにしたいと考えています (次のように動作します)。ランタイム異常）。

理論的には「完璧な言語はない」というのは明白に聞こえますが、開発者としての私たちの行動はしばしばこの概念から逸脱します。私たちは自分のお気に入りの言語が不完全であることを知っていると言いながら、開発するプロジェクトでは依然としてこの言語を使用し続けます。それが適切かどうかは関係なく。さらに、別の開発者が私たちの言語選択に疑問を抱いたとき、私たちはその反論の中に真実を見出すのではなく、私たちの選択を積極的に擁護します。どの言語にも長所と短所があることに注意してください。習得する言語の長所と短所を理解し、状況に応じて選択してください。

ある言語が嫌いな理由は、その言語を使用すべき理由である可能性があります

直観に反するように思えるかもしれませんが、場合によっては、ある言語が嫌いな理由がその言語を使用する理由である可能性があります。上記の例でも、C++ 開発者としての私の経験では、追跡すべきさまざまな概念 (メモリ管理やオブジェクトの有効期間、C++ プログラミングの 3 原則など) が非常に多いため、プロジェクトを完了するまでに時間がかかりすぎることがよくあります。 .) 単純な関数は煩雑になる可能性があります。 C++ で数週間開発した後、Python、Java、またはその他の「高級」言語を使用するのは才能のように思えますが、本当にそうですか?

場合によっては、言語が嫌いになることがあります。言語には理由があります。なぜそれを使うのか。私がドライバーや安全性が重要なリアルタイム システムを開発している場合、上で述べた面倒な理由がこの言語の最大の利点になるかもしれません。たとえば、C++ は、オブジェクトがコピーされるときに実行されるロジックを表現するためのメカニズムを提供します。これは、効率と厳密性を重視する場合に非常に役立ちます。

これはすべて良くて素晴らしく見えるかもしれないので、嫌いな言語がより役立つ可能性がある文脈を正確に特定するのは困難です。では、どの言語が嫌いなのかをどうやって知ることができるのでしょうか? これは私たちの 2 番目の原則につながります:

自分に正直になる: 言語が嫌いな理由を知り、自分を嫌いだと独断的に考えないでください。

たとえば、上記の C++ の例では、私が長い間 C++ でプログラムするのが好きではない理由は、この言語が厳密な思考を必要とするためです。そうしないと、ジャングルに閉じ込められたのと同じように間違いを犯しやすくなります (合格しました（森全体よりも木に重点を置きます）。この厳格さにより、開発者は「オブジェクトをスタック上に作成しているのか、それともヒープ上に作成しているのか、あるいは部分的にスタック上に作成し、部分的にヒープ上に作成しているのか?」「このクラスを拡張可能にするには、テンプレートを使用する必要がある」などの疑問を抱くことがなくなります。それとも相続？」などの決定を下します。他の言語では、開発者はそれぞれオブジェクトを作成し、オブジェクト指向の継承を使用するだけでこれらのタスクを実行でき、言語 (より正確にはコンパイラーまたはインタープリター) がこれらのタスクを処理するため、次の機能に進むことができます。詳細。

しかし、自分に正直に言うと、C++ のこれらの機能が好きではない理由は、これらの詳細を表現する責任が私に課せられるからであると認めます。他の言語では、これらの詳細について私に責任がないだけでなく、それらを表現する責任もありません。それらは開発者から抽象化されています。これらの詳細が不可欠な状況では、私が C++ を好まない理由は、まさにこの言語を使用する必要がある理由です。

これは、言語について眉をひそめたり、腹を立てたりする機能を使用する必要があるという意味ですか? その必要はありません。別の見方もできるかもしれません。これらの機能を欠点とみなすのではなく、仕事を遂行するための必需品として受け入れる必要があるのか​​もしれません。 「何という悲劇だろう」と言う代わりに、「この言語でこれができるのは神に感謝です」と言うべきです。状況によっては、これらの能力は賜物であり、別の場合には義務であることを覚えておいてください。言語の機能が気に入らない理由について自分に正直になってください。

他の言語に精通しているほど良いです

そのために、ここでお話したい 3 番目の原則があります:

もしあなたが持っている道具がハンマーだけなら、すべての問題は釘のように見えます。

このルールはソフトウェア エンジニアリングには適用されませんが、多くのソフトウェア開発状況を明確に特徴付けています。多くの場合、私たちは言語、または言語をサポートするツール (Java の JMS、Python の ASYNCIO、Rails の Ruby など) が存在することを知っているので、そのツールを選択します。私たちが精通している唯一の言語が Java である場合、遭遇するすべての問題を Java のコンテキストに適応させることになります。たとえば、「通信アプリケーション用のルーティング フレームワークを作成する必要があります。Java でこれを行うにはどうすればよいですか?」これにより、使用できるツールが制限され、ジョブに適切なツールを選択する能力が人為的に制限されます。

この問題を解決する方法は、視野を広げて、他の言語の機能と複雑さを理解することです。 Andrew Hunt と David Thomas が「The Pragmatic Programmer」で示唆しているように、毎年新しい言語を学ぶのが良い方法です。それは思っているほど簡単ではありません。言語を学ぶことの意味は人によって異なります。もう 1 つの派生的な問題は、進行中のプロジェクトではこの 1 つの言語しか使用しないことが多く、別の言語を学習するのが無駄になってしまうことです。たとえば、私が Android 開発者で、基本的に毎日 Java しか使用しない場合、C# を学ぶのは時機を逸した時間の無駄のように思えるかもしれません。

幻想に騙されないでください。別の言語を学ぶ利点は、問題を別の視点から見ることができ、問題に最適なツールを使用できることです。これを行うには、他の言語に関連する注意点と、開発者が問題を解決するためにそれらの言語を使用する方法を学ぶ必要があります。たとえば、開発者が C++ でメタプログラミングを実行したい場合、C++ でテンプレート メタプログラミング (TMP) を使用できますが、Java でリフレクションを使用することもできます。他の言語が同様の問題をどのように解決するかを理解することで、それが役に立たないと判断するリスクが軽減されます。

別の例として、クラスの実行時の特性を変更できるようにする必要がある場合、C++ の複雑さに精通している C++ 開発者は、このコンパイル時言語の境界を拡張するソリューションをでっち上げたくなるかもしれません。 。また、Java の知識もある別の C++ 開発者は、「私は C++ が好きですが、この問題を解決するには Java のランタイム リフレクションの方が適しています

プログラミングはたくさんあるので、開発者は言語を選択できます。」と言うことができます。 , そのため、どの言語を学ぶか優先順位を付けることが重要です。今日最も人気のある言語から始めるのもよいでしょう (「Github で最も人気のある言語」、「Github の言語トレンド」、「最も人気のある 9 つのコンピューター言語」、「プログラマー向け Facebook によると」を参照してください) 」など）。

言語は手段であり、目的ではありません

これは 4 番目で最後の原則であり、最も哲学的に聞こえるかもしれませんが、最も重要であるとも言えます:

プログラミング言語は手段であり、目的ではありません。

あなたが言語標準の作成者またはコンパイラの作成者でない限り、プログラミング言語を目的ではなく手段として扱うべきです。目的はプロジェクトを完了することであり、最終的な目標はプロジェクトを完了することです。特定の言語を使用します。これは、すべての開発者がその言語について好き嫌いを要求する権利がないという意味ではありません (実際、自分自身に正直であれば、これらの好き嫌いは有利に働く可能性があります。上記の 2 番目の原則) ですが、言語の機能がプロジェクトのニーズに本当に適合しない限り、「これは言語のこの機能を使用する素晴らしい機会です」などの決定を下す必要はありません。

言語は、目前の問題を解決する方法を表現する単なる手段であることを覚えておくことが重要です。解決している問題領域を最もよく表現する言語を選択するようにしてください。

その他の考慮事項

言語を選択する際に考慮する必要がある追加の事項がいくつかあります:

その言語が他の言語とどのように相互作用するかを考慮します。たとえば、Python がほとんどのプロジェクトに最適な言語であると判断したものの、プロジェクト内に非常に高いレベルの粒度または効率を必要とする明確に定義されたコンポーネントがある場合 (C または C++ の方が適しています)、このプロジェクトでは Python を使用できないという意味ではありません。代わりに、Python を使用し、C または C++ で特定のコンポーネントを記述してから、Python C API を使用してこのコンポーネントに接続することを検討してください。このようなソリューションを定式化するには、Python に C API があることを知る必要があることに注意してください。したがって、最も一般的な言語の機能を知っておくと役立ちます。

ミドルウェアは複数の言語の使用を許可できます。たとえば、モバイル デバイスとサーバー アプリケーションなど、通信する必要がある 2 つのアプリケーションがある場合、これはそれらが同じ言語を使用する必要があるという意味ではありません (もちろん、それが最善の決定であると判断した場合は、同じ言語を使用することもできます)。 。モバイル デバイスが Android フォンで、サーバー アプリケーションが Python アプリケーションとして最適な場合、RabbitMQ などのメッセージ ブローカーを使用すると、両方の言語を同時に使用して通信できます。Android アプリケーションは Java RabbitMQ を使用できます。 API を使用できますが、サーバー アプリケーションでは Python RabbitMQ API を使用できます。

他の言語の特徴を受け入れましょう。 Java 開発者であれば、パッケージを使用してソース コードの論理単位を分離します。Python 開発者であれば、Python のパッケージ構造を使用して同じことを行います。名前空間を使用するか、クラス名にプレフィックスを付けます (つまり、「DZone_MyClassName」)。自分が話している言語の特徴を理解し、それを受け入れてください。ローマでは、ローマ人と同じように行動してください。そうしないと、イタリア語の発音を好むためにイタリア語のアクセントでドイツ語を話すようなものになり、特徴のないものに聞こえてしまいます。もちろん、言語の機能が古くから存在している可能性もありますが、この場合は必ず理由があるはずです。その理由を必ず理解してください。