Unixでのプログラミングの技術（だけでなく）。 パート2、クラリティは賢さよりも優れています
「The Art of Unix Programming」のEric Raymondのルールに関連する一連の記事を続けます。
最後の投稿では、モジュール性の規則について書いた。 単純なブロックは明確で理解しやすいインターフェースで接続する必要があるということを思い出させてください。
今日は次のルールについてお話します-
明快さのルール： 明快さは賢さよりも優れています（または、明快さはスキルよりも優れています）
明快さのルール：明快さは賢さよりも優れています。
おそらく、KISSとして知られる原理と設計プロセスについて何度も聞いたことがあるでしょう。 この略語は、「短く簡単に保つ」（「簡単にする」）または「シンプルに保つ、愚かな」（「複雑にしないでください！」など）の略です。 実際には、問題の2つの解決策（単純なものと複雑なもの）を知っている場合は、2番目の問題を決定する前によく考えてください。
多くの場合、プログラマは自分の目標に適さないタスクを自分で設定します。 彼らは自分自身でそれを英雄的に克服するための問題を思いつきます。 これには、タスクだけでなくタスクのクラス全体を解決することを可能にするあらゆる種類の「エンジン」の作成が含まれます。 たとえば、既製の検索エンジンを使用する代わりに、自分で作成します。 もちろん、タスクはより興味深いものになりますが、不安定なソリューションを取得するリスクは高くなり、サポートはさらに高価になります。
ちょっとした余談：ここでの状況は非常に一般的で、元のタスクにはなかった独自の要件を考えたことがあるかもしれません。 それらは本当に余計なものではないかもしれませんが、決して自分の中に隠れてはいけません。 顧客に外部タスクがある場合、これらの要件を修正して承認し、代替案、リスク、利点、欠点を示すことは非常に正しいことです。
このルールに関連するアルバート・アインシュタインの有名な表現を思い出す価値があります：「すべてをできるだけ長く単純化する必要がありますが、それ以上ではありません」と「できるまで何も理解できないと言うことはできません」それをあなたの祖母に説明してください。」 アクセサリを選択したり、価格表を処理したりするためのシステムのロジックを祖母に説明できるかどうかはわかりません。 しかし、私はビジネスの人に簡潔かつ簡潔に説明しなければなりません。 これが失敗する場合は、非常に複雑なシステムを考え出しています。 簡素化、そうでなければ彼女はテナントではありません...
オッカムの剃刀という主題に近い哲学的概念があります。 その本質は、現象の定義または説明がいくつかある場合、それらの最も単純なものが正しいと見なされるべきであることです。 しかし、多くの場合、「Occam's Razor」は「不必要に実体を増殖させない」という別の文脈で想起されます（哲学者に関しては完全に真実ではありませんが、それ自体が正しいです）。 このルールは、プログラミングのほぼすべてのステップで役立ちます。
だから、私は要約します：
最後の投稿では、モジュール性の規則について書いた。 単純なブロックは明確で理解しやすいインターフェースで接続する必要があるということを思い出させてください。
今日は次のルールについてお話します-
明快さのルール： 明快さは賢さよりも優れています（または、明快さはスキルよりも優れています）
明快さのルール：明快さは賢さよりも優れています。
おそらく、KISSとして知られる原理と設計プロセスについて何度も聞いたことがあるでしょう。 この略語は、「短く簡単に保つ」（「簡単にする」）または「シンプルに保つ、愚かな」（「複雑にしないでください！」など）の略です。 実際には、問題の2つの解決策（単純なものと複雑なもの）を知っている場合は、2番目の問題を決定する前によく考えてください。
多くの場合、プログラマは自分の目標に適さないタスクを自分で設定します。 彼らは自分自身でそれを英雄的に克服するための問題を思いつきます。 これには、タスクだけでなくタスクのクラス全体を解決することを可能にするあらゆる種類の「エンジン」の作成が含まれます。 たとえば、既製の検索エンジンを使用する代わりに、自分で作成します。 もちろん、タスクはより興味深いものになりますが、不安定なソリューションを取得するリスクは高くなり、サポートはさらに高価になります。
ちょっとした余談：ここでの状況は非常に一般的で、元のタスクにはなかった独自の要件を考えたことがあるかもしれません。 それらは本当に余計なものではないかもしれませんが、決して自分の中に隠れてはいけません。 顧客に外部タスクがある場合、これらの要件を修正して承認し、代替案、リスク、利点、欠点を示すことは非常に正しいことです。
このルールに関連するアルバート・アインシュタインの有名な表現を思い出す価値があります：「すべてをできるだけ長く単純化する必要がありますが、それ以上ではありません」と「できるまで何も理解できないと言うことはできません」それをあなたの祖母に説明してください。」 アクセサリを選択したり、価格表を処理したりするためのシステムのロジックを祖母に説明できるかどうかはわかりません。 しかし、私はビジネスの人に簡潔かつ簡潔に説明しなければなりません。 これが失敗する場合は、非常に複雑なシステムを考え出しています。 簡素化、そうでなければ彼女はテナントではありません...
オッカムの剃刀という主題に近い哲学的概念があります。 その本質は、現象の定義または説明がいくつかある場合、それらの最も単純なものが正しいと見なされるべきであることです。 しかし、多くの場合、「Occam's Razor」は「不必要に実体を増殖させない」という別の文脈で想起されます（哲学者に関しては完全に真実ではありませんが、それ自体が正しいです）。 このルールは、プログラミングのほぼすべてのステップで役立ちます。
だから、私は要約します：
- まず、シンプルで明確な決定に移りましょう。
- 複雑な決定をすべて、できればできるだけ早い段階で、重要な分析に委ねてください。自分自身を単純化する方が費用がかかると確信できるまでは。
- 合併症には、顧客との理想的な合意と承認が必要です。
| “ 始まり：モジュール性のルール | 継続：構成ルール " |
All Articles