Beautiful Code

第15章を読んで考え中。

実装側の意識としての、『暗黙のうちの制約』は、「ああ、その通りだなぁ」と。プログラミング実習の課題で、「受けたデータを加工して出力してください」と旨のを設けているんだが、仕様にはどこにもインプットするデータ長に関しては(わざと)書いてないんだが、今まで正しく制限無しのコードを書いてきた人は、ほぼ居ない。大体が２桁バイトまでの意識で書いてくる。そして９割方の人は、自身が設けた規定以上のデータを受けるとクラッシュ系のバグを盛り込んでくる。

それはまぁ良くある事例なので放置。

今回、考えたのは15章での『エラー通知』に関して。うまくいかなかった理由を正しく返せてたかなぁ。実際、実装してきてテストの際、「正しく動かない」こと自体の指摘はあるが、「正しく動かなかった理由が無い仕様不備」に関しては、ほぼ無い。あってもUI系で足りないからという理由から。それ以外では無い。まぁ要求仕様では無いからな。

「正しく動くライブラリ」は要求されるが、正しく動かない時に「正しくエラーを返すライブラリ」は重要視されてない。ユーザ通知系なら必要だけど、他は、まぁ必要とされてない気がする。

また、これまで行ってきた「エラーログを残す」戦略ってのは、正しいのか？。今まで、先輩からの経験値として得ていたのは、「必要最小限のログを残してエラー原因を早期に検知すること。ログを残して自身のコードが(正しい|正しくない)ことを判定できる情報を出力すること。もし自身の担当が原因でないなら、エラーを出している担当を正しく検出し早期バグ解決に導くこと。」だったはずだ。

だけどコレだとエラー原因はログを出力している担当者にしか分からないよな。

ライブラリ実装側、ライブラリ利用側の双方、ハッピーになるには、エラーコードを充実して、何がダメかを通知することなんじゃ。と。今のエラー分類ってかなり間違ってるんかな。見直してみないとな。