テストファースト開発（2）

以前、「テストファースト開発」と題して、当時どのように開発していたかを書いています。その中で開発のフローについて、次のように書いています。各ステップの解説については、前述のブログを読んでください。

1. 既存のAPIの仕様の記述の変更、もしくは、新たなAPIの仕様の記述
2. 既存のAPIの実装の調査（新たなAPIの場合には似たAPIの実装の調査）
3. テストコードの作成
4. 機能の実装
5. リファクタリング

今週は、あるマイクロサービスの機能の一部を別のマイクロサービスへ移行する作業をしました。機能そのものは小さかったのですが、実際に行ったことは、次の通りです。

API仕様の確認

最初に、API仕様、つまりgRPCの.protoに書かれているrpcの仕様を確認しました。仕様を読んで、疑問に思うことが何点かありました。つまり、仕様から読み取れない振る舞いがあった訳です。それで、既存の実装コードを調べたり、既存のe2eテストを修正して試したりして、不明な振る舞いの動作を確認しました。

確認した内容のすべてをもとの.protoファイルに記述するPR（Pull Request）を作成し、もとの開発者にレビューをお願いしました。私が調査から読み取れていなかった点の指摘があったので、指摘点を修正して、PRをapproveしてもらい、マージしました。.protoファイル内にコメントして記述されている仕様の修正なので、特に実装の変更はありません。

テストコードの作成

もとのマイクロサービスにあったe2eテストを参考に、修正されたAPI仕様に書かれていることをすべて網羅するのを確認しながら、新たなe2eテストを作成して、すべてのテストが失敗するのを確認しました。

実装

テストが合格するように順次実装していくのですが、まだ実装していない箇所にコードが到達した場合には、panicするかUnimplementedエラーを返すようにコードを入れながら実装していきます。テストがすべて合格するまで、実装を行っていきます。

すべてのテストが合格したら、テストによって実際に実行されたコードをカバレッジで確認します。ここで重要なのは、カバレッジのパーセントではなく、実装したコードがすべて実行されたかです。私個人としては、「開発者はカバレッジのパーセントではなく、実行されたコードを確認することが重要」と思っています。

確認してみると、実際に起きたらInternalエラーになるコードが実行されていないことが判明しました。Internalエラーは、設計上想定していないことが起きていることを意味しますので、そのエラーをテストで起こせるかどうかは、内容次第となります。今回は、テストコードで起こせるものだったので、追加のテストコードを作成しました。

この追加のテストコードは、すでに実装が書かれているので、合格するテストを最初から書いてしまうと単に合格してしまいます。それでは該当コードが実行されたことによって合格しているのか、それとは別の理由で合格しているのか分からなくなってします。それで、わざと（正しくはない）合格しないテストを書いて、失敗することを確認してから、正しいテストへ修正して、合格することを確認しました。

最後にカバレッジで実行された実装コードを確認して、実装作業は終了です。

コードを見直して、とくにリファクタリングは必要ないと判断し、PRをレビューに出しました。

20冊目の技術書の翻訳の状況

私にとって通算20冊目となる技術書の翻訳本ですが、早ければ今週中に出版社での組版が終わった初校が上がってきそうです。初校のPDFが送られてくたら、私の方で10日ほどでチェックすることになります。

一年で2冊出すのはあまりないのですが、今年3月に出版した19冊目の『スーパーユーザーなら知っておくべきLinuxシステムの仕組み』と比べると、20冊目はページ数も少なくコードも多いので、翻訳に要した時間は、19冊目の1/3程度となっています。

メルペイで4年が過ぎました

ソラミツを退職して、メルペイに入社したのが、2018年6月1日でした。ちょうど4年前です。

入社前の面談で、週4日勤務（金曜日は休み）を希望したのですが、雇用形態としてはそのような制度はないということで、正社員として採用されました。ただし、金曜日は欠勤としたり、有給休暇を使ったりして休んでよいということで、入社しました。メルペイのサービスを最初にリリースする前の2か月ほどは、金曜日に働いたことはありますが、それ以外は金曜日は欠勤か有給休暇で休んでいます（欠勤すると所定労働時間に達しないので、不足分は給与が減額されます）。

技術教育と技術書の翻訳

金曜日は、主に複業としての技術教育（Java言語教育やGo言語教育）や技術書の翻訳などを行ってきました。もちろん、単に休むこともあります。副業としてのソフトウェア開発を行っているエンジニアも多いですが、ソフトウェア開発は締め切りがあったり、デバッグがいつ終わるか予想できないことがあるので、私は行わないようにしています。

Go言語教育では、古川陽介さんと和田卓人さんが受講してくれました。古川さんは、彼が社会人になった頃からの知り合いですが、和田さんとも知り合えたのがよかったです。

技術書の翻訳も以下の4冊を行えています。4冊目（Go言語による分散サービスに関する書籍）はまだ発売されていませんが、4月末には私の作業は終わっており、現在出版社による組版を待っています。

• Effective Java 第3版
• 新世代Javaプログラミングガイド
• スーパーユーザーなら知っておくべきLinuxシステムの仕組み
• タイトル未定（2022年夏発売予定）

メルペイでの活動

メルペイでは、Backendのソフトウェアエンジニアとして、マイクロサービスの開発に従事してきました。1984年4月に社会人になってから、主にワークステーション開発とデジタル複合機の組み込みシステムの開発を行ってきており、ウェブサービスの開発に本格的に従事したのはメルペイが初めてでした。Kubernetesについては、書籍『Kubernetes in Action』で独学しながらの開発でした。

マイクロサービスの開発を通しての成果として、いくつかのTech Blogを書いています。また、GDG DevFest Tokyo 2019やJaSST'19 Tokaiで登壇して、マイクロサービスでのテスト駆動開発について話しました。

今後

現在の私の年齢は62歳6か月であり、65歳までにあと2年半となりました。今後もソフトウェア開発に従事しながら、複業を続けていきたいと考えています。

伸ばすのが難しい能力

2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。

ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。

• 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない
• テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない
• Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない

API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書き方」としてmerpay Tech Talkで話しています。

実装を一切書かずに、きちんとAPI仕様を書けないと、おそらくテストファースト開発もできないと思います。色々な人達とソフトウェア開発を行った経験から、この二つは、かなり密接に関連しているのではないかと思っています。

残念ながら、上記の三つは、プログラミングを覚える際に習うことはないため、身に付かないまま年数を経ている開発者が多いと思います。では、どうやったら身に付くかというと、上記の三つを伸ばすための活動をきちんと行っている開発組織で働くことです。そうでなければ、たいていは無理ではないかと思います。もちろん、個人で身に付ける人はいるとは思いますが、継続したレビューで指導してくれる人達がいないと、多くの人にとってはなかなか難しいでしょう。

しかし、そのような開発組織を見つけるのは、容易ではありません。多くの企業は、使っている技術や組織の文化とかは盛んにアピールします。しかし、上記の三つの能力育成活動をきちんと行っている組織はもともと少なく、その上で外に向けてアピールする企業はほとんどないからです。さらに、きちんと行っている組織は、そうするのが当たり前だと考えられていて、わざわざ当たり前と思うことを外に向けて発信することはないと思います。

昭和大学藤が丘病院、お世話になりました

2020年6月20日（土）に急性心筋梗塞で救急搬送されて以来、お世話になっていた昭和大学藤が丘病院ですが、今日が最後になりました。今後は、特に問題がなければ、通院することはありません。今月16日に受けた心臓超音波検査の結果も一年前と比べても良好でした。

今では、急性心筋梗塞になる前よりは、健康になっていると言えます。血液検査の各種の値も正常値ですし、長年の脂肪肝も前回の人間ドックから見られなくなりました。毎日飲んでいる各種の薬、日々の食事制限、ほぼ毎日の自宅でのエアロバイクのおかげだと言えます。

救急搬送されたときの緊急手術から、武井洋介 先生には大変お世話になり、ありがとうございました。また、10か月間の心臓リハビリテーションを行った昭和大学藤が丘病院リハビリテーションにもお世話になりました。

最後に、私の妻、惠美子にも感謝しています。食事のコントロールをずっと行ってくれて、いろいろと支えてくれています。

翻訳する技術書の選択

以前から聞かれる質問に、「翻訳する技術書はどのように決まるのですか」というのがあります。どのように決まるかは、次の二つのパターンに分かれます（一度翻訳した本の改訂版は別として、新たな技術書の翻訳の場合です）。

• 出版社が翻訳する技術書を選定して、その翻訳を依頼される
• 私が翻訳したいと思う技術書を、出版社へ打診する

今まで19冊を出版していますが、一度翻訳した本の改訂版を除くと、出版社からの依頼が7冊、私から出版社に打診して翻訳したのが9冊です。

私から打診した本がすべて採用される訳ではなく、以下の理由でダメな場合があります。

• 翻訳しても売れそうにないと判断される
• 実はすでに翻訳が進行中である
• （まれですが）翻訳されることを、著者が許可していない

ちなみに、19冊目の『Linuxシステムの仕組み』は、私から出版社へ打診した本です。そして、今年の夏に出版予定の20冊目は、出版社から依頼された本です。

最近、予約注文した専門書

読みかけの専門書もまだ多くあるのです、新たに以下の3冊を予約注文しました。

Code: The Hidden Language of Computer Hardware and Software

• 作者: Petzold, Charles
• 出版社/メーカー: Microsoft Press
• 発売日: 2022/08/19
• メディア: ペーパーバック

第2版ということで、どのような内容になっているのか楽しみ。

API Design Patterns: Simplify Your Remote Service Interface (Addison-Wesley Signature Series (Vernon))

• 出版社/メーカー: Addison-Wesley Professional
• 発売日: 2022/09/16
• メディア: ペーパーバック

API Design Patternsというタイトルに惹かれて。

Tour of C++, A (C++ In-Depth Series)

• 作者: Stroustrup, Bjarne
• 出版社/メーカー: Addison-Wesley Professional
• 発売日: 2022/10/10
• メディア: ペーパーバック

私のC++に関する知識は2009年で止まっているので、C++を学び直したいと思い。

『Effective Java 第3版』オンライン読書会を終了します

Effective Java 第3版

• 出版社/メーカー: 丸善出版
• 発売日: 2021/07/13
• メディア: Kindle版

2020年6月から月に1回、土曜日の午後（13:00〜17:00）に開催してきました『Effective Java 第3版』オンライン読書会は、第2サイクルの途中でしたが、参加者が少ないため終了することにしました。

読みながら、難しい箇所を説明しながらの読書会でしたが、第2サイクルは参加者が当初から少なく、第1サイクルを参加した人で、第2サイクルにも参加している人だけがいつも参加される読書会になってしまいました。したがって、終了することにしました。

『Effective Java 第3版』をきちんと理解するには、Javaに関する多くの基礎知識を必要とします。また、本文中にコードを示しての説明もありますが、コードだけでは理解するのが難しい場合、簡単な図を書いて説明することも必要です。また、文章による説明が多いため、図を書いたり、簡単なサンプルコードを示したりもしました。

オンライン開催なので、日本のどこからも参加可能でしたが、残念ながら私が主催している他のオンライン読書会と比較すると、参加者が少なかったのは残念です。

今のところ、第3サイクルは予定していません。

正誤表『Linuxシステムの仕組み』

スーパーユーザーなら知っておくべきLinuxシステムの仕組み

• 出版社/メーカー: インプレス
• 発売日: 2022/03/08
• メディア: 単行本（ソフトカバー）

『Linuxシステムの仕組み』の正誤表のページを追加しました。

https://yoshikishibata.github.io/

「正誤表」のタブから参照してください。

訳者あとがき『Linuxシステムの仕組み』

スーパーユーザーなら知っておくべきLinuxシステムの仕組み

• 出版社/メーカー: インプレス
• 発売日: 2022/03/08
• メディア: 単行本（ソフトカバー）

Linuxは、組み込みシステムからウェブサービスまで多くのシステムで使われています。そのため、ソフトウェア開発では、避けて通れないオペレーティングシステムになっています。今日では、ウェブサービスの多くがLinuxに基づくコンテナ技術に依存しており、開発マシンとして使っていなくても、間接的にLinuxを使っていることになります。

この本は、Linuxを使う上で知っておくべき知識を説明しています。この本で説明されている以上の詳細を知りたい場合、各章で紹介されている書籍やマニュアルページでさらに学ばれるとよいかと思います。Linuxカーネル内の仕組みについては、それだけで一冊の本になってしまうので、詳細には説明されていません。カーネルの仕組みに興味があれば、カーネルを解説した書籍を読まれることをお勧めします。

私自身は、1984年に社会人として働き始めてから、BSD 4.2/4.3、Idris、System V、SunOS、SolarisとさまざまなUnixを開発用としてだけではなく、製品のオペレーティングシステムとして使いました。Linuxも二つの組み込みシステムの開発で使いました。今日では、ソフトウェア開発にはUnixの系統の一つであるmacOSを使ってウェブサービスを開発しています。そのウェブサービスもクラウドのプラットフォーム上のKubernetes（17.2.4節）を使っています。また、Windowsであっても、WSL（Windows Subsystem for Linux）を使うことができます。その結果として、今日では、さまざまなプラットフォーム上で、Linuxを含むUnix系統のオペレーティングシステムやコマンドを使うことができます。

私がUnixを使い始めた頃は、Unixの機能は限られていました。たとえば、スレッド、共有ライブラリ、mmapシステムコール、TCP/IPのプロトコルスタックといったものはなく、プロセス間通信はfork/execした親プロセスと子プロセス間でのパイプだけでした。その後、さまざまな機能が追加されて、Linuxにも引き継がれています。一方で、30年以上慣れ親しんだUnixのコマンドは、現在でもその多くがソフトウェア開発で役立っています。Linuxの機能は拡張され続けていきますが、この本で説明されている基本的な事柄は、その多くが陳腐化することはないと思います。そして、皆さんのソフトウェア開発で役立ち続けると思います。

多くのソフトウェアエンジニアにとって、この翻訳本が日々のソフトウェア開発を支える知識の獲得に役立てば幸いです。