今年もJJUG CCC に参加してきました。 例年に比べて遅めの開催だったので外は寒かった。 http://www.java-users.jp/ccc2018fall/#/www.java-users.jp
- ふつうのJavaアプリ開発のための自動テスト戦略
- ドメイン駆動設計とSpring Bootを活用したアプリケーション開発
- The Silence of the Lambs: Promoting and Inspecting Source Code and Binaries, in Continuous Delivery Pipelines
- 思考停止しないアーキテクチャ設計
- 今こそStream API入門
- Migration Guide from Java 8 to Java 11
- コードをどまんなかに据えた設計アプローチ
- 「マイクロソフト牛尾さん渡米直前記念」 外資系企業で働くエンジニアの生産性向上物語
- 全体感想
ふつうのJavaアプリ開発のための自動テスト戦略
自動テストを高速化するために、テスト設計を見直したお話。
最近ではTDDなども認知されて来て、テストコードを書くのも当たり前になって来たと思いますが、それ故に、テスタビリティを考えた設計や構造にしないと、テストの実行時間だけが増えるだけで、継続的な改善が出来なくなり、本来の自動テストの目的が失われてしまいます。
ここでは特にテスト時間が長くなる主な要因の、Springコンテナ起動やDBとの接続先などの環境周りについて改善したことを紹介していました。
レイヤー階層にして、フレームワークや環境に依存しないモジュールを多く作ることが大事で、恐らくそれはDDDなどのドメイン層のようなビジネスロジックに切り出すことなんだなと思いました。
ドメイン駆動設計とSpring Bootを活用したアプリケーション開発
SpringBootのチュートリアルを進めて「SpringBoot完全にマスターした」状態で、業務アプリケーションを開発していったら、ドメインモデル貧血症に陥ってしまった。そこからDDDでどうやって改善していったかと言うお話。
恐らくリクエスト単位にSpringBootに依存しているファイルにビジネスロジックを作ってしまい、テストもしづらく、要求の変化に対応しにくい作りになってしまったのだと思います。
自分も以前の現場で、Strutsを利用したアプリケーションで、Actionクラスに沢山ロジックを詰め込んで、環境依存も激しいスパゲッティコードばかりのシステムに携わって似たような経験をしたことを思い出しました。
フレームワークで何でもやろうとせずに、フレームワークに任せるべき所とフレームワークに依存しない業務や振る舞いをしっかり把握して、構造化するためにもDDDを知ることが大事だと改めて認識しました。
The Silence of the Lambs: Promoting and Inspecting Source Code and Binaries, in Continuous Delivery Pipelines
http://www.java-users.jp/ccc2018fall/#/sessions/849342fa-7bfc-417f-96b5-71f76df70c2c
海外のJavaチャンピオンの方による、ソースコードとバイナリファイルに対する静的解析の部分に焦点を当て、Jenkin pipelineを使ったデモを見せて頂きました。
ソースコードの静的解析に使っていたSonar Qubeは知っていましたが、バイナリファイルの解析に使っていたTwistlockは初めて知りましたが、システムに使っているライブラリやDockerコンテナにインストールされているソフトウェアのバージョンを読み取り、脆弱性情報を検知してくれるようでした。コードの静的解析は良く使われますが、バイナリレベルで脆弱性を解析まで出来るとより、信頼性の高いシステムがリリースできると思うのでツールを知ることが出来て良かったです。
海外のエンジニアのセッションを通訳無しで聴くのは初めてでした。 正直、話の半分以上は聞き取れなく問いかけられていた事やジョーク的な話題が理解できなかったのが悔しかったです。
思考停止しないアーキテクチャ設計
www.slideshare.net
川島さんによるアーキテクチャ設計で考慮するべき内容をまとめたお話。難しい内容でしたが、自分達のこれまでのシステム設計ではここでお話しされていたことはほとんど考慮していなかったなと反省しました。
様々な視点で考えられるパターンがあり、パターンごとにトレードオフがあって、単純にこれをやればOKみたいな選択（つまりこういう考えが思考停止かな）は無いよと言うのが良くわかりました。
今の仕事や立場では自分でアーキテクチャを設計することがほとんど無いのですが、いずれ携わることもあると思いますのでその時に向けて少しでも勉強しておきたいと思います。
今こそStream API入門
www.slideshare.net
桜庭さんによるStream APIとラムダ式の概要と使い方のお話。
「本当は別の内容でCfPを出したけど、JJUGの会長からStreamの話をして欲しいと言われた。」そうなのですが、その辺も含めStreamやラムダ式がまだ広く普及していない現状があるのかなと感じました。
自分自身も仕事で書くコードでは使ったことがなく、書籍やブログを見て触れた程度しかなく、なかなか慣れていなかったので復習も兼ねて聴きました。
「これまでのfor文を使ったイテレーターとの違いと言った視点からのStreamのメリットの説明」と「仕組みの理解は後回しでいいので取り敢えずStreamを書いて慣れよう」と言った話で Stream APIとラムダ式への抵抗感を減らしてから、使い方の説明に入ったのでとてもわかりやすかったです。
また、BGMやスライドの画像の中にStreamやラムダ式に関する小ネタが仕込まれているのも楽しかったです。
例題を使った説明では、慣れないうちは中間操作の記述を飛ばしてforEachで処理を書き、処理を少しずつ中間操作に変えて変えて行って、forEachでの処理が無くなるまで繰り返す考え方はとても覚えやすいと感じました。
また「Streamの例外処理への対応が難しくて困っているが、どうするといいか？」と言う質問に「eitherパターン」を紹介されていました。ちょうど前日に会社でStreamを使っている同僚からも同じように例外処理に困っている話を聞いていたので、質問された方共々、大変助かりました。
Migration Guide from Java 8 to Java 11
www.slideshare.net
久保田さんによる、Java 8 から Java 11への以降方法の仕方や注意点のお話です。 今の自分のお仕事で紹介しているA社のツールは現行バージョンはJava 11をサポートしないようで、どの製品も次のバージョンからの対象となるようなのですが、会社で開発しているアドオンなどは近いうちに新バージョンへの対応と合わせてJava 11への移行を検討しなければいけないと思うので聴きました。
説明の中では大きく２つの移行パターンとして「Java 8でコンパイル済みのアプリケーションをJava 11で実行する」と「Java 11でコンパイルし直して実行する」が紹介されていました。自分の中では基本的に後者のJava 11でコンパイルし直すことしか頭になかったので、前者の方法についてなるほどなと思いました。もちろんどちらの方法でもメリット・デメリットがあるわけですが。
またJava 8では使えていたAPIなどが廃止になっているものも多く注意が必要なのとテストが重要なことも理解できました。また今後のリリースサイクルを考えた時にLTSで同じバージョンを数年使う方法もありますが、いざ新しいバージョンに切り替えた時に同じようにAPIが廃止になっていることもあるのかなと思うと、一概にLTSに頼るのではなく半年ごとのバージョンアップで定期的にテストしながら移行するのが結果的に楽になるのかも感じました。
コードをどまんなかに据えた設計アプローチ
irofさんのセッション。設計・ドキュメント・コードはどれも必要なモノやプロセスであることを再認識した上で、プログラマーの欲求や無駄を考えてコードを中心に設計とドキュメントを回していく方法をお話されていました。
従来からの『設計する -> ドキュメントを書く -> コードを書く』の流れを改善していく中で「コード = ドキュメント」と言う考えが増えて来ていると自分は考えています。そこには無駄を減らしたいと言う思いと共にコードを書く時間をふやしたい、綺麗なコードを書きたいという思いや欲求があるからだと思います。
ですが実際はコードがドキュメントの代わりを完全に請け負えることはなく、わかりやすさと言う意味ではコードよりもドキュメントの方が良いのですが、無駄とか欲求を理由にドキュメントを作らないことを正当化しようとしているだけなのかもしれません。また、これはアジャイルマニフェストの「包括的なドキュメントよりも動くソフトウェアを」を誤解したり都合よく解釈して、"アジャイルはドキュメントがいらない"と定義してしまうことと同じと感じました。
お話の中では、ドキュメントが必要である現実から逃げずに、コードを中心とした逆転の発想で『コードによる設計』と言う考えを提示し、コードから意図を汲みやすくする方法やJIGと言うツールを使って書いたコードからドキュメントを出力する方法を説明されていました。
個人的にはこれに加え、テストしやすい設計とコードも意識して取り組んで行きたいなと思いました。
「マイクロソフト牛尾さん渡米直前記念」 外資系企業で働くエンジニアの生産性向上物語
http://www.java-users.jp/ccc2018fall/#/sessions/b0657145-4de3-4a64-b02b-83fbc2fdc6b9
牛尾さん、今月末に米MSの部署に異動され、生活拠点もアメリカに移されるんですね。そんな背景の中、同じくMSの寺田さんとのトーク形式で日本のエンジニアに向けて、とても面白くまた考えさせられるお話が聞けました。あっという間に時間も過ぎてしまい、もっと聴きたかったので、牛尾さんが日本に戻られた時などにまたお二人のトークセッションを聴きたいです。
トークの内容は主に「キャリア形成」「情報発信」「英語によるコミュニケーション」の３つで、セッションタイトルにもある”生産性向上”に繋がるようなお話が間接的に聞けた気がしました。
キャリア形成の話では「働き方改革を知りたければ、外資系とか他の会社に入って肌で感じるといい。」とか、「転職について難しく考えすぎでは？自分がどうしたいか目標を建ててそれを達成するための行動をとればいいんじゃないか」とか。情報発信ではブログの使い分けをお話されて、通常のブログは注目されるような記事を書くことを心掛けているが、自分のための技術的な記録はqiitaに書いている。また英語のブログも書いているが海外のエンジニアはそれを意外と読んでいることが多いそうです。英語の話が一番多かった気がしていて「英語が出来ないことで技術を身に付けることに不利が出てしまう」ことや「英語を母国語として使ってない国の中でも日本語が英語と離れた言葉になっている」など話され、牛尾さんも寺田さんも決して若い頃から英語が出来たわけでなく、仕事の中でどんどん英語でコミュニケーションを取るようにしたとのことでした。
全体感想
今回は自分が取り組んでいる技術や、仕事で検討していることを中心に聞いたこともあり、どれもすごく勉強になりました。
また、特にテストやDDDといったキーワードで話を聞いていて、次回に向けて自分もちょっと話できたらいいなと思い浮かんだことがあったので、もしタイミングが合えばCfp出してみようかなと思っちゃいました。
