Unixでのプログラミングの技術（だけでなく）。 パート1、「モジュール方式のルール」
過去10年間、私は市場でプログラマを探していましたが、主にWeb開発の分野で、大小さまざまな偉業を成し遂げてきました。 しかし、残念ながら、次第に価値の低い候補者が見つかります。 彼らは同じタスクに長年取り組んでおり、既存のソリューションとその欠点を複製しています。 あなたは何を達成したかを尋ねます-そして、日常的な、ありふれた事柄に応じて。 ウィンドウ自動化は、これらのプログラマーのほとんどが行うことです。 しかし、スペシャリストがほとんどいなかったため、本当に難しいタスクについては、今日に至っています。
Unixプログラマーは、これらの「ウィンドウオートメーション」から際立っています。 オープンソースソフトウェアの世界では、誰もがシステムソフトウェアと複雑なアプリケーションソリューションの開発に挑戦できます。 オープンソースソフトウェアの世界におけるそのような人々の業績は誰もがアクセス可能であり、私にとっては彼らは時々勧告を置き換える。 彼らの仕事が見えるからです。
私の意見では、自分の将来をソフトウェア開発につなぐことを決めた人にとっては一種の「聖書」である本がたくさんあります。 それらの1つで、一連の記事を始めたいと思います。 これはEric Reinmondの本、The Art of Unix Programmingです。 この本は、自分でオープンオペレーティングシステムを選択した人だけに推奨するものではありません。 それはかなり普遍的な哲学に基づいており、自分の職業をプログラミングと結び付けたすべての人に適しています。
エリック・レイモンドは、この「哲学」の17のルールを概説しています。 各ルールに1つのメモを付けます。 これらの概念を可能な限り最も理解しやすく、簡素化された一般的な形式で提示するようにします。
最初のルール-モジュール性のルール-から始めましょう。 「モジュール方式のルール：クリーンなインターフェイスで接続されたシンプルなパーツを書く」、明確で理解しやすいインターフェイスで相互に通信します。
つまり、設計段階であっても、ターゲットシステムを単純なブロックのセットに分解し、それらの間の相互作用の観点から車輪を再発明しないようにして、これの均一性を維持する必要があります。 各ブロックが1つのことだけを実行し、適切に実行することが非常に重要です。
実生活からの2つの例：1）システムユニットとモニターからの古典的なホームPC 2）ラップトップ。 たとえば、両方の画面で空白になりました。 私たちが理解しているように、理由は何でもかまいません。 しかし、自宅のPCの場合、最初の仮定を確認するのは簡単です：モニターは別のコンピューターで動作しますか？ 動作しない場合、その理由はモニターにあります。 その場合、理由はコンピューターにあります。 次に、別のコンピューターでビデオカードを試すことができます-そしてすぐにそれが事実かどうかを理解します。 状況は、キーボード、マウスでも同様です...
ラップトップの場合、すべてがより複雑です。 単純な素人の場合、彼には2つの状態があります。 何かが失敗した場合、原因を見つけることはそれほど簡単ではありません。 画面障害の原因は、ソフトウェア障害または機械的損傷のいずれかです。 はい、マスターにとってはこれらは異なるコンポーネントですが、あなたにとっては1つのラップトップです。 したがって、前の例よりも誤動作を判断する方が費用がかかります。 最初の診断については、少なくともサービスワークショップに連絡する必要があります。 最初のケースでは、自分で誤動作を判断し、モニターに障害が発生した場合、彼だけをサービスに連れて行くことができます。
ソフトウェア開発でも同じことが言えます。 各コンポーネントは、1つの非常に簡単なタスクを実行する必要があります。 当然のことながら、他の同様のコンポーネントと統合します。 そのようなメカニズムがより普遍的になればなるほど、より良いものになります。
私たちの実践から：Svyaznoy製品のアクセサリーとアナログの選択サービスを開発しています。 それ自体はかなり複雑なシステムですが、別のコンポーネントと考えると、ソリューションはすぐに美しく完成した外観になります。 コールセンター、電子カタログソフトウェア、Svyaznoy Webサイト、アップセールメーリングシステムに実装します。 そして、外部インターフェイスをより明確で理解しやすくするほど、おそらくそれも考えもしなかった新しいシステムに実装しやすくなります。
インターフェースの単純さにより、たとえば、すべてのユースケースがエミュレートされ、計算結果が期待される結果と一致するかどうかが確認されるテスト環境にコンポーネントを配置できます。 たとえば、私たちの実践からの例-配達時間を計算するときに、各テストケースの配達時間が手動で計算されたテーブルが作成され、その後、変更を加えると、テストで偏差または不在が示されました。
むかしむかし、大学卒業後、リャザンエコベント社のダクト設計システムを書きました 。 そこでは、エアダクトの任意のモデル、つまり3次元すべてに分岐のあるパイプを作成できます。 ある時点で、ソフトウェア部分全体を完全にやり直さなければなりませんでした。複雑になりすぎたからです。 設計変更を担当する個々のコンポーネント-たとえば、要素の追加など、「ブロック幅を追加= 100高さ= 100深さ= 10」という形式のテキストコマンドの形式のテキストインターフェイスがありました。 もちろん、ユーザーにそのようなコマンドの入力を強制する人はいませんでした。これには、幅、高さ、深さを入力する個別のグラフィカルウィンドウインターフェイスがありましたが、フォームはまだコマンドに変換されました。 これにより、数百のオブジェクトを作成して描画する必要がある複雑な状況を非常に簡単にデバッグできました。
UNIXの世界では、コマンドラインの1つの統一されたインターフェイスが長い間発明されており、「パイプ」（パイプ、|）と呼ばれています。 チャネルを介して、1つの非常に単純なタスクを実行するさまざまなプログラムを非常に簡単に接続できます。 たとえば、行数、文字数をカウントするユーティリティ（wc）、およびファイルの内容を表示するユーティリティ（cat）があります。 それらを次々に配置すると、たとえばファイル内の行数を取得できます（cat file | wc -l）。 そして、そのような「ユーティリティ」はすでに多く開発されています。 「オンザフライ」でそれらを結合する機能は、文字通り数秒でかなり複雑なタスクを解決するのに役立ちます。
要約すると、いくつかの簡単なヒントがモジュール性ルールの私の意味です。
» 続き：明快さのルール
Unixプログラマーは、これらの「ウィンドウオートメーション」から際立っています。 オープンソースソフトウェアの世界では、誰もがシステムソフトウェアと複雑なアプリケーションソリューションの開発に挑戦できます。 オープンソースソフトウェアの世界におけるそのような人々の業績は誰もがアクセス可能であり、私にとっては彼らは時々勧告を置き換える。 彼らの仕事が見えるからです。
私の意見では、自分の将来をソフトウェア開発につなぐことを決めた人にとっては一種の「聖書」である本がたくさんあります。 それらの1つで、一連の記事を始めたいと思います。 これはEric Reinmondの本、The Art of Unix Programmingです。 この本は、自分でオープンオペレーティングシステムを選択した人だけに推奨するものではありません。 それはかなり普遍的な哲学に基づいており、自分の職業をプログラミングと結び付けたすべての人に適しています。
エリック・レイモンドは、この「哲学」の17のルールを概説しています。 各ルールに1つのメモを付けます。 これらの概念を可能な限り最も理解しやすく、簡素化された一般的な形式で提示するようにします。
最初のルール-モジュール性のルール-から始めましょう。 「モジュール方式のルール：クリーンなインターフェイスで接続されたシンプルなパーツを書く」、明確で理解しやすいインターフェイスで相互に通信します。
つまり、設計段階であっても、ターゲットシステムを単純なブロックのセットに分解し、それらの間の相互作用の観点から車輪を再発明しないようにして、これの均一性を維持する必要があります。 各ブロックが1つのことだけを実行し、適切に実行することが非常に重要です。
実生活からの2つの例：1）システムユニットとモニターからの古典的なホームPC 2）ラップトップ。 たとえば、両方の画面で空白になりました。 私たちが理解しているように、理由は何でもかまいません。 しかし、自宅のPCの場合、最初の仮定を確認するのは簡単です：モニターは別のコンピューターで動作しますか？ 動作しない場合、その理由はモニターにあります。 その場合、理由はコンピューターにあります。 次に、別のコンピューターでビデオカードを試すことができます-そしてすぐにそれが事実かどうかを理解します。 状況は、キーボード、マウスでも同様です...
ラップトップの場合、すべてがより複雑です。 単純な素人の場合、彼には2つの状態があります。 何かが失敗した場合、原因を見つけることはそれほど簡単ではありません。 画面障害の原因は、ソフトウェア障害または機械的損傷のいずれかです。 はい、マスターにとってはこれらは異なるコンポーネントですが、あなたにとっては1つのラップトップです。 したがって、前の例よりも誤動作を判断する方が費用がかかります。 最初の診断については、少なくともサービスワークショップに連絡する必要があります。 最初のケースでは、自分で誤動作を判断し、モニターに障害が発生した場合、彼だけをサービスに連れて行くことができます。
ソフトウェア開発でも同じことが言えます。 各コンポーネントは、1つの非常に簡単なタスクを実行する必要があります。 当然のことながら、他の同様のコンポーネントと統合します。 そのようなメカニズムがより普遍的になればなるほど、より良いものになります。
私たちの実践から：Svyaznoy製品のアクセサリーとアナログの選択サービスを開発しています。 それ自体はかなり複雑なシステムですが、別のコンポーネントと考えると、ソリューションはすぐに美しく完成した外観になります。 コールセンター、電子カタログソフトウェア、Svyaznoy Webサイト、アップセールメーリングシステムに実装します。 そして、外部インターフェイスをより明確で理解しやすくするほど、おそらくそれも考えもしなかった新しいシステムに実装しやすくなります。
インターフェースの単純さにより、たとえば、すべてのユースケースがエミュレートされ、計算結果が期待される結果と一致するかどうかが確認されるテスト環境にコンポーネントを配置できます。 たとえば、私たちの実践からの例-配達時間を計算するときに、各テストケースの配達時間が手動で計算されたテーブルが作成され、その後、変更を加えると、テストで偏差または不在が示されました。
むかしむかし、大学卒業後、リャザンエコベント社のダクト設計システムを書きました 。 そこでは、エアダクトの任意のモデル、つまり3次元すべてに分岐のあるパイプを作成できます。 ある時点で、ソフトウェア部分全体を完全にやり直さなければなりませんでした。複雑になりすぎたからです。 設計変更を担当する個々のコンポーネント-たとえば、要素の追加など、「ブロック幅を追加= 100高さ= 100深さ= 10」という形式のテキストコマンドの形式のテキストインターフェイスがありました。 もちろん、ユーザーにそのようなコマンドの入力を強制する人はいませんでした。これには、幅、高さ、深さを入力する個別のグラフィカルウィンドウインターフェイスがありましたが、フォームはまだコマンドに変換されました。 これにより、数百のオブジェクトを作成して描画する必要がある複雑な状況を非常に簡単にデバッグできました。
UNIXの世界では、コマンドラインの1つの統一されたインターフェイスが長い間発明されており、「パイプ」（パイプ、|）と呼ばれています。 チャネルを介して、1つの非常に単純なタスクを実行するさまざまなプログラムを非常に簡単に接続できます。 たとえば、行数、文字数をカウントするユーティリティ（wc）、およびファイルの内容を表示するユーティリティ（cat）があります。 それらを次々に配置すると、たとえばファイル内の行数を取得できます（cat file | wc -l）。 そして、そのような「ユーティリティ」はすでに多く開発されています。 「オンザフライ」でそれらを結合する機能は、文字通り数秒でかなり複雑なタスクを解決するのに役立ちます。
要約すると、いくつかの簡単なヒントがモジュール性ルールの私の意味です。
- 各ブロック、プログラム、モジュールは1つだけを実行し、適切に実行する必要があります。 ブロックの目的である目標が「不鮮明」になり始めた場合、パーツへの分割について考える価値があります。
- 可能であれば、業界標準（XML、HTTP、RPC、CSV、JSON）の中からインターフェースを選択してください。それらを超えることはありません。
- ブロック数を増やすことでインターフェイスを簡素化できる場合は、単純化してください。 より多くのブロックがありますが、それらを個別にテストすることが可能になります。 もちろん、ブロックが単独ではなく、階層に並んでいる場合は正常です。
- パフォーマンスを著しく低下させることなく、より明確なタスクと標準インターフェイスを使用して、ブロックを小さなブロックに分割することでブロックの機能を単純化できる場合は、ブロックを分割します。 パフォーマンスが低下した場合でも、慎重に検討してください。時には、それを犠牲にする価値があります。 鉄が安くなった。
» 続き：明快さのルール
All Articles