(jp) =
<!–
–>

昨日、興味深いブログ記事を読みました。 2008年にさかのぼる古いもので、「関数が何もしない場合でも、明日何かをするかもしれないので、ドキュメントにそう書かれている場合でも呼び出す必要があります」. それはかなり一口ですが、記事自体はかなり短いです。 1 つの段落に要約できます。
Windows カーネルには、何もしない関数がありました。 それでも、ドキュメントはプログラマーに、この関数は 持っていました 別のものを呼び出した後に呼び出される: もしも きみが呼んだ GetEnvironmentStrings、 あなた また 電話する必要がある FreeEnvironmentStrings. しかし、多くのプログラマーは無意味だったのでわざわざそうしませんでした: FreeEnvironmentStrings 何もしませんでした。文字通り空の関数でした。 数年後、その関数は実際に実装され、多くのアプリケーションが機能しなくなりました。これは、プログラマーが最初から関数を呼び出そうとしなかったためです。
この記事では、次のように要約しています。
ドキュメントに関数を呼び出す必要があると記載されている場合は、関数を呼び出す必要があります。 関数は何もしないかもしれませんが、それが将来何かをするのを妨げるわけではありません。
または、私がそれをどのように表現したいか:可能な限り最もくだらないソフトウェア設計のいくつか。
コメント セクションでは、Microsoft と開発者 (Microsoft のコードのユーザー) のどちらが失敗したのかについて、議論が巻き起こりました。 結局のところ、ドキュメントはユーザーにその関数を呼び出す必要があることを明示的に伝えているため、ルールに従わなかった場合、ユーザーは独力でした.
ただし、マイクロソフトを非難するコメンテーターが数人いました。
代わりに、プログラマーが API を正しく使用できず、プログラムをコンパイルできるように API を設計してみませんか?
ソース
と:
私自身、時々システムプログラマーとして、何もしない関数呼び出しに固執し、人々がそれを契約する。
ええと、それは本当に良いアイデアのように思えましたか? Windows NT 4 の頃には、多くのアプリケーション開発者が、あなたが言ったとおりに物事を進めようとはしないということをずっと前に理解していたのではないでしょうか?
これは最初に MS のエラーです。 アプリ開発者の秒。 どちらも正しくありませんが、MS の方が間違っていました。
ソース
私の意見では、これらはいくつかの理にかなった議論です。 一般に、ユーザーは、1 つはドキュメントを読み、2 つはその時点では意味がないと思われるルールに従うことを信頼することはできません。 それは、世界が機能する方法ではありません。
でもまあ、これは 2008 年のことで、今はもっとうまくやれるようになったんですよね? ええと…実際には、他の人が使用するコードを書くことはまだ非常に一般的です。 推定 それらのユーザーは、そのコードを責任を持って使用する方法を知っています。 私は個人的に、この考え方に従う人をたくさん知っています。 私は彼らをとても尊敬していますし、彼らも私がこの意見に同意しないことを知っています。
ただし、ユーザーの観点から見ると、この考え方も最適ではありません。コードが 自体 それがどのように使用されるべきかについて明確ではなく、ユーザーの心に導入された不確実性のレベルがあります。 「ここで何か不足していますか?」 「このコードを実際に使用する前に、利用可能なすべてのドキュメント ページを読む必要がありますか?」
ベンダーにとってもユーザーにとっても、コードをできるだけ明示的かつ堅牢にし、解釈や不確実性の余地をできるだけ少なくする方が、より良いソフトウェア設計だと思います。
私の意見では、それは次のことを意味します。
- 適切な型システムを使用する (できるだけ厳密に)
- 設計による場合を除き、クラスの拡張を許可しない
finalデフォルトで - 仕様によるものでない限り、状態を外部から書き込み可能にすることはできません。
readonlyデフォルトで - メソッドをパブリック API に追加するだけで、 実際に 一般にアクセス可能であるべきであり、
privateデフォルトで - どこでも明確で明確な名前を使用する
- 実装ではなくインターフェイスへのプログラミング
ベンダーにとってもユーザーにとっても、コードを可能な限り明示的かつ堅牢にし、解釈や不確実性の余地を最小限に抑えることが、より優れたソフトウェア設計です。
私にとって、それは不信の問題ではなく、IDE から遠く離れた場所にあるドキュメントに書かれた一連のルールを掘り下げることなく、何をするのかが明確なコードを書くことです。
最近では、追加の説明を必要としないコードはほとんどありません。
//platform.twitter.com/widgets.js