コードレビューの視点 016

ボクシングに注意する

Java言語に限った話ですが、不注意なボクシング/アンボクシングに注意する必要があります。

Javaが1.4の頃からプログラミングしている人であれば、自動ボクシングが言語仕様として存在しない頃からJavaを使用していわけですから、Booleanクラスとboolean型の違いを分かっていると思います。しかし、Java SE 5.0以降からJavaでプログラミングを始めた人は違いが分かっていない人が増えてきていると思います。

5.0は、2004年9月にリリースされていますので、すでに10年以上が経過しています。そのため、基本データ型（byte, short, char, int, long, float, double)とラッパークラス（Byte、Short、Character、Integer、Long、Float、Double）の違いを分からないままプログラミングしている人がいるのではないでしょうか。そのため、コードレビューなどで、以下のようなフィールド宣言を見かけたりします。

Boolean flag = false;

この場合、どうして「booleanではなく、Booleanなのですか？」という質問に対して、質問の意図を理解できないようであれば、ボクシングを理解していないと思って間違いないでしょう。

不注意なボクシングは、使用するメモリ量の増加や性能低下になってしまいます。その仕組みについては、初心者でもしっかりと理解しておくことが必要です。ボクシングに関しては、拙著『Java 2 Standard Edition 5.0 Tiger』の第2章「ボクシング/アンボクシング」を参考にしてもらうとよいかと思います。

コードレビューの視点 015

意図しない継承に注意する

Java言語でクラスを設計する場合に、継承されることを想定していなくても、実際には継承可能なコードを書いてしまうことが多いです。たとえば、次のコードを考えてみてください。

public class Point {
    private final int x;
    private final int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() { return x; }
    public int getY() { return y; }
}

このようなクラス宣言をした場合には、このクラスの使用方法は、1つではありません。単純にインスタンスを生成するだけでなく、クラスを継承して別のクラスを作成するという使用方法や、さらに、メソッドをオーバーライドして使用するなどができてしまいます。

ところが、コードレビューで、このようなコードを見かけたときに、「継承を前提とした設計なのですか？」と聞くと、「継承されることは想定していません」という返事が返ってくることがあります。Java言語では、継承できないように書くには、さらにクラスをfinal宣言するとかprivateのコンストラクタだけにするとかの手間をかけないといけないため、意図せずに継承可能なクラスを書いてしまうことが多いです。

しかし、継承される前提の設計でなければ、そもそも継承できないように書くべきです。コードレビューでは、その点を注意しなければなりません。特に、公開APIとなるようなクラスでは、なおさら注意する必要があります。

コードレビューの視点 014

可視性に注意する

プログラミング言語の多くは、モジュール化を行うための何らかの言語仕様上の仕組みを持っています。たとえば、Java言語やGo言語であればパッケージ（package）をまとまりとして扱います。APIの観点で言えば、パッケージ外に公開されるのか、パッケージ内に隠蔽されるのかという違いとなります。

Java言語では、何らかのIDEを使用している人がほとんどだと思います。その結果、新たなクラスを作成する場合、デフォルトではpublicと宣言されたクラスが生成されたりします。

コードをレビューしてよく指摘するのは、「このクラスはパッケージ外から使用されることを想定しているのですか」ということです。つまり、「クラスをpublicと宣言しているのですから、外部から使用するという設計ですよね」という質問になります。

しかし、「パッケージ外から使用されることは想定していません」と回答されることがあります。パッケージ外からの使用を想定していないのであれば、そもそも、使用できないように最初から書いておくべきなのです。

可視性に注意することは、クラス宣言だけでなく、メソッド宣言にも適用されます。public宣言されたクラスだからといって、すべてのメソッドがpublicというクラスは少ないはずです。

コードレビューでは、設計上の意図がきちんと反映されているかを確認する必要があります。特に、その意図の記述が使用しているプログラミング言語により可能ならば、きちんとその言語の機能を使用すべきです。その一つが、可視性を正しく記述することです。

JAL工場見学へ行きました

貯めているマイルを使って参加できるJAL工場見学へ6月12日（金）に、妻と二人で行きました。

マイルを使って行ってみよう！JAL工場見学～SKY MUSEUM～

マイルを使った工場見学には、2種類があるようです。

• スタンダードコース（2,000マイル/一人）
• ナイトサファリコース（3,000マイル/一人）

通常の無料のJAL工場見学は、半年先の予約なのですが、このマイルを使用したJAL工場見学は、先着順に予約できます。私も予約したのが5月23日でしたが、約3週間後の6月12日に見学したことになります。

スタンダードコースは、昼間に開催されるもので、無料のJAL工場見学と内容は同じようです。ただ、記念品がもらえます。通常のJAL工場見学の内容は、次の通りです。

【通常/スタンダードコース】

• 展示エリア（30分）
• 航空教室（30分）
• 格納庫見学（40分）

展示エリアもおそらく解説してくれるのではないかと思います。ナイトサファリコースは、内容が少し異なっています。

【ナイトサファリコース】

• 展示エリア（15分）
• 航空教室（30分）
• 格納庫見学（75分）

展示エリアは、自分で勝手に見るだけですので、集合時間である16時45分からの15分間が上記の15分のようです。16時に到着したので、それからすぐに展示会場やショップをゆっくりと見学することができました。つまり、ナイトサファリコースでは、16時頃に行くことをお勧めします。格納庫見学が終わったあとは、展示会場やショップも消灯してしまっていますので。

航空教室が17時から開始され、17時30分から1グループ12名の4グループに分かれて、それぞれのグループは整備士さん2名に引率されて格納庫見学です。予定では75分とありますが、私が行ったときは、90分の見学時間でした。

幸運なことに、政府専用機が整備のために格納庫にあり、目にすることができました。そして、見学が終わる頃には、政府専用機（ジャンボ）の重量を測っていました。

（おそらく、40分の格納庫見学とは異なるのではないかと思いますが）単に見るというのではなく、その夜の国際線の便として実際に使用される767が見学用に準備され、様々なところが開けてありました。預けられた荷物を収納する部分には階段を上がって中を見ることができましたし、車輪の前のカバーや尾翼の付近の下のカバーは開けられいました。そして、単に外から見るだけではなく、その767に乗り込んで、操縦席も見せてもらい、操縦席に座ることもできました。操縦席は、結構窮屈な感じでした。

格納庫全体を回りながら見学するのですが、格納庫の出口では、ひっきりなしに着陸する航空機を目の前でみることもできました。

初めて行ったJAL工場見学でしたが、とても良かったです。必要なマイル数は増えますが、「ナイトサファリコース」がお勧めです。写真撮影に制限は全くありませんでしたが、格納庫見学で撮影した写真は、ブログ、Twitter、Facebookなどでは公開禁止となっています。

展示エリア入り口


歴代のスチュワーデスの制服


記念品とその箱、入館カード、パンフレット

教育と場（まとめ）

過去に書いた記事です。

• 教育と場
• 教育と場（2）
• 教育と場 （3）
• 教育、場、権限

最後の「教育、場、権限」をそのまま抜粋しておきます。

転職してから気づいたことなのですが、私自身のソフトウェア開発の経験をもとに会社の中で若手のエンジニアの成長を後押しするには、次の3つの条件が揃っている必要があります。

• 教育 － 基本的に知っておいてもらいたい事柄を技術教育や勉強会という形式を通して教えてく。
• 場 － 教育で教えたことを、設計レビューやコードレビューなどの日々のソフトウェア開発活動全般を通して指導していく。それにより、教育では伝えきれない部分を伝えていく。
• 権限 － 日々のソフトウェア開発での指導ができる組織上の権限。

教育を受けただけで、日々のソフトウェア開発で実践指導されなければ、身につくことはないかもしれません。教育をすることだけが自分の仕事だと思っている人であれば、教育したという事実で満足するかもしれません。しかし、私自身は、場が与えられなければ教育の効果がないということを感じています。

日々指導するには、ソフトウェアの開発組織ライン上の権限が必要となってきます。たとえば、チームを構成するメンバーでもなくそのチームリーダでもなければ、チームリーダが指導しないことをそのチームのメンバーに指導することは簡単なことではありません。

つまり、若手技術者の育成には、「教育、場、権限」が必要だということになります。そうでなければ、ソフトウェア開発を何年経験していても、中途半端な技術者が増えるだけかもしれません。