- 2020/02/16に御茶ノ水女子大で行われたオブジェクト指向がテーマのカンファレンスに参加してきたので、レポ投下。
- Object-Oriented Conference概要。
- 敬称略です。
- 駆け足でメモしたところがかなりあるので、間違っているところ、あいまいな部分かなりあると思います。
- 詳細、正確な情報はYOUTUBEアーカイブをご覧ください!(自分も見返さなければ)(いつまであるかは不明)
基調講演
keynote: Object-Oriented Diversity
登壇者
成瀬 允宣(@nrslib)
概要
スライド
レポート
あなたのオブジェクト指向はなんですか?
『多様性』をうまく扱うために、ポリモーフィズム(多態性)がある。
ポリモーフィズムは前後関係による文脈が大事、
- 前後関係をうまく使うのがポリモーフィズム。
- 前後関係 は英語で『コンテキスト』。
- 一連の中のコンテキストを恐れずに使ってほしい。
- コンテキストを理解することが大切、多様性をうまく扱う。
- コンテキストを理解すると、素直なプログラムが書ける。
ポリモーフィズムを恐れない為のアドバイス
- 対話するとき
- 例えば、カンファレンスで質疑応答するとき
- もしかして、質問する人がつよつよにみえてる??まさかりコワイよね。
- 質問が出るということは自己表現したいということ。
- 好奇心旺盛になっている子供と一緒。そう思うと見え方が変わってくる。
- もしかして、質問する人がつよつよにみえてる??まさかりコワイよね。
- 例えば、カンファレンスで質疑応答するとき
- コンテキスト、来歴を理解してあげましょう。
所感
- ホールAでの発表だったが、すでに満席でYoutube配信をホールBでみた。
- オブジェクト指向に関わらず、コンテキスト(前後関係)を理解するのはとても大切。来歴を理解することで、争いや誤解が生まれなくなる(はず)。生まれたとしても、建設的に話ができるのでは。
- 質問される側の心構え的な話がでたが、質問する側も相手のコンテキストを理解した上で質問するの大切、とおもった。
セッション
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
登壇者
松岡(@little_hand_s)
概要
スライド
レポート
DDDとオブジェクト指向の関係
DDD
- ソフトウェア開発志向の1つ。
- 適用する対象の何らかの問題を解決するために導入される。
- Domain Language(https://domainlanguage.com/ddd/reference/)
- 本より読みやすいのでおすすめ。
- モデリングから劇的な利益を得られたものからエッセンスを抽出する。
モデルとは何か?
- まず、DDDでの『モデル定義』をしよう。
- モデルとは問題解決のために物事の側面を抽象化したもの。
- ドメインモデル
- 現実世界をも問題を解決するモデル。
- データモデル
- DBに何かを永続化するモデル。
- ドメインモデル
- モデルとは問題解決のために物事の側面を抽象化したもの。
- 今回はドメインモデルの話。
抽象化について
- たとえば、履歴書
- 履歴書の要素として、写真を貼る場所、履歴を描く場所などがある。
- 上記の目に見える要素以外にもたくさん要素がある。
- 履歴書のメーカーや紙の素材、書いているときの気持ち・・・etc。
- すべての要素をモデルに落とし込むことはできない!
- 履歴書のメーカーや紙の素材、書いているときの気持ち・・・etc。
- 抽象化とは、要不要の判断をすること。
よいモデルとは
- わかりやすいモデルが良いモデルか?
- No。問題解決ができることモデルが良いモデル。
よくないモデルとは
- 問題解決ができない。
- 実例
- 採用管理システムで考える
- 書類選考、一時選考、最終選考を考慮したシステムを構築しました!
- 書類の前に面接があるんですけど・・・。
- 求人の関係ない採用もあるんですけど・・・。
- 上記のような柔軟な対応がむずかしい、となるとどうなるか。
- 運用でカバー!!!(技術の敗北)
- カバーできるレベルなら問題ない。
- 他のUXと競う場合は完全に不利になる。
- カバーできるレベルなら問題ない。
- 運用でカバー!!!(技術の敗北)
- 書類選考、一時選考、最終選考を考慮したシステムを構築しました!
- 採用管理システムで考える
- DDDの実装パターンを的確に反映して、まったくバグがないシステムを実装したとしても、拡張性がなければ利益は生み出せない。
よいモデルを創るには
- ドメインに詳しい人にしっかり話を聞く。
- しっかり会話をして得た知見をモデルにフィードバックする。
- モデルは最初から完成しない、変わっていくもの。
モデルとコードが乖離してしまうと・・・
- モデルの更新をコードに正しく反映できているか分からなくなる。
- 案件に途中から入る人はコードから読む。
- コードからモデルが理解できない、モデルからコード理解できないとソフトウェアとしての価値が低い。
- モデルがそのままコードになっているのが望ましい。
- 「オブジェクト」でモデルを表現したい。
- モデルを継続した変更に耐えうるようにするためには、拡張性の高い設計が必要。
軽量DDD
- DDDの実装パターンだけ取り入れる手法に意味はあるか?
ドメインモデリングの方法
コードへの落とし方
- アーキテクチャは代表者がざっと決めて開発を進める。
- プレゼンテーション層 ⇒ アプリケーション層 ⇒ ドメイン層(エンティティ)の順番。
- まず動くものを作りましょう!ひどいつくりでもOK。
- その後、リファクタリングしていく。
- レイヤーによって書くべきことが決める。
- レビューコメント論争を生まない為に。
- コード全体に規律を持たせることができる
- お手本コードを作る。
- Application,Entity,Repository。
- ドメインモデル図をもとに実装する。
- 本を読む。
- 手を動かしてみて、どう書き分ければいいんだっけ??と模索してみる。
質問
※ 質問はslidoより転載。
Q.既存のMVCベースのフレームワークを利用していると、オニオンアーキテクチャやクリーンアーキテクチャの適用が難しいなと感じています。MVCにおける○○はどのレイヤーなのか?このレイヤーは○○を利用すべきなのか、それとも別のクラスにすべきか?等で手が止まります。どのような手順で適用していくと良いのでしょうか?
Q.集約単位の見極めが難しいのでは?こつはありますか?
- A.本にもあるが下記2つ。
- トランザクション範囲が大きくなってしまっているか?
- 整合性保ちたい範囲はどこか?を決める
Q.モデルの新規作成や改善にあたっていきなりコードから入る人がいます。個人的にはいきなりコードに入る前にもう少し手前でたくさん試せればいいなと思うのですが、その方法についてアイデアはありますでしょうか?
- A.価値を感じるまでが難しい。。
- 話ながらいきなりボードに書き出す手法がある。(目の前で描かれると無視できない。)
Q.軽量DDDに価値がないとは思わないのですが、問題は軽量DDDを行って手元でコードを書いて満足してしまう、この状態でDDDをやってると思ってしまう人がいることだと思います。お話されたようなモデリングに向かうアプローチがあってこそのDDDだと思うのですが、そこに意識が無い人への対応など、何かお考えなどありますでしょうか。
- A.自分が作ったシステムが本当に役立ってるか?というところに意識を向けることが大事。
Q.CQRS などの文脈で Query はレイヤーを両略してよいだとか、ORM を使ったシンプルな実装でよいという意見をよく見かけるのですが、データの解析やビジュアライゼーションがメインのアプリケーションで、複雑な Query ロジックをドメイン層で表現するのはありですか?(ドメインエキスパートはデータアナリストです)
- A.クエリに寄せたほうがいい。更新系と参照系でオブジェクトを分ける。
- 更新はオブジェクトの切り方、集計とかビジュアライズは参照の用途で違うので知識が混ざらないようにしたい。
Q.お手本のコードは詳しいひとじゃないと書けないですか?
- A.やってみたいひと、強い意志がある人で進めればいい。
Q.軽量DDDはコードからDDDを導入する、とお話しがありました。例えば、ドメインエキスパートがもういない、すでに仕様をわかるひとがいない、レガシーなコードで保守だけでなく機能追加もある…みたいな案件で、それぞれの課題をクリアーにするために、軽量DDDは使えるのではないか、と感じましたが、松岡さん的にはアリでしょうか?
- A.「コード汚い」という問題と、「仕様がわからない」という問題は違う。
- 仕様がわからない・・「ドメインモデル図」を仕様理解のためにつかえばいい。
Q.golangでDDDはできますか?
- A.できる!
所感
- 技術書典で本を絶対買います!
- 重要なことは「問題解決できているか」。DDDを導入することではない。
- 問題の切り分けが上手になりたいなあ。
- DDDは「やってみたいひと、強い意志がある人で進めればいい」という言葉に感銘を受けた。 自分には技術が足りないから・・とかで逃げない。責任をもって進もう。と思った。
オブジェクト IPPON グランプリ
登壇者
- パネリスト Chatwork株式会社 加藤 潤一 (@j5ik2o) 株式会社バリューソース 神崎 善司(@zenzengood) 弁護士ドットコム株式会社 天重 誠二(@tenjuu99) 株式会社オージス総研 原田 巌(@iwaoRd)
- モデレータ 株式会社チェンジビジョン 平鍋 健児(@hiranabe)
概要
スライド
- 見つけられませんでした。(見つけ次第貼り付けます)
レポート
UMLは何の略ですか?
- 回答無し。
なぜオブジェクト指向?
オブジェクト指向はClass?Message?
- Scalaやってるとどっちもある(神崎)
- プロログ以外の物はすべて入ってる。
- 向いてるところで使えばいいと思っている。
- 考えるツールと言っていたが、関数型も好き。自分で書くときは関数。対象をとらえるときはオブジェクト指向。
- 最近はテクニカルなものに興味なくなった
- ユーザと話した時に、何を考えているんだろう?というときにオブジェクト指向で考えている。 どっか分析をしていて、Entityとしてとらえてる。(原田)
- オブジェクト指向は自分の考え方に合うと感じる。(平鍋)
- いまや分析論とまでになった。対象カテゴリを決める、知る、概念となってしまった。
- オブジェクト指向はプログラムから生まれたと言われている。
- ヒープ上にずっと残っているもの=オブジェクトだった。
- オブジェクト指向はプログラムから生まれたと言われている。
- いまや分析論とまでになった。対象カテゴリを決める、知る、概念となってしまった。
- 両方捉えられるものだと思っている。(天重)
- アジャイルの言語でものをつくるとき、はやく作らなきゃ!ユーザと認識合わせなきゃ!同プログラムにつたえよう!設計⇒分析⇒要求というライフサイクルを回すことも近い。
- Complexな状況に適応するため。(加藤)
- 環境の変化に耐えられる。ひっくるめてこれにいきつく。
- 存在たら占める何かを合意する。(原田)
- 属性を切っていった後に見える本質。
DDDってオブジェクト指向?
- DDDはオブジェクト指向か?オブジェクト指向はDDDか?と考えたとき違和感を感じる(神崎)。
- オブジェクト指向的に考えたとき、継承で成立するかで考えるが、今回は違う。
- そもそもDDDはドメインドリブン ⇒ 「お」の字もない。
- オーパーツにつながるミッシングリンク。(原田) ドメインドリブンはドメインで導く。 オブジェクト指向的なところから、最終的にはどのようにおとしこむか。
- NO オブジェクト指向の基盤になるモデリングパラダイム(加藤)
- DDDは社会的な制約。メッセージ思考とはちがう。クラス指向が制約としてプログラマの制約としてはたらくドメインモデル。(原田)
- DDDはクラス指向だと思う。(天重)
- オブジェクト指向は基本的には概念設計していく。
- 概念としての、クラスとしてあらわして実装されるのでクラス指向。
オブジェクト指向はGUI か?(天重)
- アラン・ケイがオブジェクト指向を産み出したと同時にGUIも生み出されたが、イコールになりうるか?(天重)
コードがあればモデリングはいらない?
- コードの量が多いのはしんどい。(平鍋)
- エディターがどんなになっても便利になっても、10万行もあればわからないし、理解できない。(神崎)
- マギシステムの付箋(エヴァ)。(原田)
- マギシステムになにかあった時に、システムの裏に付箋が貼ってあって調整する。
- こういう存在であってほしい。コードがあればいいということはない。
- 設計意図がつたわる。モデルがあれば理解出来るというところを大切にしたい。
- こういう存在であってほしい。コードがあればいいということはない。
- マギシステムになにかあった時に、システムの裏に付箋が貼ってあって調整する。
- モデリングは仮説⇒コード・テストは実証。モデリングは図示、コード・テストは詳細。(加藤)
- モデルはシミュレーション、コードは制約(天重)
好きなモデリングツールは?
所感
- OOCのデザインをみて、Ipponグランプリを思いついたらしい。たしかに!
- そういえば、OOCのデザインはなんで黄色と黒なんだろう。
- パネリストの方々は歴史というか原案てきな部分をしっかり網羅している。そこら辺の部分の理解の甘さを痛感した。本や原著をしっかり読んでおきたいと思った。
- miro.com、使ってみたい。
- 「モデルを渡すのではなく、モデリングをみんなでする」はとても大切だと感じた。DX。
概念投影によるオブジェクト指向設計の考え方とその方法
登壇者
hirodragon(@hirodragon112)
概要
スライド
レポート
前提
- プログラミングの基礎があること。
- そのうえで、設計をやってみたい。何からやってみてもわからない。設計活動の迷いとの闘いをしている人向け。
- 何が正解かの捉え方の説明。
- 設計活動の考え方。
- DDDとか具体的な手法概念の説明しない。
- Before Principal、Before pattern、Before Paradigm
設計を難しく感じる理由
- 正解がわからない、何から始めればいいか分からない、GOALがわからない・・。
- 設計が進んでいる道が分からない。
- スタートラインがわからない
- DB、画面設計書?クラス図?
- ゴールがわからない。
- ゴールなんてない!
- 何かを覚えてやる、暗記でOK? 設計は暗記じゃない、論理が組みたっていないとできない。
- 全体像を知っていると認識が違う。
- 迷いはミスにつながる。
- 自分の中に指針を持って設計すること。
アプリケーション開発とは
- 現実世界の活動代行
- 現実世界は意様々な活動を無数のアプリケーションが支えてる
- 小人が中で動いているようだが、実際に小人はいない。
- やりたいことをイメージすることが大事。ソフトウェア化の前提をクリアにしないといけない。
設計とは
- 4w1h
- What・・・小人がいる世界を作る
- Who・・・エンジニア
- Where ・・・コンピューターの中に
- Why・・・代行させたい
- Howが一番重要。
- システム化したい領域を投影する。この無の世界に現実世界を代行してくれる新たな世界を作り上げる。
- 世界を創世している、くらいのつもりで取り組む。エンジニアの力で、無から有へ。
- ただし、コンピューターは現実世界を知らない。
- 与えられた武器はプログラミング言語
- ここに現実世界の「営み」を代行してくれる小さな世界を作り上げる
- じゃあ、どうやって世界をつくるのか?
- 概念投影。
- コンピューターは現実世界を知らない
- 設計をせずともプログラムは動く。簡単に作れる。
- ただし、ほんとにコンピュータも理解してますか?
- 例えば、コレクションを受け取って性別が"man"だったら配列に加え、男性だけのリストを返すとする。
- 実際はコンピューターは不明な何かを受け取って、不明なプロパティが文字列の中と比較し、配列にいれて、出来た配列を返しているだけ。manとか知らん。
- 無の世界に持ち込まれたのはプログラミング言語の作る世界のみ。
- 例えば、コレクションを受け取って性別が"man"だったら配列に加え、男性だけのリストを返すとする。
- 人間は文字(man)を見て、自分の世界の概念と照らし合わせることにより無意識に認知ができる
- コンピューターはプログラミング言語が成約した概念のみしか認知できない。
- このようなギャップのことを『セマンティックギャップ』という。
- 「認識が当たり前ではないと意図的に考えない」と、セマンティックギャップが認識できない。
- コンピューターは現実世界を知らない
- 概念投影。
概念を投影するとは?
- 限られた武器でコンピューターに仮想的な現実世界を教えて存在させる必要がある。
- 存在 = 実在ではなく『認識』できること。
- 認識できる=『概念が定義されていること』。
- 概念を教えて仮想的な現実世界を作る ⇒ 概念を投影するということ。
- 与えられた武器はプログラミング言語。
公理と定義
- 公理
- 無条件で正しいと定められているもの。正しいという証明が不要なもの。
- string、int、bool、dateなど言語が用意する型やClassも公理。言語が提供しているものは公理。
定義
- 公理をもとに新しく正しいと定めたもの。
- ユーザー定義クラスなど。
無の世界に投影させる際、公理の方のみ使用すると現実世界にある概念が存在しない世界となってしまう。
- 定義は公理を使用して型を作るが、定義は人によって意味が異なる可能性がある。
Activity(営み活動)
- 何かを売る・買うなどといった、アプリケーション有無に限らず存在する大前提。
- Activityを表現するために必要な論理、ロジック。
- アプリケーションを駆動するために必要だが、現実世界の営みに影響力を持たない。
- 現実世界の営みを代行してくれる小さな世界を作り上げる
Domain Actibity
- 例えば、「ホテルの予約」というような営みがあれば存在するもの。アプリがなくても別の媒体でできる。
- ドメインモデリング
- 必要な単語を洗い出す(用語集を作る)。小さな単位でまとめる。
- 出てきたアクティビティに関するものをまとめる。
- 作った単語集を少しステムに近づける 。
- 概念投影
ApplicationLogic
- Activityと混同しがち。ClassというよりInterface。
暗記しても意味ない。目的を実現するためのもの。
- 手法や理論を用いる前にその活動が何を実現しようとしているのか指針を持つことが重要。
- 概念の投影により、仮想世界に現実世界を存在させる概念投影指向という考え方。
- 投影されたすべては単一で存在する概念。Atomicな存在まで概念を分析する。
- オブジェクト指向ではClassとして表現される。
- 単一債務、関心の分離 設計せず複数の債務監視を持った処理作成など。
- 概念投影指向の概念はすでに単一で分離する必要がない。
- 単一な概念を統合するとDomainとして表現が膨らむ。
表現としてのふくらみ
レイヤードアーキテクチャー
- Port- Adaptor
- Application Logicとして投影されている
- Port- Adaptor
契約による設計
- 関数シグネチャに型を指定そ、各振る舞いの事前条件や事後条件を制限する。
- 契約したい概念はActivityとApplicationLogicとしてアプリケーションの世界で認識できるようになっている。
- あとは契約を描くだけ。公理の方のみでは契約書けない。
- DDD
所感
- 主催者の方の話が聞けたのはあつい!
- 内容えもい。我々は世界を作っている。そのくらいの気持ちが大切。
- 概念の話、「散歩する侵略者たち」という映画を思い出した。
- 最初のコンテキストの話にも通じるものがあった。
- 公理と定義の考え方、何かを考えようと思ったときに一番最初に考えるための指針として持っていようと思った。
オブジェクトライフサイクルとメモリ管理を学ぼう
登壇者
ariaki(@ariaki4dev)
概要
スライド
レポート
- オブジェクトはどこからどこへ行くのか。
- 星の数ほど作り出されるオブジェクトにどんな意味があるのか?
メモリ管理
- CPUの中にレジスタがあり、内部データを保管している(x64系は16個ある。64*16)
- フロントサイドバスがメモリからCPUに転送する。
CPUの中でメモリとやりとりをするがかなり低速。x64系はメモリがキーとなっている。
New object(); されたとき何がおきるか
x64アーキテクチャでは?
- OS <-> RAM間は64bit単位で読み書きされる。
- 64bit中48bitがメモリアドレス。(最大256TB)
- 48bitが5つの箱に入っており、それぞれのテーブルが次のテーブルの場所を差している。
- 具体的なオフセットアドレスを差している。
- MMU(メモリマネジメントユニット)がメモリのアドレスを割り当ててる。
- アドレスが変換された対応表のTLBがある。
- TLBがあれば、高速にアドレスを引き出せる。TLBがあるからこそ今日のCPUが速い。
- ただし、あるせいで攻撃されることもある。
- if文などの分岐の処理をCPUが先読み実行出来る。
- ブランチ両方を先読み。
- 実行して成功率が高くなければ成功率下がる。
- 投機的実行。突き詰めればもっとはやい処理が書ける。
- TLBがあれば、高速にアドレスを引き出せる。TLBがあるからこそ今日のCPUが速い。
- メモリ要求用に応じて4kb、2mb、1GBごとに区切られたページが確保される。
- 仮想~物理の対応はページテーブルで管理。
- 頻繁に使われるアドレスはTLBにキャッシュ。
- ページテーブルはOSが定義しているが、動作はCPUの機構。
メモリアロケータ
- プログラム ⇔ メモリアロケータ ⇔ OS-CPU
- malloc()
- 確保したいメモリサイズに応じて自動で最適なサイズを割り当てる。
- メモリサイズごとに異なる領域を確保。
- fastbins < 160
- bins> 160
- 大きなメモリはmmap命令。
- freeしても内部的にはキャッシュしていることある。
- chunk単位で確保。8byteでアラインメントされている。
アラインメント
アラインメントとは、メモリ使用教を キャッシュラインにあわせること。
- 例
- short・・・2byte
- int・・・4byte
- float・・・4byte
- double・・・8byte
- char・・・1byte
- 例
アクセスに無駄がなく、高速に読み書きできる
- CPUによってはアラインメント違反はエラーになる未使用領域が発生する。
- アラインメント最適化
- キャッシュライン+高級言語の仕様。
- メモリがどのくらいひつようかは、言語仕様をを読み解かないといけない。
- キャッシュライン+高級言語の仕様。
スタックとヒープ
- スタック
- 確保・解放が速い。
- 寿命が短い。
- サイズ小さい。
- コールスタック
- 関数様に確保されている。ローカルの変数等。
- 関数ごとにスタックフレームという枠を作ってデータを入れている。
- 積んでいることで、そのリターン後に自動で破棄される。
- コールスタック
ヒープ
- 確保・解放が遅い。
- 自分で寿命を決められる。
- サイズ大きい。
- 参照型の実態を持つ。
- 好きなだけ好きな時に割り当てられる。
- 誰かが解放しないといけない。
CPUの中で処理できるデータは64bit(xbit)
- メモリの読み書きを頻繁に行っている。
- 高速に保つためCPU内でN次キャッシュをもつ。
- アクセス速度はバスクロック/メモリクロックに依存する。
- オブジェクトで管理されるメモリ領域はアラインメントされる。
- 大きなオブジェクトはの確保は重い。
オブジェクトの正体
- New object(); -> オブジェクトヘッダとオブジェクト実体ができる。
- オブジェクトヘッダの言語ごとの実装
※ Javaについては割愛してしまいました・・(スライドを参照くださいませ)
PHP5
- ZVAL構造体
項目 内容 refcount 参照カウンタ type 型を示す文字列 is_ref 参照集合かどうかを判定するbool値 PHP7
- ZVAL構造体
項目 内容 interned 文字列がインターン化された状態 refcount 参照カウンタ is_ref 参照有無 interned(インターン化)
コピーオンライト
- $ar2 = $ar1;の時点では$ar2のメモリは確保されない。
- $ar2[0] = 1;の時点で値が複製(コピーオンライト)される。
- 配列に値を一個ずつ突っ込むと、8個ごとにメモリを追加確保していることがわかる。
- 8倍ごとにメモリが追加確保されている?
$ar1= ['a','b','c'];
$ar2 = $ar1;
$ar2[0] = 1;
unset($ar2);
GC(Garbage Collection)
まとめ
- 設計だけじゃなく、プログラムの中の設計にも目を向けてみよう!
所感
- がっつり低レイヤーの話!むずかしかったけど面白かった。
- メモリ管理、普段考えられてなかったけど今後はしっかり考えてきたい。
- 言語(同じ言語でもバージョンによって)によってメモリ管理の仕方が違うということがざっくり理解できた。これから使う言語(ruby)についても調べてみよう。
タイトル
登壇者
株式会社メディアドゥ 濱口賢人(@kent_hamaguchi)
概要
スライド
- 見つけられませんでした。(見つけ次第貼り付けます)
レポート
まず、オブジェクトの定義をしよう!
- システムそのものもオブジェクトである。
- 設計は仮設提唱。
- 苦しまない開発をしたい。
オブジェクトって何?モデル?
- そもそもオブジェクトとは? ふるまい、構成要素、hogehoge?
- 本セッションはでは、『唯一の振る舞いであり、それを支えるための洗練された構成をもつこと』と定義してみる。
各レイヤーのオブジェクト
横と縦で考えてみる。
縦
- 組織観点
- プロダクト観点
- システム観点
- インフラ観点
- ソフトウェア観点
横
- 組織観点 -> 組織論、人間論、コンベイ・・・。
組織もオブジェクトなのでは。定義があって、インスタンスが立っているイメージ。
- システムもオブジェクト。
各レイヤーをオブジェクトとして見てみる。
- クリーンアーキテクチャー。
- 上位レイヤーのオブジェクトは論理性が破綻しているととつくれない。
- 成果物が目的に成り立たず、破綻する。
- 仮説
- 目的への達成方法を論理設計する。
- ソフトウェア開発は論理的なコンピュータを扱う。
- 故に論理的に成り立っているべきである
- HOWTOからはいっていっても、結びつかないと意味がない。
- 目的への達成方法を論理設計する。
証明
- 仮説を結果へ成果物を作成し実証する。
- 論理的。筋的に成り立つものであれば実装できるべきである。
オブジェクトを支える仮説実証の流れをアジャイルスクラムで回していく。
- コーディングに入った途端分からなくなる、ゴールを見失う。
- 振る舞いはなんとか担保できても、内部構造が破綻する継続的な改善できない。
- そもそも後から理解出来ない
これはゾウですか?
- 組織のトップレベルで話されているが、セクションが分かれすぎてそれぞれの部署の話しかしてない。
- 大きい組織でなればなるほど裁量が分かれていってしまう。
- 全体を視座を上げる。
- 事実に基づく信憑性のある仮説を立てて、結果を直視する。
- 仮説たてながら事実に基づいた正しいふるまいのオブジェクトを蒸留する。
半面直感を大事にする
- いろいろ考えても、結局机上の空論。
- 直感を検証なしにこねるのはよくないが、素早く検証し事実か確かめることは大切。
オブジェクトを使う目的
- 個人にしても組織にしても、社会に対して何を提供し恩恵を出すのかが大事。
- 最終的には人が価値を判断する。
オブジェクトを支える
- オブジェクトが期待されるふるまいを続ける。
- ゴールに沿った論理設計を行い、コードはそれらを素直に表現できること。
所感
- 『セクションが分かれすぎてそれぞれの部署の話しかしてない』はめちゃくちゃあるある・・小さいチームでさえ起こりうる。
- みんなが視座を上げるために、どのようなことをしたらいいんだろう。前職(現職)では自分だけ空回ることが多かった。
- 直感を大事にする、という言葉は今回初めて出てきた。方式も大事だが、経験もすごく大事だよなあ。
- 何にせよ、フットワーク大事。
全体所感・気づき・メモなど
- まだゴリゴリにオブジェクト指向を理解できているわけではないから、すこし緊張しながら臨んだが、DDDの話やモデリングの話などコーディングにとどまらない話が多くとても面白かった。
- 相手と考えをすり合わせるツールとして、オブジェクト指向がいかに便利で有用か分かった。もっと理解するためにも、まずはしっかりコーディングを勉強したいと思った。
- 御茶ノ水女子大の建物素敵だった。
- きなり屋のラーメン、うまかった。
- 自分で考えつつまとめるのうまくなりたい。議事録てきな、スライド読んだ方が早いみたいなまとめ方しかできないな。。。
レポっした。