きのこ本の感想の続き、書いていきます。
あれこれと予定が増えすぎて、きのこ本まで手が届かないですね。時間を有効に活用すればできそうではありますが…
37 バグレポートの使い方 (マット・ドーア, Matt Doar)
バグレポートは開発における上で一種のコミュニケーション手段になりえるものですね。
その点を忘れてしまうと残念なバグレポートがよく生まれるみたいですね。たまに現場の方の話を聞いていると、バグレポートが「人に伝えるような書き方になっていない」ことが多いようです。
バグレポートとして
- バグの再現方法
- 本来の仕様
- 実際の動作
は必須事項ですね。エッセイでもこれは必要であると書いてあります。
私としてはできればどの段階で発見されたかもわかるといいかなと思います。もちろん、どの段階というようなものじゃないこともあるとは思うのですが、単体テスト、受け入れテスト、コンポーネントテスト、システム・パフォーマンス・負荷テストなどで発見された場合はこのテストのどの段階で発見されたかもわかった方がいいのでは？と思ったりしています。
バグ自体がどの段階で発生するようなものかをテストから判断することもできると思うので、この辺も書ければ書いておいた方が私としてはいいのかなと思います。
単純なバグレポートとしては不要な情報になってしまうのかな…？
私としてはバグレポートは「正式なドキュメントと思って」書くべきだと思います。
38 余分なコードは決して書かない (ピート・グッドリフ, Pete Goodliffe)
必要ないものは書かない。
これは原則ですね。
現在のコードは複雑で量もとても多いものになりやすいので、必要ないものを書いているとすぐに煩雑でとんでもない量のスパゲティコードが生まれることになるでしょう。
そして保守は難しくなり、レガシーコードへと落ちていくわけです。
やはり、コードの中に不要な部分を削ることは重要ですよね。
私としてはコードだけでなくコメントにも注意すべきだと思いますね。
コメントも不要なものはできる限り追加しない。理解できることをあえてコメントで書く必要はないと思います。
javadocみたいなものを使っているならもちろんドキュメントになる部分に手を抜くのはよろしくないとは思いますが。
39 最初が肝心 (マーカス・ベイカー, Marcus Baker)
このエッセイに書いてあることは分かりますね。
意味不明なインストール方法やそもそもインストール方法が書いてない、あってもその通りでは動かない、ひっそりと公式サイトの端の方にあるバグレポートのまとめにのみ対応策が書かれてる、なんていうのを見るとそのソフトウェアを入れる気にはなりませんね。
またちょっと試してみようくらいの気持ちの時には、どうしても自分でソースコードからデプロイまでを行わなければならないような形式になっているのは正直諦めたくなりますね。
あと、会員登録みたいなものが出てくると他を当たろうと思います。
最近では私もある程度ならソースコードからコンパイル、デプロイなどを行うようにはなりましたが、それでもコンパイル時などに問題が発生すると一人ではたいてい対応しきれません。バグレポートをあさったり、Googleを調べたりして見つからなければ諦めます。
それだけの時間を掛けて効果が得られるなら良いのですが、得られるか分からない時にそこまで時間をかけたくはないです。それほど時間を投げ捨てられるほどは持っていませんから。
最後に
今回のエッセイに書かれていることはちょっとした事に見えますが、重要なことですね。
特に最後のはよくあり過ぎて、うなずけますね。
もちろん限度はあるのでしょうが、出来れば「やってくれるだろう」という形を取るのはやめてほしいかな。とくに初心者は厳しいです。プログラマサイドから見て「やってくれるだろう」はやめるべきですね。
