記事が投稿された日付は気にしてはいけない。ヶ月前に下書きになっていた記事があったので掘り返し。タイムラインにこんなツイートが流れてきました。エンバグを断罪するような思考そもそも気に入らない。個人の注意力に依存するのは工学的じゃない。コメントせずにはいられませんでした。バグらないように「気をつけて」作るんじゃなく、バグる余地が無いように「考えて」作る。似ているようで、全く違う。今回は、この「バグらないように『気をつけて』作るのではなく、バグる余地が無いように『考えて』作る」という考え方について、もう少し深掘りしてみます。背景ソフトウェアに限らず、広くエンジニアリング(工学)の世界には「フールプルーフ」という考え方があります。いう英単語にもなっています*1。これはすなわち「人間はミス(ポカ)をするものという前提のもと、仕組みによって正しい挙動・安全を担保しよう」という考え方で、代表例としては「(片手が巻き込まれないように)両手でスイッチを押さないと動作しない工作機械」などが挙げられます。現在の私の仕事は、ミスによって人の命が失われたり怪我をしたりするような環境でありませんが、バグを生み出してしまえば何かしらの損害*2につながることには変わりません。この考えから私は「どうしたらバグが入り込む余地がないように作れるのか」ということに強い関心を抱き続けてきました。具体例どんなに気を付けても人間の注意力には限界があります。先述の通り「人間はミスをするもの」なのです。「注文」というデータを、次のように(連想)配列を使って表現したとします。],];このように表現すると、次のような「ミスをする余地」が生じてしまいます。文法上は正しいのですぐにエラーにならず、検知が遅れます。使ってループを書くことになります。これによてコードのネストは深くなり、見通しが悪くなりがちです。配列ではなくクラスを使って「注文」やその属性を表現してみるとどうなるでしょう。下記はあくまで一例です。}}このようにすれば、配列で表現していたときに存在していた「ミスする余地」が無くなります。なにかしらミスがあれば即座に構文エラーとして検知することができます。注文した商品の総数の計算ロジックもメソッド内に閉じられるのでコードの見通しも良くなります。「このデータが何なのか」という情報も、配列で表現していたときには「辛うじて変数名から推測できる」くらいだったものが、クラス(型)を持つことで明確になるというメリットもあります。このようにして設計の力によって「バグらせることを難しくできる」という風に考えられるわけです。余談これは私見になりますが「ミスをする余地」のあるプログラムを書くのは、プログラミング初心者だけでなく、頭の良い人*3の場合も多い気がします。頭が良いのでその人はこの方法でもミスすることがありません。この方法に疑問を持つ機会が無いのだと思います。そんなコードがひとたび「普通の人」に引き継がれれば、それはきっと悲劇の始まりでしょう。「バグる余地が無いように『考えて』作る」という考え方を広めていきたい、と思うのです。最近になって、この考え方についてさらに思うことが生まれてきました。これはちょっと長くなりそうなので別エントリに書くことにします。okashoi参加グループプログラミングはてなブログをはじめよう!okashoiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。