Unixでのプログラミングの技術（だけでなく）。 パート5、シンプルさのルール
「 エリック・レイモンドによる」Unixのいくつかの簡単な開発ルールに焦点を当てた一連の記事を続けます。これは、私の最も深い信念において、他のオペレーティングシステムに拡張できます。 最初の3つのパートでは、 モジュール性 、 明clarity性 、 構成および分離の規則についてすでに話しました。 今日では5番目のルールになります-
ルール5：本当に必要な場合にのみ複雑さを追加します（簡単にするために設計し、必要な場所にのみ複雑さを追加します）。
さまざまな情報システムを設計するとき、私はしばしば「やめなさい：本来あるべきよりも難しいことがわかった」と言い、最初に戻って何が悪かったのかを理解します。 システムの複雑さは、サポートのコストではなく、開発のコストではありません。 複雑なシステムに対して変更がもたらす結果はどうなるかという質問への答えは、ビジネスが必要とするよりもかなり多くの時間を必要とします。 段階的に、システムは死にかけ、プログラマーの間では、製品全体の完全な変更についての考えがますます大胆に表現され始めています。
KISSの原理と「Occamの剃刀」については、「明快さは賢さよりも優れている」という原則についての記事で以前に書きました。 したがって、この記事は、単純さと複雑さのトピックに関する他の人々の考えのダイジェストとして提示します。
アントワーヌ・ド・サン・テグジュペリは、この機会に優れた考えを述べました。「 ご覧のとおり、完璧なものは、追加するものがないときではなく、持ち去ることができるときです 。」 新しいiPhoneが登場した時代を思い出してください。「iPhoneにはないものと私の祖母の年金受給者の電話」というトピックに対する冗談は、すべてのフォーラムのライトモチーフでした。 良い時間に間に合うように、これはすべて余分だったからです。 私たちが見るように、中国人はまったく逆のことを考えます。
何か 新しいことを十分に加えて、これがどれだけ効果を生み出すか、それを評価できたかどうか、または単に推測するたびに自問します。 特に2番目のケースでは、機会を残して、痛みを伴わずに「切断」します。
Perlには、Larry Wallに起因するいくつかのモットーがあります。 1つは「それを行う方法は複数あります」です。これには、TMTOWTDIの削減もあります。 2つ目は、「 単純なことは単純で複雑なことを可能にする必要があります」（簡単なことは簡単で、難しいことは可能であるべきです）です。 開発者が比較的迅速に改訂の実行可能性に関する質問に答えることができず、少なくとも人件費と必要な変更を大まかに見積もることができない状況は警戒すべきです。 そのため、システムを制御するのは開発者ではなく、彼女...
特に、データ構造の簡素化に努めるべきです。 「 Cathedral and Bazaar 」という本のエリック・レイモンドは、「正しいデータ構造と悪いコードは、良いコードと悪いデータよりもわずかにうまく機能する 」という非常に正しい考えを述べました。 システムを「作り直し」、主な困難は非常に多くの場合、データと設計の誤りです。 先週、私はプログラマーにインタビューしました。プログラマーは、彼の意見では、住所情報を保存するための正しいオプションについての質問に答え、まれな記号で区切ってすべてを1つのフィールドに保存することを提案しました。 その後のすべての質問はすぐに消えました。
この主題に関する別の表現は、 ルートヴィヒ・ヴィットゲインシュタインによるものです 。「 良い建築家は、悪い建築家とは誘惑に 負け、 良い建築家はそれを避けるという点で、悪い建築家とは異なります。」 ですから、それはプログラミングにあります。何か を追加したい場合は、停止し、紙に書き留めて、それが機能するように作業を続けます。 システムをゼロから設計する場合は、最も必要なものだけを残し、小さな「超過分」を慎重に追加します（引用符なしで追加する必要はありません）。
製品仕様の開発レベルでは、顧客が最初に望んでいたことを最終的に理解したときに、多くの問題が発生します（2回目は、最初のプロトタイプを見たときにこれを理解し、3回目はすべてが既に実装されているとき）。 仕様を複雑にするのは非常に簡単です-文字通りすべてがそれに関係しています。 それに取り組むことは非常に難しいでしょう。 したがって、ルールに従うことは価値があります。変更の価格には、この変更だけでなく、影響の分析と、可能性の高い拡張機能のブックマークの価格（必要に応じてこの変更を削除することを含む）が含まれます。 要件の数が増えると、設計文書と製品の両方でこのような変更の価格が高くなることは明らかです。 したがって、できるだけ早く、追加のすべての非キー要件を次の段階に持ち込むことをお勧めします。これにより、最初の要件をできるだけ早く開始して、プロトタイプと最初のリリースをできるだけ早く取得できるようになります。 十分に機能的ではありませんが、シンプルにしましょう。ただし、パフォーマンス、使いやすさ、信頼性のテストの準備はできています。
今日の記事は、 オスカーワイルドの有名な表現で締めくくります。 オスカーワイルドのその確認は、あらゆる段階で文字通り会います。 複雑なこと。 人生はシンプルなものであり、その中でよりシンプルなものほど、より正確です。」
ルール5：本当に必要な場合にのみ複雑さを追加します（簡単にするために設計し、必要な場所にのみ複雑さを追加します）。
さまざまな情報システムを設計するとき、私はしばしば「やめなさい：本来あるべきよりも難しいことがわかった」と言い、最初に戻って何が悪かったのかを理解します。 システムの複雑さは、サポートのコストではなく、開発のコストではありません。 複雑なシステムに対して変更がもたらす結果はどうなるかという質問への答えは、ビジネスが必要とするよりもかなり多くの時間を必要とします。 段階的に、システムは死にかけ、プログラマーの間では、製品全体の完全な変更についての考えがますます大胆に表現され始めています。
KISSの原理と「Occamの剃刀」については、「明快さは賢さよりも優れている」という原則についての記事で以前に書きました。 したがって、この記事は、単純さと複雑さのトピックに関する他の人々の考えのダイジェストとして提示します。
アントワーヌ・ド・サン・テグジュペリは、この機会に優れた考えを述べました。「 ご覧のとおり、完璧なものは、追加するものがないときではなく、持ち去ることができるときです 。」 新しいiPhoneが登場した時代を思い出してください。「iPhoneにはないものと私の祖母の年金受給者の電話」というトピックに対する冗談は、すべてのフォーラムのライトモチーフでした。 良い時間に間に合うように、これはすべて余分だったからです。 私たちが見るように、中国人はまったく逆のことを考えます。
Perlには、Larry Wallに起因するいくつかのモットーがあります。 1つは「それを行う方法は複数あります」です。これには、TMTOWTDIの削減もあります。 2つ目は、「 単純なことは単純で複雑なことを可能にする必要があります」（簡単なことは簡単で、難しいことは可能であるべきです）です。 開発者が比較的迅速に改訂の実行可能性に関する質問に答えることができず、少なくとも人件費と必要な変更を大まかに見積もることができない状況は警戒すべきです。 そのため、システムを制御するのは開発者ではなく、彼女...
特に、データ構造の簡素化に努めるべきです。 「 Cathedral and Bazaar 」という本のエリック・レイモンドは、「正しいデータ構造と悪いコードは、良いコードと悪いデータよりもわずかにうまく機能する 」という非常に正しい考えを述べました。 システムを「作り直し」、主な困難は非常に多くの場合、データと設計の誤りです。 先週、私はプログラマーにインタビューしました。プログラマーは、彼の意見では、住所情報を保存するための正しいオプションについての質問に答え、まれな記号で区切ってすべてを1つのフィールドに保存することを提案しました。 その後のすべての質問はすぐに消えました。
この主題に関する別の表現は、 ルートヴィヒ・ヴィットゲインシュタインによるものです 。「 良い建築家は、悪い建築家とは誘惑に 負け、 良い建築家はそれを避けるという点で、悪い建築家とは異なります。」 ですから、それはプログラミングにあります。
製品仕様の開発レベルでは、顧客が最初に望んでいたことを最終的に理解したときに、多くの問題が発生します（2回目は、最初のプロトタイプを見たときにこれを理解し、3回目はすべてが既に実装されているとき）。 仕様を複雑にするのは非常に簡単です-文字通りすべてがそれに関係しています。 それに取り組むことは非常に難しいでしょう。 したがって、ルールに従うことは価値があります。変更の価格には、この変更だけでなく、影響の分析と、可能性の高い拡張機能のブックマークの価格（必要に応じてこの変更を削除することを含む）が含まれます。 要件の数が増えると、設計文書と製品の両方でこのような変更の価格が高くなることは明らかです。 したがって、できるだけ早く、追加のすべての非キー要件を次の段階に持ち込むことをお勧めします。これにより、最初の要件をできるだけ早く開始して、プロトタイプと最初のリリースをできるだけ早く取得できるようになります。 十分に機能的ではありませんが、シンプルにしましょう。ただし、パフォーマンス、使いやすさ、信頼性のテストの準備はできています。
今日の記事は、 オスカーワイルドの有名な表現で締めくくります。 オスカーワイルドのその確認は、あらゆる段階で文字通り会います。 複雑なこと。 人生はシンプルなものであり、その中でよりシンプルなものほど、より正確です。」
| " 以前：構成ルール | 続き：コード保存のルール " |
All Articles