手元でのテストが終わりました。じゃあレビュー担当エンジニアによるレビューということになりました。しかし、そのコードは標準では決まっていないものの、レビュー担当エンジニアが知らない機能を使っていました。たとえば、ラムダ式であったり、Windows 2000(Shell API 4.71)あたりで追加されたAPIであったり。
ラムダ式はまぁ新しいけれど、実は意外と新しい…といっても、XPあたりで追加されたAPI知らない人は多いです。特にShell Lightweight APIなんかは昔IEのバージョンに依存して更新されていたので、「IE 6が入っていなくてはならないから」といった理由や、手元にある書籍がWindows 98/Windows 2000の古い時代のものだったり。
標準に書かれていない機能だけど、レビュー担当エンジニアが知らない機能などを使っていたらどうしましょう*1?「ほかの人がメンテナンスできないから変えてくれ」とか言われないでしょうか?
個人的には別に使える奴は使っていいんじゃないか…と思います。ちゃんとテストがそろっていて、だれでもテストを実行して動作が追いかけられるようになっていれば。
たとえば、英語でも、読むのと聞くのはそこそこがんばれても、しゃべったり書いたりするのは聞いたり読んだりするレベルとつりあっていない人もいますよね(私もそうです)。あれと同じで、新機能を使って新しく作るのは慣れるまで結構大変だと思います。でも、読んだり試すのはそうでもない。そしてそういう人のソースを見て次に自分も使いたければ使えばいいのです。
簡単に作れるならそれに越したことはないし、基本的に書けるソースの長さはそう多くない。だったら効率良い方法を少しずつでも身につければきっと次回はもう少しいいものができるかもしれません。
とりあえずテストに関して思ったところはこのくらいでしょうか。なんか書き忘れていることがあればまた。
テスト後のリリース管理 - 新日々此何有哉
テスト結果の管理 - 新日々此何有哉
プラットフォーム更新時のテスト - 新日々此何有哉
テストとテストデータ - 新日々此何有哉
テストとサンプルコード、特殊なコードに関する話 - 新日々此何有哉
テストに関する話 - 新日々此何有哉

*1:ここではライセンスに問題があるようなライブラリを使った場合の話は除きます