技術者の評価を下げる「悪い」コメントに注意しよう
ソフトウェアの受託開発や、オープンソースのプロジェクトでは、ソースコードが他の技術者の目に触れる。そのため、ソースコードから開発者の技術力が評価されやすい。 ソフトウェアの開発者は、モジュール分割やクラス設計には全力を傾ける。最近では、設計の完成度を高めるために、実装の後でリファクタリングを行うことも珍しくない。 だが、設計の善し悪しにこだわる開発者でも、ソースコードに書くコメントの品質までは、配慮が及ばないことが多い。コメントは本質的なものではないので、つい気を緩めてしまうのである。 ところが、開発者の希望に反して、ソースコードの読み手が印象を受けやすいのは、コメントの品質である。ソースコードから設計を読み解くのは容易ではないが、日本語や英語で書かれているコメントは目に付きやすい。 優秀な技術者の書いたソースコードでも、驚くほど「悪い」コメントが書かれていることがある。そのようなソースコ
実践！電卓で学ぶソフトウェアテストのコツ
品質の良いソフトウェアを作るためには、ソフトウェアテストの技術が不可欠です。 ソフトウェアは出荷される前に、必ずテストされます。しかし厄介なことに、ソフトウェアをふつうに操作しているだけでは、たいていは問題なく動作してしまいます。バグがあっても、なかなか尻尾を出しません。 ソフトウェアテストの真髄は、奥深くに隠れているバグをいかに見つけ出すか、です。ソフトウェアをありとあらゆる方向から使いまくり、いじり倒して、バグを絶滅させなければなりません。 どのようなテストをすればバグを見つけられるのかは、難しい問題です。バグを見つける能力は、ソフトウェア技術者の実力です。熟練したテスターは、ふつうの人より圧倒的に多くのバグを見つけ出します。 バグを見つける技術は、経験で身につけるのが一番でしょう。 ここでは、Windowsに付いてくる「電卓」から、バグが見つけられるかどうか、試してみたいと思います。
実装が終わってからプログラム説明書を書こう
設計書と説明書は同じもの!? 一般的な開発手法では、はじめにソフトウェアの設計を行い、設計書を作成する。ここで提案する手法では、更に、実装の後にプログラム説明書を作成する。 これらはいずれも、ソフトウェアがどのような作りになっているかを解説するドキュメントである。よって、この２つのドキュメントの内容は、まったく同じになる。 では何故、はじめに設計書を作っているのに、改めて同じ内容の説明書を作らなければならないのだろうか。 設計書と説明書では、読み手が異なる 実装の前に作成する設計書とは違って、プログラム説明書は実装の後で、完成したソフトウェアを元に作成する。同じプログラムの作りを解説するドキュメントであっても、実装の前に書くのと後に書くのとでは、出来上がる文章は、まったく別物になる。 設計書は、これからどのように実装するか、その指針を書いたものである。つまり、実装を行う自分自身のために作る
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
