『Effective Java 第3版』届きました

正式な発行日は10月30日ですが、見本刷りが出来上がったので、土曜日のお昼に出版社から届きました。

2001年に初版を読んだときは、自分自身の無知を自覚しました。1996年夏からJavaを使っていて、すでに5年も経過しているのに、初版からあまりにも学ぶことが多すぎて、衝撃を受けたものです。

今月末までには書店に並ぶと思います。

Effective Java 第3版

• 作者: Joshua Bloch
• 出版社/メーカー: 丸善出版
• 発売日: 2018/10/30
• メディア: 単行本（ソフトカバー）

clibと呼ばれるライブラリー開発の思い出（５）

前回から一年近くが過ぎてしまいましたので、過去の記事を最初に列挙しておきます。

• clibと呼ばれるライブラリー開発の思い出（１）
• clibと呼ばれるライブラリー開発の思い出（２）
• clibと呼ばれるライブラリー開発の思い出（３）
• clibと呼ばれるライブラリー開発の思い出（４）

スレッドライブラリ

独自に設計したメモリ管理ライブラリに基づいて設計したのが「スレッドライブラリ」でした。主には二つの機能が提供されていました。

• CThread、IRunnable、CSynchronizer、CReaderWriterLockというスレッド生成および同期用のクラス
• スレッドセーフなコレクションクラス（リスト、セットなど）

私の記憶が曖昧になっており、コレクションクラスとして何を準備したのかは記憶が定かではありません。スレッドライブラリのAPI設計では、いくつかの間違いをしました。それらの間違いは、初期のclibでは修正されていません。間違いを修正したのは、2003年から従事したLinuxベースでのソフトウェア開発でです。代表的な間違いは、fail-fast iteratorを仕様に盛り込まなかったことです。そのため、誤ったイテレータの使い方が行われていても気付かない実装になっていました。

今日なら

1993年から2000年にかけてC++を用いたデジタル複合機のコントローラソフトウェア開発で経験したメモリ関連の苦労を反映したのがclibでした。かなりの量のソフトウェアを新規開発しながらも、富士ゼロックス社のデジタル複合機を2000年後半から2年弱で開発できたことに貢献したと思っています。

しかし、今日作り直すとしたら、C/C++ではなくGoで開発すると思います。実際開発しましたし、将来機会があればやはりGoだと思います。

小さなスタックで動作する軽量なゴルーチン、CSP による通信、ガベージコレクタとメモリ保護、構造体によるコンパクトなメモリ設計、オブジェクト指向プログラミング、および、ウェブのクライアントやサーバの機能を含めたさまざまな機能を提供する標準パッケージと、道具は揃っています。したがって、オペレーティングシステムにLinux を採用している組み込みシステムでは、C やC++で開発するのではなく、Go で開発するのが適切だと思っていますし、将来Go で開発されるのが普通になる日がくるのではないかと期待しています。実際、ある組み込みシステムの制御ソフトウェアをGo を使った完全なテスト駆動開発で行うプロジェクトを2 年間にわたり率いて、Go での組み込みシステムの開発が可能なことを実証できました。

『プログラミング言語Go』の「訳者あとがき」より

残念ながら、clibを設計してから10年後にGoは登場しました。

『Effective Java 第3版』で言及されている書籍

Effective Java 第3版

• 作者: Joshua Bloch
• 出版社/メーカー: 丸善出版
• 発売日: 2018/10/30
• メディア: 単行本（ソフトカバー）

『Effective Java 第3版』の本文中で言及されている参考文献には多くの書籍がありますが、最も参照されているのは『The Java Language Specification』です。当然と言えば当然ですが、残念ながら言語仕様は今では翻訳されていませんし、おそらく今後も翻訳されないと思います。

正確に数えた訳ではありませんが、次に多く言及されているのは、やはり『デザインパターン』です。

オブジェクト指向における再利用のためのデザインパターン

• 作者: エリック ガンマ
• 出版社/メーカー: ソフトバンククリエイティブ
• 発売日: 1999/10
• メディア: 単行本

原著は20年以上前に出版されており、古典と言ってもよいかと思います。2000年前後にデザインパターンがブームとなった頃にはさまざまな書籍が出版されてましたが、最近は新刊はほとんどないです。知らなくてもよくなったのではなく、知っておきべき「常識」となったと考えるのが正しいと思います。この本の注意点は、サンプルコードがC++だということです。

次に言及が多いのが次の本です。

Java並行処理プログラミング ―その「基盤」と「最新API」を究める―

• 作者: Brian Goetz
• 出版社/メーカー: ソフトバンククリエイティブ
• 発売日: 2006/11/22
• メディア: 単行本

『Effective Java 第3版』の「第11章 並行性」で言及されています。

次に言及が多いのがJoshua Bloch自身が共著者の一人である『Java Puzzlers』です

Java Puzzlers 罠、落とし穴、コーナーケース

• 作者: ジョシュア・ブロック
• 出版社/メーカー: ピアソン・エデュケーション
• 発売日: 2005/11/14
• メディア: 大型本

2005年に出版されたこの本は、多くのパズルが含まれ、その解説だけでなく「言語設計者への教訓」が書かれています。また、多くの錯視図が含まれており楽しめます。さらに、パズルそのものやそのタイトルには多くの語呂合わせが含まれており、楽しめる技術書となっています。この『Java Puzzlers』は、私が初めて原著の草稿段階からレビューに参加させてもらった書籍です。

「付録A 罠と落とし穴のカタログ」には、Javaでプログラミングを行う上での助言が書かれており、『Effective Java』と共通する助言が多いです。「付録B 錯視に関する説明」では錯視図の説明が書かれています。「付録C 語呂合わせとポップカルチャー参照」は、私がJoshua Blochへ依頼して執筆してもらった付録であり、日本人には分かりにくい本文中のジョークや文化的背景が説明されています。

この本は、2005年に本で開催されたJavaOneで先行発売され、著者のJoshua BlochとNeal Gafterも来日していたので、会場でサインをもらった人もいるのではないかと思います。

初刷が2,500部だけで、すでに絶版となっていますので、『Effective Java』で言及されているパズルを今後紹介していきたいと思います。

通勤電車の書斎化（4）ー スターバックス ー

「通勤電車の書斎化（3）」では、現在の話を書きました。通勤電車と同じように書斎化という点では、出社前のスターバックスも重要なので、その話をします。

どの会社に勤めていても、通勤電車の書斎化は行うのですが、会社がフレックス勤務ではない場合、会社の最寄り駅に到着しても出社せずに、そのままスターバックス（あるいはマクドナルド）に行きます。

2009年8月末に富士ゼロックス情報システムを退職するまではフレックス勤務でした。勤務場所も遠くなかったので、朝は自宅で翻訳作業をすることが多かったです。2009年9月にリコーへ転職してからはフレックス勤務ではありませんでした。

最初は大森事業所でしたので、最寄り駅の「荏原町駅」にあるマクドナルドで珈琲を飲みながら翻訳作業をしてから出社していました。

その後、海老名へ転勤になったので、海老名のビナウォークにあるスターバックスの「海老名店」に寄って出社まで作業をしていました。いつも、ドリップコーヒーしか飲まないので、作業を終えて店を出る前にお替わりのコーヒー（100円）をタンブラーに入れてもらって出社していました。海老名店は、朝は混んでいないのですが、昼間や夕方はいつも混んでいます。

海老名店から見たビナウォーク

2015年の暮れから新横浜事業所になったのですが、新横浜では横浜アリーナに近いスターバックスの「新横浜三丁目店」に寄っていました。ここは、次の点で穴場のお店でした。

• 横浜アリーナでイベントないときは、昼間や休日でも比較的空いている
• 新たなスターバックスカードが即日でなくなることがなく、入手しやすい

昨年の9月からソラミツに勤務し始めてからは、会社が麹町（今は神宮前）でしたので、「麹町店」を利用していました。

麹町店

そして、今のメルペイはフレックス勤務なので、スターバックスに寄ることなく出社しています。

最近は、一冊の本を仕上げるのに400時間以上を要しています。

• 『Effective Java 第3版』（432時間）
• 『ベタープログラマ』（521時間）
• 『プログラミング言語Go』（474時間）

私の場合、翻訳作業が休みの日にはかどることはあまりなく（集中が続きません）、どうしても平日での時間の積み上げが必要になってくるため、通勤電車やスターバックスで時間を捻出して作業する必要があります。

API仕様を書く（7）

（「API仕様を書く（6）ー gRPC protoファイル（2） ー」からの続き）

きちんとしたAPI仕様を書いていない場合、そのAPIのテストコードは当然のことながら、正常ケースだけだったり、不正なパラメータが渡されたときにどのように振る舞うかは実装のソースコードを見ないと分からなかったりします。さらに、「エラー翻訳」（「例外翻訳」）を行っていない実装は、いつのまにか返されるエラーが変わってしまっていることも起こり得ます。

おそらく多くの大学ではAPI仕様の書き方も含めてAPI設計の教育は行われていないと思います。そして、社会人となってから、個々のソフトウェアエンジニアがAPIの仕様をどの程度記述するかは、その人が属したソフトウェア開発組織の文化に影響を受けると思います。

私自身、gRPCを用いたソフトウェア開発では、前職のソラミツが初めてでした。そこでは、protoファイルには何も仕様が書かれていない理由は、それが大学の学生が作成したものだからだと思っていました。しかし、それは学生が書いたからではなく、そもそもAPI仕様を書くことを行ったことがない人達が書いたものだったからです。つまり、企業でソフトウェア開発をしているソフトウェアエンジニアであっても、仕様を書かない人が圧倒的に多いのではないかということです。

リコーに勤務していた頃は、さまざまなAPIをレビューしましたが、やはりきちんと書いてこないソフトウェアエンジニアが圧倒的に多かったです。その中でも、NDAを結んだサードパーティへ提供するAPIなのに、これはないだろうとう不完全なAPIが多くありました。

不備が多いAPI仕様は、不具合が多いAPI実装を生み出し、そして、サードパーティから問い合わせが多くなり、結果として長期的な開発コストを増加させます。これは、サードパーティへ提供するソフトウェアではなくても、会社内で閉じているソフトウェアでも、長期的な開発コストを増加させる結果となります。

マイケル・C・フェザーズの言葉を置き換えると次のようになるかと思います（「ネーミング」を「API仕様」と読み替えてます）（『レガシーコード改善ガイド』）。

API仕様は設計の中心である。優れたAPI仕様はシステムの理解を助け、作業を容易にする。しかし、貧弱なAPI仕様はシステムの理解を妨げ、後でシステムを扱うプログラマに辛い日々を送らせる。

（おわり）

API仕様を書く（6）ー gRPC protoファイル（2） ー

（「API仕様を書く（5）ー gRPC protoファイル ー」からの続き）

gRPCから返すコードについては、Go言語用のこちらの定義が分かりやすいです。個々のコードは定義を読めば使い方は分かるかと思います。

API仕様には、gRPCで提供するサービスが提供する機能に応じて、どのような場合にどのコードが返されるかを書く必要があります。ただし、UnknownとInternalに関しては注意が必要です。

Go言語のgRPC用のミドルウェアでは、statusパッケージ※1を使わずに生成したerrorを返すと、コードとしてUnknownが返されます。たとえば、DBへのアクセスして返されたerrorをそのままRPCのerrorとして返すと、コードはUnknownとなります。つまり、Unknownとは適切にコードが指定されなかったことを意味します。RPCが提供する機能に対する適切なコードを返すためには、「エラー翻訳」（Javaで言うところの「例外翻訳」※）を行う必要があります。適切なエラー翻訳を行うためには、RPCが提供する機能に対して概念的に正しいコードを仕様に定義する必要があります。
※1 google.golang.org/grpc/status
※2 『Effective Java 第3版』の「項目 73 抽象概念に適した例外をスローする」

返すコードとしてのでInternalは、呼び出した側の問題ではなく、呼び出された側の何らかの不変式（invariant）が成立していないときに返します。言い換えると、設計上のバグと考えられるものはInternalを返すことになります。Java言語で言えばAssertionErrorが明示的にスローされるような場合です（『API設計の基礎』の「第3章 防御的プログラミング」）。

UnknownとInternalは、どのRPCでも返される可能性があるので、個別のRPCの説明（前の記事の③）に書く必要はなく、サービス全体の説明（前の記事の①）に書けばよいと思います。どちらも、「呼び出し側の問題ではなく、呼び出された側の実装の問題なので、開発者への報告を求める」の旨が書かれていればよいかと思います。

（続き）

『Effective Java 第3版』

Effective Java 第3版

• 作者: Joshua Bloch
• 出版社/メーカー: 丸善出版
• 発売日: 2018/10/30
• メディア: 単行本（ソフトカバー）

私にとって17冊目の翻訳本になる『Effective Java 第3版』が今月末には書店に並びます。第2版がちょうど10年前です。第2版は、ジェネリックスを含めた大きな言語仕様の変更がJava 5で行われた後でした。今回は、Java 8でラムダとストリームという言語仕様の変更とライブラリの拡張が行われた後となります。

新たに追加された項目は以下の通りです（項目番号は、第3版の番号です）。

• 項目9 try-finally よりもtry-with-resources を選ぶ
• 項目21 将来のためにインタフェースを設計する
• 項目25 ソースファイルを単一のトップレベルのクラスに限定する
• 項目32 ジェネリックスと可変長引数を注意して組み合わせる
• 項目43 ラムダよりもメソッド参照を選ぶ
• 項目44 標準の関数型インタフェースを使う
• 項目45 ストリームを注意して使う
• 項目46 ストリームで副作用のない関数を選ぶ
• 項目47 戻り値型としてStream よりもCollection を選ぶ
• 項目48 ストリームを並列化するときは注意を払う
• 項目55 オプショナルを注意して返す
• 項目85 Java のシリアライズよりも代替手段を選ぶ

第2版にあった「項目73 スレッドグループを避ける」は引退して削除されています。
既存の項目も見直しが行われています。

今回も翻訳作業を通して原著の間違いを多く発見し、その多くは英版版の4th printingで修正されています。