Let's Swagger

Let's Swagger

社内勉強会で使用した資料をはてな用にアレンジしたものです。

Goals

  • Swaggerって何か聞かれて答えられる程度の知識をみにつける
  • 具体的に何ができるのか、HowとWhatを知る

つゆばらい

  • 序盤英語です
    • 翻訳が面倒でした。ごめんなさい
    • 英語見ると蕁麻疹出ちゃう人はよそ見しててください
      • でも、英語できないとエンジニア人生かなり辛いです
  • Swaggerを使う準備として調べてみたことを発表しています

  • ってことは、私自身の実績はないですありませんでした

    • でも、参画中のプロジェクトでは使われています使ってると言える程度に関わるようになりました
  • 自分自身のために勉強したことを発表用に仕立て直してます

    • そのため、興味の対象が偏ってるかもしれません

What's Swagger ?

Ansower quoted from official Site

The World's most popular Api tooling.

Swagger is the world’s largest framework of API developer tools for the OpenAPI Specification(OAS), enabling development across the entire API lifecycle, from design and documentation, to test and deployment.

  • 要約すると(RESTful)APIの設計、文書化、テスト、開発を網羅した世界最大のフレームワークって書いてある
構成要素
  • DESIGN : Swagger Editor
  • BUILD : Swagger Codegen
  • DOCUMENT : Swagger UI

DESIGN (with Swagger Editor)

Design new APIs, or edit existing ones, in a powerful editor which visually renders your OAS/Swagger definition with concise, real time feedback and error handling.

  • 要はAPIの設計をエディター上でパワフルにやれるって書いてある

demo -> https://editor.swagger.io

BUILD (with Swagger Codegen)

Quickly build APIs by turning your OAS/Swagger definition into code, generating server stubs and client libraries in over 40 different languages, allowing for development and prototyping.

  • 要約すると定義ファイルからコード生成できるよって書いてある
# demo
$ swagger-codegen generate \
-i http://petstore.swagger.io/v2/swagger.json \
-l nodejs-server \
-o ./ist-swagger-demo
$ cd ist-swagger-demo
$ tree .
.
├── README.md
├── api
│   └── swagger.yaml
├── controllers
│   ├── Pet.js
│   ├── Store.js
│   └── User.js
├── index.js
├── package.json
├── service
│   ├── PetService.js
│   ├── StoreService.js
│   └── UserService.js
└── utils
    └── writer.js
$ npm install
$ node .

DOCUMENT (with Swagger UI)

Visualize your API's resources from its OAS/Swagger definition and generate beautiful, interactive documentation that can be hosted in any environment, allowing your end consumers to easily get started with your API.

  • 要約すると定義ファイルから綺麗な仕様書生成するよって書いてある
# Continuing the previous, execute followings
$ npm install
$ node .
# then, go to http://localhost:8080/docs/

なぜSwaggerを使うのか

その1:API仕様書を元にコード化できるから

  • YAML/JSONで仕様書が書ける
  • API定義ファイルから
    • 多数の言語のクライアントコードなどが生成できる
    • サーバもさくっと作れる
      • mockとして使うもよし、ベースに使ってもよし
  • トップダウン形式というらしい

その2:コードからでもAPI仕様書の自動生成ができるから

その3:デファクタスタンダードだから

  • まだなってない気がするけど、たぶんなる、たぶん…。
  • フォーマットについて、一度学習すれば他の現場他の案件でも同じ
  • そのフォーマットを見慣れることになるので、見落としが減る

今回はボトムアップ形式について見てみましょう

  • サンプルアプリを作ってみた
    • SpringFoxを適用して、Swagger Spec自動生成
    • からのSwagger-UIで仕様書の出来栄えを見ていく

デモ用サンプルアプリ

git clone https://github.com/kogayushi/swagger-demo.git

どんなアプリか

Identity Manager

  • ID認証して認証情報を返すだけの簡単なお仕事

Framework

  • Spring Boot

Protocol

とりあえず、完成したSwagger-UIを見てください

$ cd swagger-demo
$ ./gradlew bootRun
# go to http://localhost:8080/swagger-ui.html

git commit logを追います

Swagger用アノテーションなしのプレーンな状態からアノテーションを張っていくごとに徐々に育っていく様子にご注目ください

https://github.com/kogayushi/swagger-demo

Step 1

  • Apply Spring Fox for swagger
変更点

f:id:kogayushi:20180413233949p:plain

Swagger UI

f:id:kogayushi:20180413234008p:plain

ダメなところ
  1. リクエストパラメーターがわかりにくい
  2. レスポンスパラメーターがわかりにくい
  3. formパラメーターでは具体的に何を送るべきかわからない 4.サンプル値がない 5.model見ると全部optionalってありえない 6.定義してない4XX Http Statusがならんでる
  4. 401/403は使ってない
  5. 5XX Http Statusがない
    • ありえない
  6. 少なくとも予期せぬエラーで500は絶対に返すことある

Step 2

  • Declare input variable as to be independen from form data
  • 独立した項目として入力値を定義する
変更点

f:id:kogayushi:20180413234026p:plain

Swagger UI

f:id:kogayushi:20180413234039p:plain

Step 3

  • Disable default response definition
  • デフォルトレスポンスの定義を消す
変更点

f:id:kogayushi:20180413234050p:plain

Swagger UI

f:id:kogayushi:20180413234102p:plain

Step 4

  • Declare proper response http status
  • 返す可能性のあるHttp Statusを正しく定義する
変更点

f:id:kogayushi:20180413234112p:plain

Swagger UI

f:id:kogayushi:20180413234147p:plain

Step 5

変更点

f:id:kogayushi:20180413234202p:plain f:id:kogayushi:20180413234209p:plain

Swagger UI

f:id:kogayushi:20180413234225p:plain f:id:kogayushi:20180413234231p:plain f:id:kogayushi:20180413234238p:plain

Step 6

  • Add descriptive annotation of Swagger into Error response DTO classes.
  • Swaggerの記述用アノテーションをエラーレスポンスのDTOクラスに付与する
変更点

f:id:kogayushi:20180413234309p:plain f:id:kogayushi:20180413234315p:plain

Swagger UI

f:id:kogayushi:20180413234325p:plain

課題

  • エラーレスポンスの例が全てのHttp Statusでおなじになってしまっている
  • エラーレスポンスの定義を全てのコントローラーで定義しなければならなさそう

終わりに

このようにアノテーションを張っていくだけで仕様書が出来上がってしまうというすぐれものです。 みなさんも、ぜひご活用ください。

キャリアアップに必要な物量(勉強時間)について真剣に考えてみた

キャリアアップに必要な物量(勉強時間)について真剣に考えてみた

社内ブログの記事を個人ブログ用に修正したものです。


私の経歴

  • 2009/4に医療系のSIerに新卒入社
  • 2014/7に人材派遣業の会社に転職し、派遣されて某大手ECサイトの会社へ。Webエンジニアへのキャリアチェンジ。
  • 2017/1に今の会社に入社

キャリアチェンジ時に考えていたこと

Web業界は初めてで現時点では実力も実績もない この業界でキャリアアップするためには、ひたすら努力(勉強)することしか思いつかない それ以外に能力を上げる方法があるとも思えないし… と思って勉強命で頑張ってきました


転職したあとから思った

でも、、、 いったいどれくらい勉強すればいいんだろうね?

そんなの人それぞれだと思うけど、 なんか定量的で納得感のある数字が欲しい


みなさんは一ヶ月にどれくらい勉強してるのでしょう?

  • 0時間(一切してない)
  • 5時間~
  • 10時間~
  • 20時間~
  • もっと(20時間以上)

平均は?

Paizaが行ったアンケートによると 週に5時間以上(月20時間以上)らしいです

じゃあ、その人達の先を行こうと思ったら、 何時間勉強すればいいんでしょう?


少し話がそれます


ランチェスター法則(戦略)ってご存知ですか?

Wikiより

ランチェスターの法則ランチェスターのほうそく、英:Lanchester‘s laws)とは1914年にフレデリック・ランチェスターによって発表されたオペレーションズ・リサーチにおける戦闘の数理モデルである。


第一法則

※読まなくていいです

ランチェスターの第1法則はいくつかの前提に基づいた場合にだけ適合する一次方程式の戦闘モデルである。ランチェスターの理論でその前提は次のように整理される。 1.両軍は相互に射撃を行うが、互いに相手の部隊の全てを有効な射程に収めている。 2.両軍の部隊の戦力は兵員と武器の性能によって同様に決まっているが、両軍の部隊が発揮できる戦闘効果は異なっている。 3.両軍とも相手が展開している地点の情報を持たない。したがって、射撃の効果がどれほど得られるか不明なまま戦場の全体に対して射撃を行なう。 4.両軍とも戦闘において残存する両軍の部隊は展開しているが、その部隊の配置は決して形式的に定まることはない。 このような前提を踏まえれば、狭隘な地形において対峙している一対一の戦闘部隊による戦闘をモデル化したものと見做すこともできる。このモデルはいくつかの要因を含んだ次のような方程式として示すことができる。


第二法則

※これも読まなくていいです

ランチェスターの第2法則は二次方程式を用いた戦闘モデルを示したものであり、ランチェスターは既に述べた第1法則の前提のうち1と2については同じように導入しながらも二つの異なる前提を設けて理論を構築している。 1.戦闘において残存している部隊は互いにあらゆる時点で相手の部隊が配置されている地点についての情報を持つ。 2.戦闘における両軍の部隊の射撃は相互に相手の残存する部隊に均等に分配する。 省略した2つの前提を含む第2法則の4つの諸前提は各部隊が敵情について正確に把握し、かつ相手に対して無駄のない適切な射撃が可能であることを示している。この戦闘モデルを調べると、第1法則で示された戦果に対して興味深い相違点が認められる。


(゚Д゚)ワケワカラン…

きっとみなさん、今こんな顔


小難しいことは置いといて…

要するに弱者が強者に勝つ、あるいは強者よりも優位に立つ(差別化する)ための戦略のことを指すらしい これ、勝ちに行きたい(稼ぎたい)ITエンジニアにも当てはめることできるんじゃなかろうか

よし、じゃあ具体的に当てはめて考えよう そして、他を蹴落として優秀なエンジニアになって高収入になってウハウハしよう! と、私は考えました


と思って具体的に考えてみた

ランチェスター法則には 攻撃力=(兵力)^2×(武器性能) という計算式があるらしい

これを経営に置き換えると 経営(人生)=素質×(時間)^2+過去の実績 となるらしい


さっきの勉強時間に当てはめると式はこうなるんじゃね?

エンジニアだと 能力(単価)=素質×(勉強時間)^2+過去の実績 こうなる(たぶんね)


おk,能力値の求め方はわかった

能力(単価)=素質×勉強時間^2+過去の実績 の式だと、素質と実績は定数 となると、変えることができるのは勉強時間だけ

さて、、、 人と同じかそれ以上の能力(単価)にするには何時間勉強すればいいのか、まだわかんないんだけど…?


また別の頭の良い人はこうもいいました

コロンビア大学のバーナード・O・コープマンが他の人よりどれくらい働けば成果が出せるのかシミュレーションしたそうです その結果によると才能が並か劣った人でも…

  • 人の2倍で他の人と同等の成果がだせるようになり
  • 人の3倍で大体勝てるようになり
  • 人の4倍で圧勝できるレベルになる

なるほど

  • 人の2倍勉強したら並
  • 人の3倍勉強したら優秀(単価100万とか?)
  • 人の4倍勉強したら神(単価130万とか?)

ってことか( ゚д゚ )クワッ!!


必要な勉強時間はどうなった?

能力=素質×勉強時間2+過去の実績 で、『勉強時間』は乗数だから 人の2倍とは√2で1.414倍 人の3倍とは√3で1.732倍 人の4倍とは√4で2倍 すればいいってことになる


つまり

人の2倍=20h × 1.414 = 約28h 人の3倍=20h × 1.732 = 約35h 人の4倍=20h × 2 = 40h


結論

人より劣っていると思うなら とりあえず月に28時間勉強してみましょう 人より秀でたいと思うなら 月に35時間勉強しましょう 単価130万もらってウハウハになりたいなら 月に40時間勉強しましょう


ただ、体感的には…

そんなに周りの人勉強してない気がする アンケートはpaizaなので勉強家ばかりのデータ 業界全体で平均とると、10時間未満とかな気がする 人の2倍=10h × 1.414 = 約14h 人の3倍=10h × 1.732 = 約17h 人の4倍=10h × 2 = 20h じゃないかなぁ。 誰か業界全体で平均とってみてほしい。


続きがありまして…

バーナード・O・コープマン氏によると

成功するにはこれを10-15年続ければいいそうです

コツコツ頑張りましょう!


ちなみに私の勉強時間は?

f:id:kogayushi:20180317141716p:plain 記録をつけ始めた(勉強本気になった)のは2015/1/1からです。 2017/03/31時点での総計勉強時間は984時間のようですね。

984/((12*2)+2)=約37h

圧勝する(単価130万以上)になるにはこのペースのままで あと最低でも8年頑張る必要がありそうです ※2017/3/31時点の話

コツコツ頑張ります。

オブジェクト指向プログラミングを学ぶのに適切な書籍と私がおすすめする読む順番

オブジェクト指向プログラミングを学ぶのに適切な書籍と私がおすすめする読む順番

何故かいたか

同僚Aが緑のデザパタ本読んでたり、同僚Bが他の人が読んでる本が気になるっていってたり、後輩Cが会うたびにおすすめの本を聞いてくるので、それらにちなんで、オブジェクト指向プログラミングを習得するためにこの順番でこの本を読むと良いのではないかということを伝えるために、私的な案を考えてみました。

短くまとめてはいますが真剣に考えています。

真剣に考えてみた結果、彼らに伝えて終わりにするのがもったいなくなってしまったのでブログに書いておくことにしました。

オブジェクト指向プログラミングが学べる書籍たち

私が読了済みの本の中から選んでいます。スムーズに理解が進むと思われる順番に並べています。

前提言語はJavaで言語構文にも十分詳しいことが大前提です。

  1. 現場で役立つシステム設計の原則
    • OOPらしさの雰囲気がわかります
    • 入り口に最適です。OOPがどう良くて嬉しいのか、平易でわかりやすく書かれています。
  2. テスト駆動開発
    • OOPらしいコードにたどり着く道筋がなんとなく見えます
    • そういう用途にも使えるというだけで、主題はテストコードです。
  3. リファクタリング
    • 手続き型からOOPらしいコードへ導く道筋のカタログです(リファクタリングが主題の本ですもんね)
    • リファレンスとして手元においておくとよいでしょう。
  4. パターン指向リファクタリング(絶版だが頑張ればまだ手に入る…)
    • さらにもう一歩踏み込んで、落とし所となるデザインパターンへ導く手法を主題にしています。
    • (3)と同じくカタログ化されています。リファレンスとして手元においておくとよいでしょう。
  5. Java言語で学ぶデザインパターン入門
    • (1)から(4)である程度OOPデザインパターンに対する理解が深まっているはずなので、このタイミングでやっとアカデミックにアプローチします。
    • 断片化しているデザインパターンの知識をここで体系的に纏めます。
  6. ドメイン駆動設計
    • ここからOOPを離れていきます
    • OOPをベースに、価値あるソフトウェアを戦術的に・戦略的に構築していく方法論が学べます。
    • いわゆる鈍器です。高いです。しかも抽象的で難解です。覚悟をもって読んで下さい。
  7. 実践ドメイン駆動設計
    • (6)の10年後に出た書籍です。DDDを具体的にコードに落とし込むとどうなるかにフォーカスしています。
    • 相変わらず、鈍器です。高いです。
    • CQRSやイベントソーシングなど技術的な観点が強めに入ってきます。
    • 実装例が出てきますが正解例ではないです。参考にするのはいいですが利用する場合は状況やプロジェクトの嗜好に合わせてアレンジしましょう。
    • これ読んだらもう一度#6読み直したほうが良いです。

その他のおすすめ(未読)

以下の書籍は私もまだ読んでいませんが、レビューなどを見る限りではなかなか良さそうです。これから読みます。

以上。

『今あえてDRY原則に向き合い』のスライドを見て考えるところ

『今あえてDRY原則に向き合う』

https://speakerdeck.com/shinpeim/jin-aetedryyuan-ze-nixiang-kihe-u

はてブ見てて、そうだよね!と共感する記事を見つけたので、私の考えている事と共にシェアします。

スライドの概要

DRY原則ってタイトルにはついてますが、DRY原則を実践するためのノウハウなスライドではないです。

DRY、DRYって言われる理由ってなんだっけ?ただ実践すれば幸せになれるんだっけ?本当にそれだけ考えれば良いんだっけ?と、いろいろな気づきを与えてくれる内容になっていますので、ぜひご一読ください。

私の考えたこと

Fuga原則だとかHogeパターンだとか、良いとされている設計原則やデザインパターンはいろいろありますが、これらはコードを鍛え上げた結果として、共通して現れてくることの多い特徴やパターンに名前をつけただけだと思っています。
※実際に世の中でどういう定義付けがされているかは知りません、私がそう理解し、また実感しているという話です。

つまり、アカデミックに理論を組み立てて作られたというわけではなく、何度もコードが変更されていく過程で、変化に対して柔軟に対応できるソフトウェアにするにはどうしたらよいか、その都度真剣に考えて鍛え上げていく、そういう実践の中で自然発生的に生まれたものなのでしょう。
※実際に世の中で(ry

そうして出来た良いコードにFuga原則だとかHogeパターンだとかという名前をつけてカタログ化することで、私のような凡人エンジニアでもそれを参照し真似することをでき、スキルとして身につけていくことができます。

しかしながら、現実問題としてFuga原則とか1つ2つ知ってるだけじゃ良いコードを書けるスキルなんて身につかないんですよね。

Aな傾向ではこのデザパタ、Bな傾向ではこの原則、Cの傾向ではある原則とデザパタを組み合わせる、といったように引き出しを増やして、組み合わせるスキルを磨いておかないと、何でもかんでも1つか2つの原則・デザパタで解決することになってしまうからです。

解法を1つしか持っていなければ、目の前にある問題に対してその解法でしか解決できないわけですから、そりゃ効率的で変更に強い良いコードなんて書けるわけがありません。
※かくいう私もまだまだ修行中です。頑張ります。

1234を55回足した答えは掛け算を知らなくても足し算で解決できますが、掛け算を知っていれば効率的に解けるのと同じです。『金槌しか持っていなければ、すべての問題は釘に見えてくる』ってやつです。

私は『DRYにしなきゃ』しか考えないエンジニアが書いたコードが○○コードと言われてしまう所以はここにあると思っています。

まとめ

『筋の良い分割とはどういう分割なのか?』らへんに触れることがこのスライドの主題だと思います。その主題に沿ってまとめるならば『筋の良い分割を実践の中で導き出すためには、多くの設計原則とデザインパターンを知っておき、それらが何を解決してくれるのかを理解しておくこと』が重要だと私は考えていると主張しておきます。

読書時の便利グッズご紹介

読書時の便利グッズご紹介

今日は短めのエントリーです。

技術書読むのに使ってる便利グッズをご紹介します。

ブックマーク

f:id:kogayushi:20180120170056j:plain

マーキングクリップをブックマーク代わりに使っています

並行して複数読んでいるとその数だけブックマーク揃えるのお金かかるし、買うのも面倒ですよね?

そこで私は全ての本にこれをつけています。
本を閉じるとき、読み進めたページにつけておくわけです。

ただし、注意点があります。
紙が薄いと挟んでいるカバンの中で他のものに押されたりして、食い込んでページに傷がつくことです。
2頁以上まとめて挟み込むと割りと平気です。

気をつけていても傷がつくので借り物の本には使用しないようにしましょう。

書見台

f:id:kogayushi:20180120170109j:plain

ほんたったが有名だと想いますが、
私はactto BST-02BKを使用しています。

本の角度が細かく調整できる点が良いです。 ほんたったは使ったことがないので断言はできませんが、きっと同じような機能はあると思います。

似たような別のものでも良いので、一つあると写経が捗ります。

デスクライト

f:id:kogayushi:20180120170120j:plain

山田照明 Z-LIGHT Z-108LEDを使っています。

ほしい位置に簡単に光源をセットできるので良いですよ。
私は夫婦ともに読書量が多く、デスクで本を読む時はライトを譲り合いながら使う必要があるのですが、
Z-108LEDは簡単に位置を変えられるので重宝しています。

以上、便利グッズご紹介でした。

新装版リファクタリング感想(第1章だけ)

印象に残った部分のメモを残します。

第1章 リファクタリングー最初の例

メソッドの抽出

page 9より引用

最初に、抜き出そうとする部分でローカルなスコープをもつ変数に着目し、それらが新規に作られるメソッドの一時変数かパラメータにならないか検討します。

ここまで言語かできてないし、全く同じことではないけど似たようなことはやってる!と思った。

条件によって代入する値が変わる場合にswitch文の中でそれをやるコードを良く見る。
しかし、スコープが比較的広く、再代入が可能なローカル変数は値が再代入されるのかを気にしなければならない。
それが嫌なため、該当処理をprivateメソッドや別クラスに括りだすようなことをよくやる。

自分が実践しているテクニックと似たようなものが紹介されていて少しテンションがあがった。

問い合わせによる一時変数の置き換え

page 21より引用

そこで、「問い合わせによる一時変数の置き換え」を適用することにします。

私はいままではオブジェクトから値を取り出すときはパフォーマンスを考慮して一時変数を利用していた。
しかしこの本によるとメソッドから取り出すことがパフォーマンスに影響することをリファクタリング時には気にしすぎなくて良いらしい。
さらには

しかし実際には、コードは適切に分割することで、もっと効率よく最適化できるのです。

とのこと。

実際のコード例はこんな感じ。

Before

            double thisAmount = 0;
            Rental each = (Rental) rentals.nextElement();

            thisAmount = each.getCharge();

            // レンタルポイントを加算
            frequentRenterPoints++;
            // 新作を2日以上借りた場合はボーナスポイント
            if ((each.getMovie().getPriceCode() == Movie.NEW_RELEASE) && each.getDaysRented() > 1)
                frequentRenterPoints++;

            // この貸出に関する数値の表示
            result += "\t" + each.getMovie().getTitle() + "\t" + String.valueOf(thisAmount) + "\t" + "\n";
            totalAmount += thisAmount;

After

            Rental each = (Rental) rentals.nextElement();

            // レンタルポイントを加算
            frequentRenterPoints++;
            // 新作を2日以上借りた場合はボーナスポイント
            if ((each.getMovie().getPriceCode() == Movie.NEW_RELEASE) && each.getDaysRented() > 1)
                frequentRenterPoints++;

            // この貸出に関する数値の表示
            result += "\t" + each.getMovie().getTitle() + "\t" + String.valueOf(each.getCharge()) + "\t" + "\n";
            totalAmount += each.getCharge();

本当に問題にならないかについては業務で試してみようと思う。
パフォーマンステストをちゃんとやる前提で。

まとめ

第1章の内容はテスト駆動開発の第1部多国籍通貨のようにペアプロをしているように感じさせる書き方だった。
ただ、テストコードがないため自分で書いたものを使った。

後半で「ポリモーフィズムによる条件記述の置き換え」の例が出ていた。 私もswitch文が登場したら不吉な匂いを感じて多くの場合は書き換えるのだが、それをほかの人に説明するための具体例に困っていた。
今後はこの書籍の例を引用したいと思う。

私は手続き型で書かれたコードをリファクタリングする際にこのテクニックは頻出だと思っているが、自分の経験の中には「誰にでも」しっくり来る例がなかったので良い例を知れたことが嬉しい。1

年齢の割にプログラミング歴が浅い&詳しい業務が偏っている私にとって、書籍から得られる汎化された知識・テクニックはとても有り難い。

全編を通して読んだが、(直前で言ってることとは矛盾するが)経験を積んだおかげか大部分を理解できた(と思う)。
だいぶ前に増補改訂版Java言語で学ぶデザインパターン入門を読了済みだったため、予備知識があったからだと思われる。

DDD本と同じく2〜3回再読してしっかりを知識を染み込ませよう。

ちなみに、今まで我流で身につけた方法にこの本の手順を組み入れたやり方2を既に現場で実践し始めた。

以上。


  1. 私は一番長く関わっている業務分野が認証なのだが、この文脈の中から例を取り出してもわかってもらえることが少ない

  2. 組み入れたと言ってみたが、大部分はほんのやり方に置き換わった

ITエンジニアに読んでほしい!俺的技術書大賞2017

ITエンジニアに読んでほしい!俺的技術書大賞2017

タイトルは完全にパクリです。 http://www.shoeisha.co.jp/campaign/award/2017/

前置き

今年も結構な数の本を読みました。読書メーターで読んだ本を振り返ると技術書だけでも11冊、その他は3冊でした。再読と技術書以外の書籍も含めると合計で20冊読んだようです。

そうして出会った本達の中で『これは良い!』というものを見つけたら、その都度身近にいる方々にはすすめているのですが、せっかくなのでこの場で共有してみたいと思います。

今回書評を紹介したいのは、2017年発行の4冊です。

どれも良書でしたので、おすすめ度が高い順番に紹介します。

2017年発行の書籍おすすめランキング

まずは、おすすめ順の一覧でどうぞ。

  1. 現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法
  2. Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで
  3. テスト駆動開発
  4. アプリケーションアーキテクチャ設計パターン

各書評

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

初級者と初級者を卒業したばかりの中級者のエンジニアと初中級者を指導する立場のエンジニアに、強く強くおすすめします。

オブジェクト指向らしく書いたほうが良いという話はよく聞きますしそういう人に出会うことも多いですが、具体的な例でわかりやすく説明してくれる(できる)人って出会ったことがありません。身近にそんな人って周りにごろごろいますか?

可読性大事っていうけど実践できる人ややり方を具体的に教えてくれる人ってめったにいませんよね。

かくいう私も現場で地道にOOPの布教活動をする側ですが、いつも上手に伝えられているかというとその自信はありません。口頭で伝えきれない場合はどうしても具体的にコードを書いて示してしまいます。

でもそれをやりすぎると『自分で書いたほうが早い』となってしまうので都度やり方を伝えて覚えてもらうにしても、どれほどそのコストをかけるのか、かければよいのか1という点が難しいところです。

そういう場合、悩むのは『もっと手早くかつわかいりやすく伝えるにはどういう言い回しや例の出し方があるのだろう』だとか『この本読んどいてって渡せる書籍があると楽だなぁ』といったことではないでしょうか。

少なくとも私はそうでした2

そんな教える側にとっても教えられる側にとっても役に立つ本、それがこの本だと想います。

OOPらしく書くときにコードで気をつける点を端的に纏めてありますし、気をつけている何かに気づいた場合にどう対処したらよいのかをPolicy/StrategyやStateといったデザインパターンを使って説明してくれています。

例えば。

ビジネスでよく出てくる満たすべき条件はPolicy/Strategyパターンを使えばif文を使わずに簡潔に表現できること、ある状態からある状態へ遷移可能かどうかをEnumとMap(連想配列)を使って簡潔に表現できること、子どもや大人といった区分で変わる振る舞い(書籍の例だと料金)には専用に用意したクラス(enumなど)に振る舞いを与えれば良い3などなど、役立つパターンが数多くわかりやすく紹介しています。

『あぁ、はいはい。デザインパターン、小難しいやつね』とちょっと思ってしまった人もしかしていませんか?

そんな人にこそおすすめです。

名前がついてしまうと小難しいような感じがしますが、実際は『なんだかよくわからないけど、ちょっと見てみるか』程度の覚悟でもちょっと中身を覗いてみると一度か二度は自分でも書いたことのある構造になっているもので、そんなに難しいものではありません。

食わず嫌いをせずにぜひ手にとって見てください。3ヶ月後にはコードの質が変わっているかと思います。

具体的な中身についての書評はググるとたくさん出てきますのでこれ以上はやめておきます。

ぜひ、みなさんも読んでみてください。絶対に後悔させません。こう強くいい切れる程度にはおすすめです。

ちなみに私は都合3回読みました。


Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

最初に断っておきますが、『入門』と題する割にはそこまで初級者向けではありません。

これも中級者の入り口くらいにいる人におすすめの書籍です。

Javaの言語としての仕様・構文の説明もありますが、どちらかというと経験豊富な著者らが現場で培った『Javaをうまく使うにはどうしたらよいか』の知見を広める書籍の側面が強いように思えます。そうかくとちょっとEffective Javaっぽいですが、もっと簡単な内容です。

そのため、『Javaの構文や言語特性はある程度覚えた。でもそれらをどう使いこなせばわからない』という人に状況にいる人に特におすすめです。

レベル感としては業務でコードを書き始めて1年経過したくらい4のエンジニアに特に適していると思います。

私は認証関係を扱うことが多いのですが、認証系の業務であまり扱う機会のないファイル操作に関しての章がとても勉強になりました。

一番役立っているのはListをimmutableに使えるドSのCollections#unmodifiableListを知れたことです。

原則としてインスタンスはimmutableにしたいのですが、Listとなるとそうはいかないのがこの本をよむまでの悩みでした。しかし、このAPIを知れたことで簡単にimmutableなListを作ることができるようになり、いまはとても捗っています。

と言った具合に現場で役立つ情報が盛り沢山です。

この本のタイトルにも『現場で役立つ』の冠をつけたほうがよかったかもしれませんね。


テスト駆動開発

言わずとしれた名著の新訳版です。JUnit5でも動くように書き直されており、コードサンプルも省略されている部分がないせいで全体像が見えなくなる(読者が迷子になる)ことがないように細かい所まで配慮されています5
もはや古典と言って良いこの本ですが、翻訳者のt-wadaさんの手で見事に生まれ変わっています。

さて、この書籍はテスト駆動開発というタイトルが付いてはいるものの、この本の本質はテスト自体にはなく『プロダクションコードがもつ意図をテストコードでどう表明するか』を具体的に示している点ではないでしょうか。
その点を付録Cでの『TDDのテストとは、いわばプログラミングの補助線、治具です』と言う言葉が端的に表しているような気がします。

私達が普段書いているテストには回帰テストの意味合いがあります。
しかし、それより重要なのは『意図していた・期待していた振る舞いをプロダクションコードが正しく表現できいるか』を確認するすべなのだということを示している点ではないでしょうか。

3番目に挙げてはいますが、この本も本当に良書です。
ぜひ、手にとって見てください。


アプリケーションアーキテクチャ設計パターン

この本はアーキテクチャ寄りのエンジニアにおすすめです。

業務で普通に話されているが、実はよくわかってない用語やよくある一般的なアーキテクチャについて知るにはとても良い書籍です。
しかし、(ただの印象ではあるが、ちょっとだけ)Java EE贔屓に感じる6ところがあり、またドメイン駆動設計の説明が薄く、手続き型を前提にしている点が少しだけ残念に感じました。
ただ、それ以外は現場で役立つ情報が満載で本当に勉強になる書籍です。

万人向けではありませんが、方式設計などにも興味がある人にはおすすめします。

終わりに

以上、4冊の書籍を紹介しました。 興味を持った本はありましたか?

もしあれば、ぜひ買ってみてください。

ちなみに私は紹介したほとんどの本を会社の書籍購入補助を利用して買いました7
良い会社ですよ、本当に。

以上。



  1. 相手が自社のプロパーの場合は話は別で、スキルアップすればするほど会社の資産・利益につながるので時間と都合が許す限りはリソースを割いています。相手が伸びるのを見ているのも楽しいですしね。

  2. ちょっと偉そうに書いてみましたが、どちらかといえば私も教えられる側の中級者だと思っています。

  3. 著者は区分オブジェクトと表現しています。私はStateパターンの亜種だと思っています。一般的に知られたデザインパターンでしょうか?私は知りませんでした。

  4. 根拠のないただの感覚値ですがステップ数に換算して4000行、クラス数に換算して30-50程度でしょうか。

  5. この点で良書なのにもったいないと感じたのはClean Codeが挙げられます。リファクタリングの様子を紹介している節があるのですが、コンパイルが通る完全なコードが載っておらず、私は写経ができませんでした。やる気をなくしてしまったあとに付録にコードがあることに気づきましたが、借りていた本ということもあり時間の都合でトライする前に返してしまいました。

  6. 著者はマスタリングJavaEE5の人なので、ポジショントーク的なところもあるのかなという気はしています。のでまぁ、私は仕方ないと思いました。どこにそう感じたのか時間があればもう一度振り返りたいと思います。

  7. 年間で10冊以上技術書を買っていると結構な金額になるので、この制度はとても助かっています。感謝しかありません。