設計レビューやソースコードレビューといったレビューは、ソフトウェアの品質確保だけでなく、開発者のスキル向上のためにも非常に有意義です。このレビューを有意義なものとするために心がけてべき最も重要なことのひとつが、 「自分の書いたソースコードや設計書に対して客観的であること」 です。簡単そうで、これがなかなか難しい。 人間、自分で作ったものは愛着が出ます。これはソースコードも同じ。エレガントなモデル設計やスマートなアルゴリズムに仕上がったものは誇らしいけど、混乱した設計や実装も、こんなはずじゃないんだ、分かっているんだとかばいたくなる。なので、人からつっこまれると、ついつい、ソースコードの味方をしてしまうことがあります。これは、ちょっと過保護で、ソースコード君のためにはなりません。 では、客観的な立場に立てているどうかはどうやったら分かるでしょうか。ひとつの方法は、「レビューの指摘に対して、ソ

年々仕事量が増えてきて、どんどん忙しさは増してくる。原因は、次々とふってくる仕事。こなしてもこなしても、空いたスペースに仕事が入ってくる。。。 私自身そうですが、業界問わずよくある話だと思います。仕事がもらえるのはありがたいとは言えるのですが、こんな時は、ついつい「やらされている」という意識をもってしまいがちです。既に十分すぎるほど忙しくて余裕がない時に、新たにたのまれた仕事などは特にそうでしょう。しかし、仕事に対する意識が「受身」になると、モチベーションもさがってしまいまい、効率も非常に落ちてしまいます。 「やらされている」という意識の裏には「こんな仕事やりたくないのに」という思いがあります。やりたくないのだからモチベーションなんてあがるはずもありません。しかし、同じ仕事でも、その時自分に余裕があれば、積極的にヘルプにまわることだってあるのではないでしょうか。例えば、人のデバッグ手伝うと

プログラミングにおける変数や関数、クラス設計の命名というのは、そのプログラムの可読性を左右する最も重要な要素のひとつです。変数名や関数名が適切であれば、プログラムの流れも読みやすいですし、バグがあっても見つけやすいものです。 さて、このような命名規則(命名規約)といったものは、大抵それ読む人間のために設定されます。コンパイラにとっては、変数名がoldUserNameだろうがounだろうがxだろうが、関係ありません。変数名は単なる記号です。 しかし、考えて見るとこれは非常にもったいない。人間が、変数名からエラーを発見できるということは、このルールを(広い意味での)コンパイラに教えてあげれば、同じようにエラーを発見してもらえるのではないでしょうか。 例えば以前に次のようなバグコードを見たことがあります。 .... len = strlen(name); strncpy(buf, name, s

デバッグ指向プログラミング(debug-oriented programming)とは何か。一言で言うとすると、「デバッグしやすいプログラムを書きましょう」ということです。テスト指向(test-oriented)と近いところもありますが、よりデバッグの効率に重点を置いた考え方です。詳しい内容は今回だけでは書ききれませんが、とりあえず今回は、なぜデバッグ指向なのか、デバッグ指向とは具体的にどんなものか、ということについて書いてみたいと思います。 バグの発生は必然 バグの発生は予定外の出来事ではありません。よほど小規模のプログラムでない限り、ソースコードが一発で不具合なく動くことはほとんどありません。つまり、デバッグ作業というものは、ソフトウェア開発において重要なステップなのです。実際、大抵のソフトウェア開発では、コーディングそのものよりもデバッグに費やす時間の方が多いことが多いのではないでし

一般的にバグの発生箇所と発現箇所が離れれていると、デバッグは難しくなり、時間もかかりがちです。今回のお話は、このような「バグの潜伏」を抑制し、「バグ」にいち早く気付かせるための実装上の工夫についてです。 ライブラリ設計において、何らかのオブジェクトにアクセスするIDを定義することがあります。例えば次のような関数定義があったとします。 file_id_t open_file(const char* path, int flags); ssize_t read_file(file_id_t id, char* buf, size_t size); ssize_t write_file(file_id_t id, const char* buf, size_t size); off_t seek_file(file_id_t id, off_t offset, int whence); int

失敗はつまずくことではない。つまずいたままでいることだ。 またまた更新間隔が開いてしまったので、久々の更新です(^^;)。今回は「エラー処理」を取り上げてみます。「エラー処理」という単語もあいまいなのですが、今回とりあげるのは「あるメソッド・関数が本来の処理を達成できなかった場合の処理」といったところです。 エラーを伝える さて、処理が失敗した時の最も基本的なパターンは、戻り値としてエラー値を返すことです。このような関数・メソッドは数多くあります。例えば、POSIX系のclose()関数をみてみましょう。 int close(int fd); これはエラーで0以外の値が返ります。このように、エラーか否かを戻り値で返すものの他に、本来の戻り値がとり得ない値をエラーの意味として返すものもあります。例えば、POSIX系のopen()関数です。 int open(const char *pathn