概要

イベント名 Object-Oriented Conference 2024
略称 OOC 2024
開催日時

• 前夜祭：2024年3月23日（土）17:00〜20:00
• 本編：2024年3月24日（日）10:30〜18:30

開催場所

• 前夜祭：docomo R&D OPEN LAB ODAIBA
• 本編：お茶の水女子大学

参加対象：ソフトウェア設計やプログラミングパラダイムなどに興味をもつ方
主催者 OOC実行委員会
X（旧Twitter） @ooc_dev

参加目的

タイムテーブル

https://fortee.jp/oocon-2024/timetable

# ソフトウェアを作りたかった私へ 〜変更しやすいコードを書くコツが見えてきた今伝えられること〜

• speaker:：nikkieさん

intro

• ソフトウェアの２つの価値
  • 振る舞い：ユーザーが認知
  • 構造：開発者が認知
• 今ある知識だけでなんとかしようとするとうまくいかない「セルフ分からん殺し」
  →外側に知識を求めていくしか

main

指針を得る

シンプル

• シンプル≠簡単
• シンプル=LEGOブロック、「もつれていない、絡み合っていない」
  • 小さいものを積み上げていけばどんな大きいものでも作れる
  • 小さな部品を組み立てて作りたい機能を作る

クラスをどう使うか

• クラス：データとロジックをまとめるもの
  • 文法を学べば、処理系が動作するクラスは書ける
  • コードの構造としてよいクラスも悪いクラスも、同様に動作してしまう
  • 良し悪しの 判断基準 「まとめているか」

小さな部品の作り方

小さい責務とは

• 単一責任原則：モジュールを変更するべき理由は１つだけであるべき
• クラスの責務：何かの法則で機械的に決まるものではなく、将来の保守開発への想像から恣意的に生み出すもの
• 将来のコードの変更を想像 して決める（保守、拡張）
• 単一責任が現実と合わなくなったら修正すればよいのか！

入出力と計算判断

過去の振り返り

• コードの行数に注目していた（N行くらいだから関数にしよう）
• コードの 目的 （入出力、計算判断）に盲目でした
• 混ぜていたので、計算だけ使えない
• 入出力と計算判断を分けていく
  • 関数の抽出
  • 関数のインライン化

作ると使うを分ける

生成と仕様

• 生成（作る）：処理が依存するモノ（例： client）を作ること
  • 使う時に作るように実装しない
  • 依存するモノは外で作られて与えられる （依存性注入💉）
  • 操作するだけ
• 使用（使う）：処理が依存するモノを使うこと

小さな部品の作り方の気付き

• 小さい責務は 恣意的 に決める
• 小さく切り出す際は、コードの行数だけでなく 目的 にも目を向ける（入出力、計算）
• 依存するモノを引数で渡す（依存性注入）

難所から得た学び

• インターフェースで 使い方 を小さく示す
• 具象ではなく、インターフェースに依存する（依存性注入からの発展）
• 継承は最後の選択肢（インターフェースや委譲を使う）

conclusion

変更しやすいコードを書くコツが見えてきた今伝えられること

• 単一責務は恣意的
• 入出力と計算判断を 分ける
• 使うと作るを 分ける
• インターフェースとは 使い方。使うと作るを分けた先
• 継承は（理解するまでは）初手で使ってはいけません

チーム開発でデプロイ頻度を上げるための設計とタスク分割

• speaker：ことみんさん

• なぜデプロイ頻度を上げたいか

  • 開発リスク低減に繋がる
  • デプロイ頻度は開発生産性をの指標である

• 日付ごとにversionが違う処理：そのXデーごとのclassにまとめてみる＆どのXデーを使うかの処理を作る

  • main側のロジックの引数がXデーだけになる
  • 余分なif分岐も減る

• タスク分割の流れ例

  1. インターフェースを先に作る
  2. その後クラスを作成
  3. テストを作成
  • 一旦function名だけでも立てて側を作る
  • 2,3をfunction単位などの細かいタスクに分割をしてもよい
  • デプロイ頻度向上できる

• テストコードを各メリット

  • 慣れていないメンバーにも安心して実装タスクを任せられる
  • テストが通るように実装してもらえば良い

• 命名変更による差分がデカくなる場合：それのためだけのPRをつくることで別PRで本質を設定できる

まとめ

• 適切な関心事でインターフェースを作成
• インターフェースを先にリリースすると、タスク分割しやすい
• インターフェースとテストコードが有ると、他の人に安心してタスクを任せてリリースできる

せっかくモデル図描くのなら、嬉しいことが多い方がいいよね！

• speaker：久保秋 真 さん

どうしてモデルを作らなくなってきたか

• UMLやオブジェクト指向というワードの検索ボリュームはここ10-20年でかなり減ってきている
• 今は頼れる環境がある
  • 立地なフレームワークとサポートライブラリがある
• ベースを継承すれば難しいことを考えずにモデルを使用できる
• モデルの関心はドメインモデルへ移った
  • 業務フロービジネスロジック
  • 会社の利益構造やDX
• そしてDDDがやってきた
• 使えるドメインモデルもすでにある分野では安心してそれを使えば良い
  • 似たサイト資産があれば、同じような作りを提案できる
• 遵法な商売はどこでも似ていることがわかった
  • 販売、財務、給与、eコマース,,,
    • 楽天にお店を出すなら、店舗と品物のデータを作れば済む
  • だからSAPやSalesforceが席巻した
• 実装になってから考えることが減った
  • すぐに実装できるなら作って動くものをユーザーに見てもらえる
    • 設計書を作って「これでちゃんと作るから」って約束しなくても済む
• フレームワークとドメインモデルが揃ったからモデルは使うだけ。アプリのフロントエンドを考えればよいということが増えた。
• モデルを作るにしてもツールが一長一短
  • ドローイングツール
  • PlantUML
  • モデリングツール
• まとめ
  • 「モデルは使う時代」になった
    • 業務ドメインの既存モデル＋リッチなフレームワークとライブラリ
  • 実装して試す方がはやくなった
    • 大部分の設計が済んでいるのなら、すぐ実装可能
    • UIはモデルで書くよりコードを試したほうが可否が分かる
    • 設計書とかモデル図が、みんな同じに見える
  • でもモデルは必要とされている

どんな力を備えるべきか

• 今はコードを出済むことを別の表現でも示せるように
• わかりにくいから図にする力
• 図のほうが分かりやすいを活かすには
  • モデルの効用を知る
  • それに見合う整理と表現になれておく

オブジェクト指向CSSが叶えたかったことと、CSSのいま

• speaker：しんくうさん

• docs：https://speakerdeck.com/shinkufencer/the-aims-of-object-oriented-css-and-the-current-state-of-css-usage

• 2009年頃のCSSの課題感

  • 再利用性の低さと記述量の肥大化
  • 適用版の理解が何回で壊れるUI

• OOCSSの考え方

  • webページをレゴのように考える
  • レゴ１つ１つを Object という

• OOCSSの原則

  • 構造とスキンの分離
  • コンテナとコンテンツの分離

• OOCSSから命名規則

  • BEM：(例)
    • Block：Elementの集合
    • Element：要素
    • Modifier：条件違いの要素
  • その他：SMACSS,FLOCSS,SUITCSS
  • 見えてきた課題
    • 意味を区別できるように、名前被りがないようにする→命名の難易度が高い
    • UI Componentフレームワークの出現：React、Vue
      • CSS in JSやCSS Moduleの登場

• 2023年の新しい仕様

  • @layer
  • @scope

• そしてこれから

  • ユーティリティファーストな構成
    • 「パーツの意味」ではなく「スタイリングの機能単位」にCSSの名前を利用
    • tailwindを利用するすべてのシステムが一貫して同じclass名称を使うので利用の気遣いが減る
    • 全体に適用させるための「テーマ」のようなスタイリングに対しても相性がいいため、ユーティリティファーストのアプローチの利点も高い

（UMTP版）モデリング漫才万歳！ ミル〇ボーイ「コーンフレーク」から始めるモデリング会話入門

• speaker：オグロ・オオモリさん

おもろい漫才だった。

ドメイン・ファーストで考える問題解決に役立つモデル設計

• speaker：Shinichiroさん

モデルとはなにか

• 典型的なモデルの例は地図
  • それぞれの目的のために特定の側面を強調したり、無視している

モデルは現実世界の事象や物事のコピーではない

• 全てのモデルには「目的」があり、その達成に必要な情報のみをふくむ
• 本質的には「抽象化」
• 抽象化の目的は曖昧にすることではない
  • ある実態を簡略化して、重要でない詳細を省いたもの
  • 複雑なものに対して考えたり操作したりするのを用意にする

ソフトウェア開発で扱われるモデル

データモデル

ドメインモデル

• 業務ドメインに特化したソフトウェアモデル
• オブジェクトモデルとして実装されることが多く、扱うデータや振る舞いを業務的に正確な意味で保持する

ドメインオブジェクト

• 「全てのオブジェクトはなんらかのクラスのインスタンスである」
• DTOのように単にデータを保持するだけでなくそのデータに関連する振る舞い(メソッド・関数)を併せ持つ(抽象データ型)

データモデルとドメインモデルの違いが曖昧になる原因

1. DB設計から始める開発アプローチ
2. ORM利用
3. スキーマ駆動開発の一般化の影響
4. 開発者ドメインの知識不足

戦術的プログラミング

• 機能を動作させることに焦点を当てたプログラミング
• 「何を解決したいか」＜「どう実現できるのか」

戦略的プログラミング

• いくつかの設計を試して最もクリーンなものを選択する
• 将来のシステム拡張を想定
• システムを改善するために時間を投資
• 最速＜最善

まとめ：

オブジェクト指向コードレビューの新しいアプローチ

• speaker：akkieさん

オブジェクト指向コードレビュー

コードレビューの７つの観点

Design

• 設計、アーキテクチャに関する指摘
• 該当ケース
  • アーキテクチャ原則違反
  • 単一責任の原則違反
  • 密結合
  • 低凝集

Simplicity

理解容易性、可読性

• 該当ケース
  • 分岐が多い、ネストが深いif
  • 複雑な三項演算子
  • filter,mapなどのObject整形文
  • 冗長なSQL

Naming

クラス、メソッド、変数などの命名に関する指摘

• 該当ケース
  • 振る舞いに一致しない変数名
  • 責務と一致しない関数名
  • 命名規則・英文法の誤り

Code Style

コードスタイルに関する指摘

• 該当ケース
  • 静的解析違反
    • Linter,Formatterで解決に向かう
  • 不適切なアクセス修飾子
  • コーディング規約違反

Functionality

機能要求に対する指摘

• 該当ケース
  • 外部機能が充足していない
  • 設計書の機能と異なっている
  • パフォーマンス低下の懸念
  • 不要なAPIデータが送信されてる

Test

• 該当ケース
  • 対象メソッドがテストされていない
  • テストパターンが網羅されていない
  • 定数がテストクラスに定義されている

Document

• 該当ケース
  • Docやコメント内容が不適切、不正確
  • READMEなどの関連ドキュメントの漏れ

AIコードレビュー

PR-Agent

• OpenAI API Key
• Github personal access token
• Github Actions