Unixでのプログラミングの技術（だけでなく）。 パート3、「構成規則」
Eric RaymondによるUnixプログラミングの芸術に関する一連の記事を続けます。 先ほど、最初の2つのルール- モジュール性と明快さ -について言及しました。
今日は3番目のルールについてお話します-
構成規則：プログラムを作成して、他のプログラムと結合できるようにします。
残念ながら、WindowsとUnixの両方で、開発者が「自転車を発明」し、標準を作成して承認し、市場で際立っているという願望により、プログラムの実際の接続については語れないほど多くの異種インターフェースが作成されます。
サービス指向 アーキテクチャ、SOAの概念を思い出すことは非常に適切です。 彼女によると、各プログラム、実際にはサービスには、理想的には既存のインターフェースとも互換性のある標準インターフェースがあります。 このアプローチにより、コンポーネントを再利用でき、サービスの自動外部テストを実施できます。 また、SOA実装では詳細が隠されていることが重要です。たとえば、より具体的なタスクプログラミング言語でサービスを開発できます。
このアプローチは、開発がより複雑で費用がかかりますが、柔軟性と拡張性がこれらの欠点の多くを相殺します。 文書化されたAPIを非常に早い段階で作成すると、アプリケーションの世界への扉が開かれます。その開発者は、あなたのプログラムではなく他のプログラムと統合できるため、最終的に誰もが勝ちます。
プロトコルとファイル形式が標準になればなるほど、エンドユーザーと同僚に利便性をもたらします。 プログラムが他のシステムとやり取りできるほど、ユーザーに開放される自由が増えます。
そのような状況では、その中に問題を引き起こす可能性のある「クリビン」があります。 たとえば、Gdrive-GMailメールサービスに 基づいてストレージが編成されている仮想インターネットディスク を呼び出すことができます 。 明らかに、このようなメールサービスの使用は彼にとって有害です。 またはもう1つ-GmailのIMAPインターフェイスは、以前はGoogleメールボックスにローカルメールを予約すると同時に、自動的にインデックスを作成するのに役立ちました。 これはOutlookを使用して行い、アカウントからアカウントにメールをコピーしてから、転送を設定しました。 これで、大量アップロードの「穴」が閉じられました。
すぐにパートナーを見つけることが非常に重要です。パートナーは、ほとんどゼロ段階でAPIを取得し、その設計と、場合によっては実装に参加します。 これは、ユーザーを「聞く」ための唯一の方法であり、ユーザーが必要なものを考え出すことではありません。
大きな間違いは、「if only」ベースでAPIを開発することです。 ドキュメント、アプリケーションの統一性、さまざまなオプションを組み合わせた単一のロジック、全体的なアーキテクチャなしでは、サービスの利点は非常に条件付きです。 悪い例としては、omgash CORBAとMicrosoft COMがあります。これらは、異種システムを接続するための開発がやや不十分なテクノロジーです。 CORBA仕様の開発には多数の第一層企業が関与していましたが、実際に起こったことは判明しました。 また、COMにはMS Windows環境の通信プログラム用のかなり狭いアプリケーションがありますが、最初からCOMをより汎用的に開発することを誰も気にしませんでした。
Unixの世界では、すでに説明したコンソールプログラムの相互作用のためのパイプテクノロジがあります。 あるプログラムの出力は別のプログラムの入力に向けられ、そのようなバンドルの「アーキテクト」の良心は、それらを互いに正しくドッキングすることです。 「ブリック」のそれぞれがどのように機能するかを理解していなくても、スペシャリストの手で有用なもの を組み立てること は、デザイナーのようなもの になります。 パイプ の概念は かなり原始的ですが、狭い主題領域の幅広いタスクに理想的です。 彼らがそれをすべてにシフトしようとすると、間違った「ツール」が選択されたために問題が発生します。 たとえば、Microsoftは、powershellでのパイプの実装で客観性を追加しました。 しかし、彼らが言うように、単純な決定は「ルール」です。 そして今、このPowershellはどこにありますか...
結論として、最初に戻りたいと思います。オープンなインターフェースを備えたプログラムを作成し、開発の最初から考えてください。 独自の形式で動作し、独自の種類と通信する方法を知らないプログラムを作成するのは、前世紀です。
今日は3番目のルールについてお話します-
構成規則：プログラムを作成して、他のプログラムと結合できるようにします。
残念ながら、WindowsとUnixの両方で、開発者が「自転車を発明」し、標準を作成して承認し、市場で際立っているという願望により、プログラムの実際の接続については語れないほど多くの異種インターフェースが作成されます。
このアプローチは、開発がより複雑で費用がかかりますが、柔軟性と拡張性がこれらの欠点の多くを相殺します。 文書化されたAPIを非常に早い段階で作成すると、アプリケーションの世界への扉が開かれます。その開発者は、あなたのプログラムではなく他のプログラムと統合できるため、最終的に誰もが勝ちます。
プロトコルとファイル形式が標準になればなるほど、エンドユーザーと同僚に利便性をもたらします。 プログラムが他のシステムとやり取りできるほど、ユーザーに開放される自由が増えます。
そのような状況では、その中に問題を引き起こす可能性のある「クリビン」があります。 たとえば、Gdrive-GMailメール
すぐにパートナーを見つけることが非常に重要です。パートナーは、ほとんどゼロ段階でAPIを取得し、その設計と、場合によっては実装に参加します。 これは、ユーザーを「聞く」ための唯一の方法であり、ユーザーが必要なものを考え出すことではありません。
大きな間違いは、「if only」ベースでAPIを開発することです。 ドキュメント、アプリケーションの統一性、さまざまなオプションを組み合わせた単一のロジック、全体的なアーキテクチャなしでは、サービスの利点は非常に条件付きです。 悪い例としては、omgash CORBAとMicrosoft COMがあります。これらは、異種システムを接続するための開発がやや不十分なテクノロジーです。 CORBA仕様の開発には多数の第一層企業が関与していましたが、実際に起こったことは判明しました。 また、COMにはMS Windows環境の通信プログラム用のかなり狭いアプリケーションがありますが、最初からCOMをより汎用的に開発することを誰も気にしませんでした。
Unixの世界では、すでに説明したコンソールプログラムの相互作用のためのパイプテクノロジがあります。 あるプログラムの出力は別のプログラムの入力に向けられ、そのようなバンドルの「アーキテクト」の良心は、それらを互いに正しくドッキングすることです。 「ブリック」のそれぞれがどのように機能するかを理解していなくても、スペシャリストの手で有用な
結論として、最初に戻りたいと思います。オープンなインターフェースを備えたプログラムを作成し、開発の最初から考えてください。 独自の形式で動作し、独自の種類と通信する方法を知らないプログラムを作成するのは、前世紀です。
| 「 以前：明快さのルール | 続き：分離のルール " |
All Articles