Share
Embed
Slide 1
Slide 1 text
古のJavaを使うということ
#ccc_m71
JJUC CCC 2016 Spring ぜろゆ
Slide 2
Slide 2 text
#ccc_m71
目次
* 自分について - これは誰ですか？
* 出会い - これはJavaですか？
* コメント - これは消せますか？
* テスト - これは直せますか？
* 周りに広める - これは使えますか？
* 古のJava - これは変えられますか？
Slide 3
Slide 3 text
#ccc_m71
自分について - これは誰ですか？
* ぜろゆ
* 文系出身・プログラミング(ほぼ)未経験で就職
* 社会人3年目
* Twitter：@zer0_u
Slide 4
Slide 4 text
#ccc_m71
出会い - これはJavaですか？
* Javaで「Hello,World!」できる程度で入社
「Java完全にマスターした」
* 研修で「動くものをつくる」魅力にはまる
→ 自分でもコードを書くように
* よりよいものを作るために勉強&写経
* JUnit実践入門
* リーダブルコード などなど
Slide 5
Slide 5 text
#ccc_m71
出会い - これはJavaですか？
* 配属！
* 知ってるコードを書くとコンパイルエラーが出る
→ (o･д･)？？？
* どうやらJavaにはバージョンというものがあるらしい
* じゃあ、この現場で使ってるJavaは？
Slide 6
Slide 6 text
#ccc_m71
出会い - これはJavaですか？
＞＞＞ J2SE1.4 の気配を察知 ＜＜＜
Slide 7
Slide 7 text
#ccc_m71
J2SE1.4 - これはバージョンアップできますか？
* 諸般の事情によりバージョンアップ不可
* この現場にいる限り逃げられない
↓ このときのぜろゆ
(o･д･) 。○(とはいえ書けるものが少ないだけでしょ？)
Slide 8
Slide 8 text
#ccc_m71
出会い - これはJavaですか？
↓ いまのぜろゆ
(o･д･) 。○(そう簡単な話でもなかったんだよなぁ)
Slide 9
Slide 9 text
#ccc_m71
コメント - これは消せますか？
* 業務 - 保守(不具合修正)が9割
* 自分がゼロからコードを書くことはまずない
* 誰かの書いたコードを読んで修正・追加がメイン
* 状況
* バージョン管理あり
* コードレビューあり
Slide 10
Slide 10 text
#ccc_m71
Slide 11
Slide 11 text
#ccc_m71
コメント - これは消せますか？
(o･д･)「うわぁ、コメントアウトめっちゃいっぱいある」
(o･д･)「バージョン管理してるし消しちゃえ」
(o･д･)「小手先で直すとコード汚くなるな...」
.....
(o･д･)「できた！ コードレビューお願いします！」
Slide 12
Slide 12 text
#ccc_m71
コメント - これは消せますか？
(*‘∀‘)「ここ何で消したの？」
(o･д･)「え？ コメントアウト邪魔じゃないですか？」
(*‘∀‘)「修正範囲は最低限だって言ったよね？」
Slide 13
Slide 13 text
#ccc_m71
コメント - これは消せますか？
* 用語「修正範囲」
* 限りなく狭いほうがよいとされているもの
* 同じ問題を解決できる複数の手法がある場合、
修正されるコードの行数が少ないほうが良い
Slide 14
Slide 14 text
#ccc_m71
コメント - これは消せますか？
* 用語「修正範囲」
* 限りなく狭いほうがよいとされているもの
* 同じ問題を解決できる複数の手法がある場合、
修正されるコードの行数が少ないほうが良い
* 特に既存の部分を(コメントも含め)削除することは
できる限り避けるべきである
Slide 15
Slide 15 text
#ccc_m71
コメント - これは消せますか？
(o･д･) (とはいえこれ半端に手を入れても意味なさそうだが)
(o･д･)「わかりました、やりなおします」
(o･д･) (どうする？)
Slide 16
Slide 16 text
#ccc_m71
コメント - これは消せますか？
(o･д･) (どうする？)
1. 先輩のいうことを受け入れる
2. 強行突破する(同じ主張を繰り返して折れるのを待つ)
3. 何か素敵な策を思いつく
Slide 17
Slide 17 text
#ccc_m71
コメント - これは消せますか？
(o･д･) (・・・！)
(o･д･) (修正範囲を妥当に見せかければあるいは)
・・・
(o･д･)「できました！もう一度レビューお願いします！」
Slide 18
Slide 18 text
#ccc_m71
コメント - これは消せますか？
* ここで取った作戦
* 「できる限り不具合を酷く見せる」
* 史上最悪の不具合に見せかけるためにひたすら
発生条件を増やし続けて1週間
* 修正しても致し方ないと思える範囲を広げれば
コメントアウトの削除も許されるはず…！
* 一部コメントアウトの削除はあきらめる
→ コメントアウト部分の削減に成功！
Slide 19
Slide 19 text
#ccc_m71
コメント - これは消せますか？ (まとめ)
* 最善のコードを書くためには被害状況を盛ることも大事
* コメントアウト一つといえど舐めてかかってはならない
* 現状のコードにはそれなりの理由があって成り立っている
ことがわかった
* とはいえJavaDoc形式でコメントアウトするのはやめろ
* Javaっぽい話はこの次から →
Slide 20
Slide 20 text
#ccc_m71
テスト - これは直せますか？
* 業務
* 誰かの書いたコードを読んで修正・追加がメイン
* 状況
* バージョン管理あり
* コードレビューあり
* テストコードなし
* 仕様ほぼなし (都度ベストな対応を考える)
Slide 21
Slide 21 text
#ccc_m71
テスト - これは直せますか？
* 用語「動作確認・保証」
* 画面上で操作を行い、不具合が修正されているか・
別の不具合が起きていないか・過去に修正した
不具合が再発していないかを確認すること
* 開発者でも同じように動作確認・保証を行う
Slide 22
Slide 22 text
#ccc_m71
テスト - これは直せますか？
(o･д･)「画面ぽちぽちするの面倒」
(o･д･)「JUnitとかいうのあるんでしょ？」
(o･д･)「テストコードが大事って知ってるもん」
(o･д･)「テストファースト！」
Slide 23
Slide 23 text
#ccc_m71
テスト - これは直せますか？
プライバシーに配慮して一部に目隠しを施しています
Slide 24
Slide 24 text
#ccc_m71
テスト - これは直せますか？
＿人人人人＿
＞ ない ＜
￣Y^Y^Y￣
Slide 25
Slide 25 text
#ccc_m71
テスト - これは直せますか？
(o;･д･)「な、なければ書けばいいんだよ」
Slide 26
Slide 26 text
#ccc_m71
テスト - これは直せますか？
＿人人人人人人人人＿
＞ 突然のJ2SE1.4 ＜
￣Y^Y^Y^Y^Y^Y^Y￣
Slide 27
Slide 27 text
#ccc_m71
テスト - これは直せますか？
* JUnit (基礎知識)
* 現在の主流はJUnit4
* アノテーションを使って簡易に記述できることが特長
* アノテーションが利用できるのはJ2SE1.5から
Slide 28
Slide 28 text
#ccc_m71
テスト - これは直せますか？
＿人人人人人人人人＿
＞ しかしJ2SE1.4 ＜
￣Y^Y^Y^Y^Y^Y^Y￣
Slide 29
Slide 29 text
#ccc_m71
テスト - これは直せますか？
(o;д;)「今からJUnit3勉強しても間に合わない...」
(o;д;)「関連オブジェクト多くてテストできない...」
Slide 30
Slide 30 text
#ccc_m71
テスト - これは直せますか？
(o･д･)「...！」
Slide 31
Slide 31 text
#ccc_m71
テスト - これは直せますか？
(o･д･)「テストしたいコード部分は1クラスのみ」
(o･д･)「確かCSVファイルをDBっぽく使えるものがある」
(o･д･)「この部分だけ抽出してテストを書けないか？」
Slide 32
Slide 32 text
#ccc_m71
テスト - これは直せますか？
* 書けた
http://bit.ly/1srLofN
Slide 33
Slide 33 text
#ccc_m71
テスト - これは直せますか？
* やったこと(概要)
* JDK8が有効になっているeclipseを別で用意
* DBUnit＋MySQLでDB接続を再現
* テスト対象コードは本番に載せるものをほぼコピー
(o･д･)「後方互換バンザイ」
Slide 34
Slide 34 text
#ccc_m71
テスト - これは直せますか？
* 周囲への説明
(o･д･)「これがあれば開発者の画面テストがほぼ不要」
(*‘∀‘)「ほんとに？デグレ起こさない？」
(o･д･)「これが(修正前)→こうだったのが(赤)
→こうして(修正後)→こうじゃ(緑)」
(*‘∀‘)「まぁ最初のテストとしてはよさそうだね...」
(o･д･) (お、まずまずの感触)
Slide 35
Slide 35 text
#ccc_m71
テスト - これは直せますか？
* 結果
* 当該不具合についてはテストコードで修正の妥当性を
確認できるようになった
* 周囲にJUnitの存在と有用性を少しアピールできた
* 継続して実行する基盤を作る前に異動...
Slide 36
Slide 36 text
#ccc_m71
テスト - これは直せますか？(まとめ)
* 「テストが大事」という金科玉条にこだわると進めない
* できる範囲のことで全力を尽くす
* JDK8が有効な開発環境を用意する
* 自分が触るコードだけでもテストを書く
* 疑う人には実演が効果的
* 画面ぽちぽちにかかる時間を計っておくとなおよし
Slide 37
Slide 37 text
#ccc_m71
ここまでのまとめ - これはJavaですか？
(o･д･)「少しずつコードも読みやすくなってきた」
(o･д･)「(自分のところだけとはいえ)テストコードも書いて
デグレが起きづらくなってきた」
(o･д･)「この取り組みを広めたら製品はよりよくなるはず」
Slide 38
Slide 38 text
#ccc_m71
ここまでのまとめ - これはJavaですか？
＿人人人人人人人人人人人人人人＿
＞ そううまくいくわけがない ＜
Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y
Slide 39
Slide 39 text
#ccc_m71
周りに広める - これは使えますか？
* ここまででわかったこと
* 製品をよりよくするためにはコードの改善も必要
* 不要なコメントアウトの削除
* テストコードの追加 など
* 一部ではなく全体的な改善が製品の品質向上に
役立つはず
* とはいえいちいち前提を説明して回るのは面倒
Slide 40
Slide 40 text
#ccc_m71
周りに広める - これは使えますか？
(o･д･)「これをほかの人にも広めたい」
(o･д･)「ちょうどいい機会(略)あるし伝えてみようか」
・・・
(o･д･)「ということで、一気にとはいわずとも少しずつ
改善していくと全体の効率が云々」
Slide 41
Slide 41 text
#ccc_m71
周りに広める - これは使えますか？
(´ー｀)「それ、お客様の業務にとっては
どんなメリットがあるの？」
(o･д･)「直接は関係ありませんが、何か不具合が見つかった
際に修正する効率が上がります」
(´ー｀)「それ別にコードを書かなくても達成できるよね？」
Slide 42
Slide 42 text
#ccc_m71
周りに広める - これは使えますか？
(o･д･) (そうだけどさぁ)
(o･д･)「コードを書く手間はありますが
自動で確認できる以上は活用しない手はないかと」
(´ー｀)「動作確認は最悪外部の人に依頼できるし、
開発者は不具合修正に集中してほしい」
Slide 43
Slide 43 text
#ccc_m71
周りに広める - これは使えますか？
(o･д･) (そういう)
(o･д･) (話じゃ)
(o･д･) (ないんだ)
(o･д･) (YO!!!!!!!)
(o･д･) (とはいっても通じないんだろうなぁ)
(o･д･)「はい、わかりました」
Slide 44
Slide 44 text
#ccc_m71
周りに広める - これは使えますか？
(o･д･)「自分1人だと効果アピールが弱いのかな」
(o･д･)「仲間を増やして全体が効率化していることを
示せばさすがに認められるはず」
Slide 45
Slide 45 text
#ccc_m71
周りに広める - これは使えますか？
* また別の日
(o･д･)「こうすると開発が早くなるんだよー」
('ω') 「でもこれ書けるようになるまで時間かかるでしょ」
(o･д･)「そんなにかからんよ、普段書いてるコードと
ほとんど同じだし」
('ω') 「であれば目視確認のが早いんじゃない？慣れてるし...
それにテストコードが間違ってたらどうするの？」
(o･д･) (Oh...)
Slide 46
Slide 46 text
#ccc_m71
周りに広める - これは使えますか？
(o･д･)「もういいや...自分のとこだけがんばろ」
Slide 47
Slide 47 text
#ccc_m71
周りに広める - これは使えますか？(まとめ)
* コードを書いて品質を向上させるという考え方は
意外と少数派
* まずは自分の行動で範を示すしかない
(その前に異動したけど)
* 仲間を増やすにはわかりやすい実績が大事かもしれない
Slide 48
Slide 48 text
#ccc_m71
古のJava - これは変えられますか？
* 古いJavaのままでも「製品として成立させる」ことは可能
* セキュリティの話は省略
* Javaを使っている製品のライフサイクルなども考慮して
バージョンについて話す必要がある
* サポートが切れそうな製品のJavaを無理に上げる
必要があるか？
Slide 49
Slide 49 text
#ccc_m71
古のJava - これは変えられますか？
* 開発者個人として古のJavaに出会ったときに打てる手(1)
* 現行のJDKベースの開発環境を確保
* 製品に必須ではない部分(テストコード等)は
現行のJDKベースで書く
* 必須でないところは最低限の手間で書く
* IDEの設定でコメント部はできる限り薄い色にする
* 見えなければどうということはない
* だからJavaDoc形式でコメントアウトはやめろと
Slide 50
Slide 50 text
#ccc_m71
古のJava - これは変えられますか？
* 開発者個人として古のJavaに出会ったときに打てる手(2)
* 実績を積む
* 自分が手を入れた部分でデグレを起こさない
* 修正にかかるコスト(工数)の可視化
Slide 51
Slide 51 text
#ccc_m71
古のJava - これは変えられますか？
* 開発者個人として古のJavaに出会ったときに打てる手(3)
* 最善を学び続ける
* 取るべき手段をできるだけ増やす
* そのまま適用できるケースはないが
状況の中で最善を尽くすには最善を知るしかない
Slide 52
Slide 52 text
#ccc_m71
古のJava - これは変えられますか？(まとめ)
* 正しい製品を正しく作るために
* 今まで作り上げたものを直視する
* コメントアウトにも相応の事情がある
* コードを使って品質を向上させる手段があることを示す
* まずは自分のところからテストを書く
* 仕様はテストコードで示す勢い
* 最善を学び続ける
Slide 53
Slide 53 text
Thank You!
#ccc_m71