複雑なソリューションと失敗についての話[閉じる]

複雑なソリューションと失敗についての話[閉じる]

参考資料を探しています。クライアントがクラッシュ(または同様)して問題なく再起動するのではなく、あるチームはやや複雑な方法で問題を解決し、他のチームは失敗する話です。

明らかに本のどこかで読んだようです。Unixプログラミングの芸術しかし、見つかりません。

ベストアンサー1

ついに見つけました。リチャード・P・ガブリエルの「悪い方が良い」私もその本を読んだUnixプログラミングの芸術。簡単に話すとこんな感じです。

MIT出身とバークレー出身(しかしUnixで働いている)という2人の著名な人々がかつて出会い、オペレーティングシステムの問題を議論しました。 MITの人々は、UnixがPCエラーの問題をどのように解決したかに興味がありました。これは、基本的に長い操作を実行するシステムコールが保持またはマスクできない割り込みを処理する方法に関するものでした。 MITにいる人はこの事件を処理するコードを見ていないし、ニュージャージーの人に問題を処理する方法を尋ねました。ニュージャージー州の従業員はUnixの人々が問題を知っていますが、解決策は常にシステムルーチンを完了させることでしたが、システムルーチンが操作を完了できなかったことを示すエラーコードを返すことが時々ありました。その後、正しいユーザープログラムはエラーコードを確認して、システムルーチンを再試行するかどうかを判断する必要があります。 MITの人々は、この解決策が「正しい」仕事ではないので好きではありませんでした。ニュージャージー州の人々は、Unixソリューションが正しいソリューションだと言います。なぜなら、Unixは単純に設計されており、正しいことは複雑すぎるからです。さらに、プログラマはこれらの追加のテストとループを簡単に挿入できます。 MITの人々は、実装は簡単ですが、機能へのインターフェースは複雑であると指摘しました。ニュージャージー州出身の彼は、Unixでは正しいトレードオフが選択されたと述べた。つまり、実装のシンプルさがインターフェイスのシンプルさよりも重要であると言いました。

おすすめ記事