JJUG CCC 2015 Spring F2 発表資料

1. ほんとうに便利だった
業務で使えるJava SE8 新機能
Vol.01 Apr/11/2015
Yuki Fukuda
DU, Rakuten Inc.
http://www.rakuten.co.jp/

2. 2
Speaker Profile
Yuki Fukuda (福田 雄貴)
Financial Service Department, DU(April, 2011-­)
• Web Application Engineer
• Team Manager
Java歴: 会社にはいってから

3. Introduction:
Java SE8を初めて使った時の話

4. 4
March, 2014 – Launch!
Java 8 リリース
おめでとうございました

5. 5
ある日の先輩エンジニアとの会話
都合よく降ってくる案件
Senpai Engineer:
今度新規Webアプリ構築の話があるんだけど 興味ある？
Fukuda, Yuki:
あります

6. 6
その直後の技術管理マネージャーとの会話
選択肢を用意しない交渉
Fukuda, Yuki:
今度 新規のWebアプリ開発案件があるらしいんですけど
Java SE8 と Java EE7 でいいですか？
いいですよね？
Technology Manager:
いいよ

7. 7
はじまったプロジェクト
n工期
n工数
n人的リソース
約6ヶ月
67人月
なんとかして

8. 8
ぼくの考えた最強のスケジュール
May June July August September October
要件定義
結合テスト
QA・総合テスト
詳細設計
基本設計
開発・単体テスト

9. 9
May June July August September October
提示されたスケジュール
要件定義・設計
テスト
QA
開発
念のため
テスト

10. 10
スケジュール上の問題点
1 要件を決める気がない
3 開発より先に念のためテストがある
2 要件を決めている最中に結合テストが始まる

11. 11
ほんとうに困った問題点
1 要件を決める気がない
3 開発より先に念のためテストがある
2 要件を決めている最中に結合テストが始まる
n人的リソース
なんとかして

12. 12
3年目の勘
1) この案件は絶対にヤバイ。
2) スーパーエースを全力で
投入しないと自分が死ぬ。

13. 13
所属組織マネージャーとの会話
スーパーエースを全力で投入しないと自分が死ぬ
Fukuda, Yuki:
スーパーエースを１０人ください
Group Manager:
おまえは何を言っているんだ
Fukuda, Yuki:
え？

14. 14
はじまったプロジェクト(再掲)
n工期
n工数
n人的リソース
約6ヶ月
67人月
なんとかして

15. 15
所属組織マネージャーとの会話(続き)
表現が良くなかった
Fukuda, Yuki:
普通の人の1.5人分働くヤツを7人ください
Group Manager:
お前が2人分働けば6人で足りるよね
Fukuda, Yuki:
はい。え？

16. 16
祝・開発チーム結成
7名のエンジニア確保に成功
※ただし7国籍
↑福田

17. 17
公用語
俺達には
英語がある

18. 18
朝のあいさつ
現実の会話
Fukuda, Yuki:
早安（中国語）
Engineer:
Bonjour（フランス語）
Engineer:
おはよー（日本語）
Engineer:
moi（フィンランド語）
Engineer:
Good morning!（英語）

19. 19
実際の公用語
Java

20. 20
果たして本当にそうか！？
理想 現実
コーディング規約 Java SE8に関する規約なし
世の中のスタンダード 探しても見つからない
Java SE8を解析できない
※いまはできます

21. 21
スーパーエースたちは思った
「信じられるのは自分だけだ」

22. 22
スーパーエースたちは思った
「信じられるのは自分だけだ」
＝宗教戦争のはじまり

23. 23
本日のテーマ
宗教戦争の果てに
僕達が見たもの

24. Main Chapter:
ほんとうに便利だった新機能

25. (1)Stream API

26. 26
Stream API -­ for文禁止令
for文禁止
※ついでにwhile文も禁止

27. 27
Stream API -­ 問
いかにして
エンジニアを
for文から
脱却させるか

28. 28
Stream API -­ IDEによる自動変換
自動変換はお手軽だけど
生成されるコードは微妙

29. 29
Stream API -­ やっぱり自分で書こう！

30. 30
Stream API -­ シンプルに教育
1 Streamの始め方
3 Streamの終わり方
2 Streamのつなぎ方

31. 31
Stream API -­ Streamの始め方(1)
Collection#stream()
「forの代わりにstreamって書け」

32. 32
Stream API -­ Streamの始め方(2)
Arrays#stream(T[] array)
配列から始めるときはこちら

33. 33
Stream API -­ Streamの始め方(3)
Files#lines(Path path)
ファイル読み書き系のバッチ処理において極めて有能

34. 34
Stream API -­ Streamのつなぎ方(1)
filter(Predicate<? super T> predicate)
主な用途:
Streamを流れるデータのバリデーション
データの絞り込み

35. 35
Stream API -­ Streamのつなぎ方(2)
map(Function<? super T, ? extends R> mapper)

36. 36
Stream API -­ Streamのつなぎ方(3)
peek(Consumer<? super T> action)
特にログを吐くときが便利
業務ロジックを動かすときは使わないこと
※サンプルには書いていますが仕事では使ってません

37. 37
Stream API -­ Streamの終わり方(1)
よくある事例：
CollectionをStreamとして処理したあと、最後にCollectionに戻したい

38. 38
Stream API -­ Streamの終わり方(1)
あまりない事例：
StringのStreamをいろいろいじくった最後に結合したい

39. 39
Stream API -­ Streamの終わり方(2)
よくある事例：
Streamの各要素をファイルに書き出したい
StreamはAutoCloseableを実装しているので
try-­with-­resource文のリソースとして利用可能

40. 40
Stream API -­ Streamの終わり方(3)
よくある事例：
なんらかの処理をしたあと n番目の要素がほしい

41. 41
Stream API -­ いいわけパート
0 0.0005 0.001 0.0015 0.002 0.0025 0.003 0.0035 0.004 0.0045 0.005
while
for
Statement / Step Count
Java SE7
Java SE8
-80% (※当社比)
-85% (※当社比)

42. 42
Stream API -­ いいわけパート
よくある事例：
検査例外がうまくさばけなかった

43. 43
Stream API -­ いいわけパート
よくある事例：
実質的final制約に負けた
IDEは結構賢いのでStreamへの変換をサジェストしてきません

44. 44
Stream API -­ いいわけパート
あまりない事例：
救いようがないほど複雑なロジックだった

45. 45
Stream API -­ まとめ
実プロジェクトではこれらの事例が複合的に襲ってきますので
for文禁止は弾力的に運用するのがよさそう
「移植したソースを直す時間
がないから」「Streamよくわか
らないから」といった理由で
for文を許可するのはダメ
※今回のプロジェクトでの判断基準は
ラムダ式の -> の右側に{ } が必要になるかどうか
にしました

46. (2)Method References

47. 47
Method References -­ Lambdaも悪くないけど…
.filter(string -­> string.length() > 6)
ちょっと鬱陶しい（というか仕事でこんなのかきたくない）

48. 48
Method References -­ Lambdaも悪くないけど…
2行以上に渡るラムダ式みたくない
ネストが深い

49. 49
Method References -­ こっちのほうが馴染みがある
他の外部ライブラリのメソッドとかも使いたい

50. 50
Method References -­ そのまま使おうぜ！

51. 51
Method References -­ Streamをシンプルに

52. 52
Method References -­ メリット
• Streamが見た目シンプルになる
• 今まで使っていたコードをそのまま再利用できる
• 単体テストが簡単になる

53. 53
Method References -­ デメリット
どうみてもそこにいるべきではないコードが出現している

54. 54
Method References -­ 教訓
ちゃんと関数型インタフェースを実装したクラスの作り方を教育すること
※そういうものが存在するっていうことを教えてあげること

55. (3)Date and Time API

56. 56
Date and Time API -­ java.util.Date禁止令
java.util.Date
禁止
※もちろんCalendarも禁止

57. 57
Date and Time API -­ メリット
直感的

58. 58
Date and Time API -­ エンジニアが苦しんだ理由
なぜかMay

59. 59
Date and Time API -­ 苦しみからの解放
直感的！！

60. 60
Date and Time API -­ 加算減算
直感的！！

61. 61
Date and Time API -­ うるう年判定 (Before)
＿人人人人人人人人人人人人人＿
＞ 突然のGregorianCalendar ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣

62. 62
Date and Time API -­ うるう年判定 (After)
直感的！！

63. 63
Date and Time API -­ 和暦 (Before)
ロケールに ja_JP_JP をセットすると
JapaneseImperialCalendar のインスタンスを生成する！

64. 64
Date and Time API -­ 和暦 (After)
直感的！！

65. 65
Date and Time API -­ 実際の運用(1)
ZonedDateTimeインスタンスの取得方法を限定する。

66. 66
Date and Time API -­ 実際の運用(2)
java.util.Dateとの相互変換メソッドを提供する
外部ライブラリの都合で泣く泣くjava.util.Dateを使わされるケースが
多々有ります

67. 67
Date and Time API -­ 実際の運用(3)
DateTimeFormatterも共通で使うものを用意しておく

68. 68
Date and Time API -­ 実は。
コード書く人にとっては
そんなに便利になっていない
のでは。
一理ある

69. 69
Date and Time API -­ 我々が真に獲得したもの
• 変なことをすると例外を吐いてくれる
• Immutable
• スレッドセーフ
• 見た目わかりやすい
という安心感。

70. (4)Optional

71. 71
Optional -­ nullチェック禁止令
nullチェック
禁止

72. 72
コードレビューの日常
Optional -­ 良識あるエンジニアによるレビュー
Code Reviewer:
安易にnullを返したらダメです
ちゃんとチェックしてください
意図してnullを返す場合はちゃんとコメントに書いてください
Young Engineer:
はい

73. 73
Optional -­ レビューの結果
nullを返さないソースコード
nullを返す場合はコメントに書く

74. 74
Optional -­ 後日
別の人が新しいロジックを書きました。

75. 75
コードレビューの日常
Optional -­ 良識あるエンジニアによるレビュー(2)
Code Reviewer:
そこnullが返ってきても大丈夫ですか
ちゃんとチェックしたほうが良くないですか
Young Engineer:
はい

76. 76
Optional -­ レビューの結果(2)

77. 77
Optional -­ チェックされていると安心する
とても
安全！！

78. 78
Optional -­ もうやめよう
人間のやる
仕事じゃない

79. 79
Optional -­ これからの時代
Optional(nullかもしれない値)

80. 80
Optional -­ nullの可能性があることを主張したい
(1)返り値の型をOptionalにする
(2)返す値をOptionalで包む

81. 81
コードレビューの日常
Optional -­ これからのレビュー
Code Reviewer:
nullが返る可能性があるのなら
Optionalで包んでください
Young Engineer:
はい

82. 82
Optional -­ nullでないことを保証しなければならない
返す値をOptionalから値を取りだす
Optionalが空のときはデフォルト値を返す

83. 83
コードレビューの日常
Optional -­ これからのレビュー(2)
Code Reviewer:
返り値がOptionalではないのなら
nullが返らないように作ってください
Young Engineer:
はい

84. 84
Optional -­ ダメな例
Optional#of(T value)はnullを渡すと NullPointerException が発生します
→このメソッドはあまり出番がないです
isPresent() + get() = やってることがnullチェックと同じ
→単純なisPresent()とget()の組み合わせは避けましょう
※isPresent()はifPresent()の処理で例外処理を入れたい場合など、
用途を限って使うのが良いと思います。

85. 85
Optional -­ プログラマを処刑すべき例
絶対に許さない

86. 86
Optional -­ orElse() orElseGet()

87. 87
Optional -­ orElseThrow()

88. 88
Optional -­ 利用にあたって
中途半端が
一番危険
このルールを適用する範囲を明確にしないと
Optionalをちゃんと返すやつとnull返すやつが混在する
カオスコード集が完成します

89. (5)Others

90. 90
UncheckedIOException
ご利用は計画的に！！

91. 91
String#split()
“When there is a positive-­width match at the beginning of this string
then an empty leading substring is included at the beginning of the
resulting array. A zero-­width match at the beginning however never
produces such empty leading substring.”
英語版Java SE8ドキュメントより引用
http://docs.oracle.com/javase/8/docs/api/java/lang/String.html

92. 92
Collection / List / Map
Streamを使う前に一度確認を！

93. Conclusion:
まとめ

94. 94
まとめ
Java SE8を仕事でつかってみました
いくつかの新機能について
思ったことを話しました
• Stream API
• Method References
• Date and Time API
• Optional
• その他

95. 95
まとめ
• シンプル
• 安全
• 古いコードもう見たくない
Java SE8 すてき！

96. 96
まとめ
Java SE8を導入して幸せになろう！
※ただし、コーディング規約や
ポリシーの類は整理が必要

97. おわり