JJUG CCC 2019 Fallに参加してきました．

Javaを初めて半年，イベントに初参加！！

Javaで学ぶオブジェクト指向プログラミングの基礎知識

発表者の資料

• オブジェクト指向の考え方がソフトウェア開発に活かせる
• 増田さんの考えるオブジェクト指向プログラミングのこだわり
  • モジュール性
    • 型(値の種類)でプログラムを分割
    • 型でモジュールを作る
  • シームレス性
    • 一連の活動の継ぎ目をなくす開発手法
• 持ち帰ってほしい言葉
  • 型
  • カプセル化
• 2つのモード
  • モード1
    • 定義済みの型だけを使う
    • 標準ライブラリや組み込み型のみ
    • 型の消費者
  • モード2
    • 独自の型を定義する
    • 型の生産者
• オブジェクト指向プログラミングのスキルアップとは
  • モード1からモード2へ移行すること
  • クラス設計のスキル
  • 独自の型の発見と改良のスキル
• まとめ
  • 型という概念的なものをクラスへカプセル化
  • クラスには値の範囲の定義と値の操作の定義を与え具体化

感想

事前に考えてた内容とは全然違ったけどかなり面白かった

13:30～14:15　開け！ドメイン駆動設計の扉

発表者の資料(無いよ)

概要

ドメイン駆動設計とは何か？
どう良いのか？
どのようにやったらいいのか？(ここら辺は速すぎて全然メモれなかった)

聞いた時のメモ

• モチベーション

• なぜドメイン駆動設計か？

  • 非ドメイン駆動設計とは
    • コードの森で迷う
    • 関連する実装が散らばる

• 目的

  • ソフトウェアの利用者とコードが地続きになること
  • 開発速度ではなく，保守性を高めるプラクティス

• ドメイン駆動設計とは

  • ドメインとは
    • ソフトウェアに含まれる範囲はどこか
  • ドメインとコードがモデルを通して，つながる
    • 反復的な開発になる

• 知識の上流

  • ドメインエキスパート
    • 作業の主体者
    • 重要なことを知っている人
    • 開発者がドメインを決める上で，相談する人
  • 開発者はドメインエキスパートと会話が必要
  • ユビキタス言語を使う
    • だれにでも通じる言葉
  • 相手の言語を使うことで，理解
    • 互いの理解を深める

• 構成要素

  • 早すぎてメモれない．．

• 深いモデルへ

  • 始めから全ては把握できない

• 会話の力が大事

  • 刹那的なニュアンスをキャッチする

• リファクタリングを嫌わない

• まとめ

• ドメイン駆動設計とは当たり前のことを当たり前に実践するためのプラクティス

感想

「Javaで学ぶオブジェクト指向プログラミングの基礎知識」と通じる話もあり，面白かった．
速すぎて付いていけない点も多かった．

14:30～15:15　JUnit再入門

発表者の資料

メモ

• なぜテストコードを書くのか
  • 回帰テストが可能になるから
  • 高い信頼性
  • 属人性を残さない
  • デバック完了を実装時に確認
  • デバックが楽しい
    • 人間に間違いを指摘されると心理的なダメージが．．．．
• テストコツ
  • テストを先に書く
    • テスト失敗を確認してから実装
    • 失敗を担保してから実装
  • 分かりやすいテスト名を付ける
    • 日本語でテスト名をかく
      • チームのメンバーが全員日本語に堪能であることが条件
    • assertionを書き過ぎない
      • ほどほどにまとまった単位で書く
      • 必要に応じてassertAllを利用
    • カバレッジ（網羅度）にこだわり過ぎない
      • 実証済みコードはテストしない
      • getter，setterのテストは不要

感想

前半部分は初心者向けの内容，後半部分が大事だと感じた
現状，テストファーストには開発できていないため，改善したいと感じた．
特にUIのテストに取り組みたい．

16:45～17:30　新卒3年目が立ち向かったお名前.comでの超巨大レガシーシステム脱却の事例

発表者の資料

メモ

• レガシーなシステムとは
• 意図したとおりには動作
• 内部のコードが複雑で，メンテしずらい
• 保守コストが高い
• レガシーなシステムからの脱却の問題点
• 仕様に関するドキュメントがない（仕様）
• 複雑化している箇所があり，修正が困難(実装)
  • ピュアなJavaで実装
  • 意図の分かりずらい実装
  • 生クエリが定義
  • 設定情報がべた書き
  • クラスの責任があいまい
• 単体テストのコードがない(テスト)
• 解決方法
• 仕様に関するドキュメントがない(仕様)
  • wikiにまとめて共有
  • gitにマジリク時にコードの詳細な情報を残す
• 複雑化している箇所があり，修正が困難(実装)
  • ピュアなJavaで実装
  • JDKの選定
  • フレームワークの選定
  • Web APIアーキティクチャの選定
  • 意図が分かりずらい実装
  • コードレビューの実施による属人性の防止
  • フレームワークに従った標準的な実装
  • 生クエリが定義
  • フレームワークの導入
  • 設定情報がべた書き
  • 設定情報をYALMに統一
  • クラスの責任
  • 各レイヤーごとに責任を明確化
  • 他のモジュールに影響しない設計
• 単体テストのコードがない
  • JUnitの導入
  • Mockitoの導入
• 今後に向けて
• ルールの厳守や定期的なメンテが必要
• さもないと，レガシー化する

感想

社内のシステムを眺めることが多いですが，実装が分かりずらいことが多い
レガシーなシステムとの戦う機会は多いと感じている．（いずれ改修も．．）
戦い方の参考にさせていただきます！！

イベント全体の感想

初心者向けの講演に参加していたが，情報量が多く付いていけないことが多かった．
→スライド枚数を制限するなど，情報量を絞ってほしい
お昼ご飯が豪華でビックリした
→おいしく頂きました．ありがとうございました．
Gradleのお話も聞きたかった
→Gradle を完全に理解した人が、何も分からなくなるための第一歩
UIのテストの話を重点的に聞いてみたい
←今関心があるから