s平面の左側

左側なので安定してます（制御工学の話は出てきません）

Object Oriented Conference に行ってきました #ooc_2020

技術／設計 イベント・勉強会

2/16（日）に Object Oriented Conference 2020 に行ってきました。 募集は随分前でしたが、ずっと楽しみにしていたカンファレンスでした。

ooc.dev

聴講セッション

聞きながらのメモ等はツイートに返信していく形で書いています。

タイムテーブルを見ても、どの発表も聞きたいものばかりで選ぶのが辛かったです。

keynote: Object-Oriented Diversity

DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか

Chatworkのドメインをモデリングした

VOYAGE GROUP流開発文化

READYFORにおける複雑なドメインとレガシーシステムとの戦い方

数理的システム設計-ビジネスと技術制約を繋ぐ手法-

概念投影によるオブジェクト指向設計の考え方とその方法

「モジュールとしてのマイクロサービス」と「分割単位としてのドメイン」について考える

以下、携帯の充電が切れたためツイートが出来なかったので、ローカルでメモを取っていました。

fortee.jp

  • 割り勘のドメインエキスパートこと、かとじゅんさん
  • マイクロサービスは何か？を突き詰めていくと、広義には部品のこと
    • モジュールもオブジェクトの一種
    • 50年来、ソフトウェア以外の領域でも「モジュール化」について取り組まれてきた
  • マイクロサービスアーキテクチャとは、単一のアプリケーションを小さなサービス群を組み合わせて構成する設計手法
    • Web APIなどの機構を介して相互通信する
    • 関心事によって分割されていく
    • 潤沢な計算機リソース、クラウドサービスの台頭によって、実現できるようになった
  • 一枚岩のアーキテクチャでは変更の影響範囲を特定するのに時間がかかってしまう
    • 「依存が飛び散ってしまっている」
    • 結果、テストの範囲が広くなってしまいがち
  • 分業形態による問題、コンウェイの法則だ
    • バッチ処理にあわせて堅い言語を使いたい、のような要求にあわせた適切な技術選択が難しくなる。
    • 「自己組織化出来ない」
  • マイクロサービスアーキテクチャによって、コードやDBも共有しない独立したコンポーネントになった
    • 問題として、横断的な処理・業務フローがあった場合に、ひとつのトランザクションに閉じられなくなってしまう
  • マイクロサービスアーキテクチャの特徴
    • サービスを通じたコンポーネント（古い言い方で「モジュール」）化
    • モジュールの歴史
      • ハードウェア、ソフトウェアを構成する個々の部品。
  • モジュールの例
    • 数の加算的グループの部分集合
      • モジュールは入れ子構造を持つ
    • 複雑性を軽減するために使ってきた手法である
  • モジュール間では独立している
    • 関心が強いものは凝集、関心が弱いものは分離する
  • PHPだと全てがpublicなので辛い。。。
    • モジュール化できない
    • 全てをpublicにするのはモジュールではない
    • 「専門的な知識を持たずに、労力だけを得るのが目的」
  • 明示的な情報≒インターフェース、プロトコル
    • 事前に合意されていなければいけない
    • 容易に変更できない
    • これが守られていれば、内部の変更をいちいち隣にお伺いをたてる必要はない
  • 明示的なデザイン・ルール
  • 隠されたデザイン・パラメータ
    • 「モジュール化されていないとベロシティが維持できない、アジャイルになれない、アジリティが担保できない」
    • 「モジュールがアジャイルを支える基盤になる」という考え方、いいなあ
  • WIKISPEED→ハードウェア領域でスクラムをやっている
    • 毎週新しいモデルを作り出す
      • c.f.) ポルシェは8ヶ月8年ごとに新しいモデル （2020-02-18 修正、@j5ik2oさんご本人からご指摘いただきました。ありがとうございます。）
    • 製造ラインにアーキテクチャを適用した
    • ムーアの法則、CPUのコア数と同じ、製造を並行化できる
  • モジュール化のオペレータ=設計の手段
    • 上位・下位を意識すること
    • 置き換える際に、他のモジュールは変更を関知しない
      • 包括的なデザインルールが担保しているため
  • モジュール型製品の場合、横断的な問題（例：静かさを向上させようとする）に取り組む際には、異なるチームどうしで連携する必要がある
    • モジュールPOどうしがメタスクラムをやることがある
    • モジュールの中に閉じた設計改善は密にコミュニケーションをとっていく
    • モジュール間で設計の改善（デザインルール自体の改善）をする際には疎なコミュニケーションにする
  • 「ソフトウェア開発はドメインとを中心にしなくても可能だが、それではビジネス変化に適応できない」
  • ドメインがモジュールの分割基準になるか？→必ずしもそうではない
    • 問題の領域と解決の領域（境界づけられたコンテキスト）は異なる
  • 「ソフトウェアは会話でできている」
  • 分割はビジネスの変化に対応できるようになるが、システムは複雑になる
    • 過剰な分割することで、変更に弱くなる、保守性が落ちることにつながる
    • フィードバックを得ながらいい落とし所を探っていく
  • モジュラー・モノリス、構造化されたモノリス
    • 分け過ぎたら戻すのは大変、もどせない
  • フロントエンド・モノリスが新たな課題
    • その解法のひとつにマイクロフロントエンドがある
    • Spotify, IKEAくらいしかやってない
  • 「YAGNIを真面目にやりすぎると、大きなコストに直面する」

オブジェクト指向プログラミングの現在・過去・未来

fortee.jp

  • 増田さんがオブジェクト指向プログラミングに向き合った内容
    • 増田さん、どんな言語も好き
  • 「オブジェクト指向プログラミングとはなにか？」
    • 「簡単なこと。これが難しくなってしまうような捉え方をしてしまうのが問題。」
  • データの抽象化
    • 抽象データ型が導くモジュール構造←手続き型プログラミングと分ける決定的な違い
      • 厳密にはここまでは抽象データ型プログラミング
      • OOPはそこにポリモーフィズムを導く部分型、動的ディスパッチが加わる
  • 「型」と「モジュール」という考え方でOOPを捉える
    • 「型」をプログラミングの単位にする
  • 過去、現在、未来（2, 30年先）変わらない
  • 公理型と定義型の考えにつながる気がする
    • 型 = 値に対して何を実行できるのか + 有効な値の範囲
      • 制約と振る舞いの話っぽい
  • 抽象化するから本質を抜き出さないといけない
    • 型・データ抽象は思考の話であって、実装の話ではない
    • クラスはその実装手段
  • 型とクラスとモジュールが一致しているのがOOP
  • OOPを乱暴に単純化すると「型というものを意識しながらプログラミングすること」
  • 型は可能な範囲を制限するより、可能な操作を定義することが本質
    • char[] → 具体的なデータ表現
    • string → 文字の配列への可能な操作
  • プログラミングが楽で安全になる
    • ただ、これをやりたいがために抽象データ型が提唱されたわけではない
  • データ抽象（型）で何が嬉しいか？
    • 型は問題領域を記述する「語彙」を提供する
    • 型は計算のアイデアの表現である
    • 型は問題領域の記述とプログラムの構造を直接的にマップする
    • 型はソフトウェア仕様の記述手段である（自己文書化）
    • 型で関心事を明示的に表現する
  • OOから生まれたアジャイルの発想→型で仕様を記述せよ
    • 意図の表現の手段が「型」
  • 型を使った契約による設計は、ソフトウェアの信頼性を向上させる
  • FORTRANの功績、ビット列を整数型と実数型に分類して扱えるようになった
  • class構文を使った手続き的なモジュール構造が流行ってしまった
  • ジェネリクスの登場等で2004年、Javaは真にオブジェクト言語になった
  • OOADは型を見失ったために、普及しなかった
  • オブジェクト指向プログラミング自体の進化
    • IDEの恩恵があって使えるプログラミングスタイルである

感想など

テーマ自体が「オブジェクト指向」と抽象度の高いものなので、必然的にトーク内容も抽象度が高いものが揃っていました。 抽象度が高いということは、広いケースに適用できる（対象ドメインやプログラミング言語などに依存しない）一方で、理解も容易ではありません。

今回さまざまなセッションを聴講していて、私自身はまだまだ抽象概念を理解するための知識や思考の整理が足りていない、ということを痛感しました。 最近はずっとプラクティカルな議論・思考に終始してしまっており、フィロソフィカルな議論・思考をする足腰がすっかり弱まっているのを感じました。 これからしばらくは、インプット量を増やしつつ思考を深める、というプロセスを重んじたいと思います。

最後に、このような気づきを与えてくれたカンファレンスが開催されたことに感謝の気持ちを表明したいです。 これもスタッフの方々、ならびに協賛してくださったスポンサー各社様のおかげです。 本当に、ありがとうございました！