【参加した】JJUG CCC 2023 Spring
こんにちは！
今回もいい刺激もらってきました！！
目次
- 目次
- これに参加しました
- タイムテーブル
- 聴講したセッション
- セッションごとのメモ
これに参加しました
今回からオフライン開催が復活しましたね。
ライブ配信（一部はオフラインのみ）もあるのは遠方の自分としてはありがたいです。
タイムテーブル
https://sessionize.com/api/v2/y7inyq6y/view/GridSmart
聴講したセッション
- 金融系子会社でレガシーシステムしか作ったことないけど、モダン開発に挑戦してみた (by 汐月 麻理佳さん)
- JJUGコミュニティセッション: JJUGで成長した元講師なエンジニアの約10年よもやま話 (by 多田 真敏さん)
- これだけは知っておきたいクラス設計の基礎知識 (by 増田 亨さん)
- 複雑性に立ち向かうためのサーバーサイドコード分割 (by Hirokuni Maetaさん)
- Webアプリケーションを作りましょう (by irofさん)
興味のあるセッションが同じ時間帯でかぶってても、
ライブ配信だから追っかけてみれるから助かるー
今回自分的には新しい技術、よりもリファクタリングとかに興味があったみたい。
セッションごとのメモ
金融系子会社でレガシーシステムしか作ったことないけど、モダン開発に挑戦してみた (by 汐月 麻理佳さん)
セッション資料
MEMO
モダン開発へのチャレンジ
レガシー⇒PoC⇒モダン開発
生命保険システムの特徴
- ライフサイクルが長い
- 高い品質を求められる
- 巨大なシステム
技術の壁
- 巨大なシステム＆大人数で開発
- 技術的な部分が社内独自FWに隠ぺいされていて、見えない。
- 設計スキルがなくても作れてしまう
- 自動テストコードは共通コードのみで、安定志向が強い
⇒め、めっちゃうちの職場それーーーーー！！！
文化の壁
- コード変更に承認がいる。
- システム巨大で影響範囲が大きく改善にしにくい
- 新しいことを学ぶモチベーションが維持しにくい
⇒め、めっちゃうｃ（略
取り組み
- ブログだけでなく、公式ドキュメント、書式で知識を担保する
- 基礎知識の習得と合わせて、実践が大事！
- １度ではなく繰り返し
- 最初はシンプルな商品＆業務仕様も簡単なものを。
- 手続き型⇒Restful＆DDDは「考え方の改革」に近い
- 改善のためにテストコードを書くことにもなれるのも必要
- 新しいことを学ぶ文化の醸成
- 原典にあたる
- もくもく会
- 資格取得
- 繰り返しおこなう
- 専任で参加
感想
今いる職場では自社請け開発ではないので、
モダン開発をやりたいという希望を通すのはほぼ不可能。
どこにやりがいを見つけたらいいかなーと正直ずっと悩んでいましたが
ここ最近考えが少し変わってきていまして。
でも、独自FWの中身を理解してクラス設計を学んだり、
リファクタリングのやり方を身に着けて、レガシーなコードに対して
改善していくことはできるんじゃないかと思っていて。
具体的にこうやっていこう！みたいなのはモヤモヤレベルでしか
思いついてないんだけど、はっきり言語化できるようにして
取り組んでいきたいなと考えています。今回のこのセッションを聴いて
その気持ちが強くなった感じ。がんばろう！
JJUGコミュニティセッション: JJUGで成長した元講師なエンジニアの約10年よもやま話 (by 多田 真敏さん)
セッション資料
MEMO
JJUGってなに？
JUG=Java User Group
JJUG=Japan Java User Group
何してるの？
- 月１でナイトセミナー・・・最新技術情報を提供
- 年２回のCCC開催・・・現場の知見
- 不定期で仕様勉強会・・・JavaSEとか
- 地方JUG（大阪だと関ジャバ）サポート（イベントへの講師派遣、宣伝、費用など）
JJUG 参加の心得①：まずは参加してみよう
- わからないセッションがあってもOK
- 最初はわからなくても、何年か後に役に立つことがある。
- 登壇者に経緯をはらって
- 発表してくださってくれていることに感謝を！
- 登壇者がよく言っているキーワードを覚える。余裕あれば調べる
- 登壇者がRTしたWeb記事を読む。よくRTしていたり、会話してくれる人にもチェック
JJUG 参加の心得②： 発信してみよう
JJUG 参加の心得③： 登壇してみよう
- まずはCCCの「初心者枠」にチャレンジ
- ○○やってみた系
- これからはやりそうなライブラリ紹介
- 現場での苦労話
登壇で得られたもの
- 徹底的に調べるようになった
- 仲間ができた
- 様々な技術が身に付いた
- お給料あがった
- QiitaのSpringタグで年間１位になった
ドキュメント翻訳をする理由
- 技術の勉強になる
- 英語の勉強になる
- 後の自分のためになる
- 同僚のためになる
- 世の人のためになる
感想
お仕事もお忙しいであろう中で10年近く、計16回も登壇できるってすごいな。
バイタリティ的なところ、熱意的なところ。
登壇される方は皆さん本当にすごい。
ためになる知見を提供してくれてありがとうございます！
「新しい流行りそうなライブラリで○○やってみた」とかやってみたいけど
登壇者の皆さんはどーやって見つけていらっしゃるのだろうか。
そういう嗅覚身につけたいけど、日々どんなこと意識してるのかな。
今回のイベントなどがあると自社の若い子たちに共有しては、
「わかんなくてもいいからまずは時間があったら参加してみてほしい。
（多田さんおっしゃるとおり）後になって役に立つかもしれないし、
何より刺激を受けるはずだから。」
と伝えています。
いつか若い子達のほうから「こんなイベントあるんすよー！」って
共有してきてほしいなーとひそかに期待しながら
懲りずに情報発信をしていこうと思う所存です。
これだけは知っておきたいクラス設計の基礎知識 (by 増田 亨さん)
セッション資料
MEMO
ソフトウェア設計
- プログラム⇒クラス設計（本セッションはこの部分の話）
- 永続化⇒テーブル設計
- 通信⇒プロトコル設計
ステップアップする
- 初級：クラス構文を使って読み書きできる
- 中級：既存のクラス設計を参考になんとなくマネできる
- 上級：なぜそういう設計をするのか、なぜそういう設計を避けるか、複数の判断軸を持つ
今の自分ってどのあたりだろう。中級の下くらいかな？
技術習得のシナリオ
- セミナーなどから情報を収集して
- 自分の体験や知識関連付けて
- 手を動かして習熟、繰り返して体で覚える
プログラムの設計：分けてつなぐ
- 「分けて」整理する
- 入出力と計算判断は分ける
- 「つないで」動かす
分けてつなぐための７つの知識
Keyword
感想
クラス設計をするときにこうやって落とし込んでいく
ってなんとなく頭にあったものが見事に言語化されて
セッション聴いていてとても腹落ちして痛快でした。
腹落ちしたけど、すぐに実践できるかは別物なので
「手を動かして実践し、繰り返して体に覚えさせる」を
やっていきたいと思います！
複雑性に立ち向かうためのサーバーサイドコード分割 (by Hirokuni Maetaさん)
セッション資料
MEMO
機能ごとにパッケージに分割
機能間でかかわらないなら、コード間も関わらない、依存しない コードだけを元に分割しても、複雑性を解決するとは考えづらい
Keyword
- ArchUnit
- https://www.archunit.org/
依存関係のテストができる
- https://www.archunit.org/
- メンタルモデル
- http://mentalmodel.jp/
「誰もが無自覚に持っている「自分は/世界はこういうものだ」という人生全般の行動の起点になっている信念・思い込み」のこと。
PM(Product Manager)のメンタルモデルってことは「PMが無自覚に持っている信念・思い込み」 そこと一致しているかどうかを確認しようってことか。なるほど。
- http://mentalmodel.jp/
なぜ機能単位でコード分割するのか？
- 機能に対応したパッケージ分けはすでにある程度されている
- 新規機能の開発と並行で進められる
- 分割の基準を一から考える必要がない
アプリを使う側と使う側で必要とされる情報や処理は変わる
- 「PMのメンタルモデル」は必ず意識して分割をおこなう
- 違和感がないかPMに確認して握る
質疑応答
分割するにあたってデグレードとかのテストも必要だと思うが
テストコードはそろってる状態だったか？
⇒そろってるし、専任のQA部隊がkintone内にいる。
「ソースコード３５万行」について
コード分割をした結果、どれくらいの行数になった？
⇒コード分割をし始めているところなので、
どれくらい減ったかまでは計測していないとのこと
ちなみにプロダクトコード自体は１０万行、テストコード含めると３５万行だそうです。
ソースコード行数以外で、コードの複雑性を定量的に判断したりしているか？
ここは納得する指標はまだなく、手探りで定性的なものが中心の状態。
まずはコード分割を進めるところから。
感想
「コードだけを元に分割しても、複雑性を解決するとは考えづらい」
これはもうホントソレですね。
「似てるから」と闇雲にコードだけ見てコード分割、共通化するのは危険。
改善にあたってPoCプロジェクトを立ち上げられる
仕組みがある組織ってすばらしいと思いました。
その一方で仕組みを単に考えるだけでは机上の空論で
そこから実現のために会社に承認もらうまで
途方もないエネルギーが必要だったのだろうなぁと思いはせたりしました。
何かを変えることは簡単なことじゃない。
でもがんばって変えていきたいよね。
Webアプリケーションを作りましょう (by irofさん)
MEMO
ライブコーディング(25分)
流れはこんな感じ。
- git initでリポジトリ作成
- gradleの設定
- Spring Initializrで生成
- git.ignore作成.ideaファイルを除外
- SpringBootが動くことのテスト
- Controllerを作って動くことのテスト
- JSONで返ってくることのテスト
- DAOを作ってテスト
- RESTApplicationのテスト
↑こんだけのことをたったの２５分でやってしまうってすごい。
すごいスピードでアプリケーションができあがっていく様は圧巻でした。
感想①：IDEのショートカット、コードアシストを最大限利用している
今回コーディングで使っていたIDEは「IntteliJ IDEA」。
ライブコーディング中、ショートカットやコードアシストを
最大限利用していて、その結果速く、正確にコードを書くことに成功している。
普段仕事はeclipse使ってるけど、ここまで使いこなせてない。
ショートカット集を皆で共有するようにしようかな。
感想②：サンプルのアプリケーションだけど、適当じゃない。
めまぐるしくライブコーディングをする中でも
一つ一つ「なぜこうしているか」を言語化して説明しているところがすごい。
今回作ったやり方以外にも複数選択肢がある。
どれを選んでもいいけど「なぜそれを使ったか」は説明できるようになろう
これは刺さりました。すべてにいえること。
コーディングに限った話じゃないですね。
感想③：テストありきでモノづくりをしている
「今回のテストはポカミスを見つけるためにしている」そうですが
テストを小さく作るってところが大事だなーと改めて思いました。
ポカミスが重なるとドはまりの原因になる。
ドはまりを防ぐためにテストを都度作って「落ちる」⇒「OK」をテストを通して
段階的に動作が担保されていくことを確認していた。
実際の仕事でも活かしていきたいです。
