Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
不幸を再生産しないための設計に対する向き合い方
Search
MinoDriven
August 20, 2022
Programming
10
9.3k
不幸を再生産しないための設計に対する向き合い方
「オープンセミナー岡山2022」のイベント登壇で用いた資料です。
https://okayama.open-seminar.org/
MinoDriven
August 20, 2022
Tweet
Share
More Decks by MinoDriven
See All by MinoDriven
破壊せよ!データ破壊駆動で考えるドメインモデリング / data-destroy-driven
minodriven
18
4.4k
アーキテクチャレベルで考える開発生産性 / architecture-and-productivity
minodriven
22
11k
見えないものに着目すると上手くいく、モデリングの勘所 / invisible-driven-design
minodriven
22
6.6k
クソコード動画『カプセル化 Mk-II』 で考える 上手くカプセル化できない理由 / encapsulation2
minodriven
21
16k
技術的負債の怨霊と除霊方法 / ghosts-of-technical-debt
minodriven
11
4.2k
分岐を低減するinterface設計と発想の転換 / interface_design_idea.pdf
minodriven
18
6.6k
目的と抽象化の関係性から分かる、システムの設計精度を高める考え方 / purpose abstraction design
minodriven
22
8.8k
『良いコード/悪いコードで学ぶ設計入門』を一歩深める読み方 / deepen good code bad code
minodriven
18
6.9k
風刺動画「一枚岩モデル」で考える、DDDの境界付けられたコンテキスト / huge model vs bc
minodriven
19
39k
Other Decks in Programming
See All in Programming
Compose 1.7のTextFieldはPOBox Plusで日本語変換できない
tomoya0x00
0
200
Jakarta EE meets AI
ivargrimstad
0
330
cmp.Or に感動した
otakakot
3
250
EMになってからチームの成果を最大化するために取り組んだこと/ Maximize team performance as EM
nashiusagi
0
100
subpath importsで始めるモック生活
10tera
0
330
3rd party scriptでもReactを使いたい! Preact + Reactのハイブリッド開発
righttouch
PRO
1
610
Amazon Bedrock Agentsを用いてアプリ開発してみた!
har1101
0
340
アジャイルを支えるテストアーキテクチャ設計/Test Architecting for Agile
goyoki
9
3.3k
ヤプリ新卒SREの オンボーディング
masaki12
0
130
ActiveSupport::Notifications supporting instrumentation of Rails apps with OpenTelemetry
ymtdzzz
1
250
カンファレンスの「アレ」Webでなんとかしませんか? / Conference “thing” Why don't you do something about it on the Web?
dero1to
1
120
rails new flags - `rails new` のフラグから Rails を構成するコンポーネントの変遷をザックリ眺める
snaka
0
1.8k
Featured
See All Featured
A Tale of Four Properties
chriscoyier
156
23k
How to Ace a Technical Interview
jacobian
276
23k
Navigating Team Friction
lara
183
14k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
A Philosophy of Restraint
colly
203
16k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
42
9.2k
Intergalactic Javascript Robots from Outer Space
tanoku
269
27k
Keith and Marios Guide to Fast Websites
keithpitt
409
22k
Fireside Chat
paigeccino
34
3k
[RailsConf 2023] Rails as a piece of cake
palkan
52
4.9k
GraphQLとの向き合い方2022年版
quramy
43
13k
Building Your Own Lightsaber
phodgson
103
6.1k
Transcript
不幸を再生産しないための 設計に対する向き合い方 2022/08/20 READYFOR株式会社 ミノ駆動
おしながき • 自己紹介 • 本日のお題 • 私の失敗経験 • 失敗経験と学びの活用 •
モデリングと認知科学 • クロージング
こんにちは、ミノ駆動です
ここで働いています
最近ニュースになった クラウドファンディング
『良いコード/悪いコードで学ぶ設計入 門』の著者。 発売3ヶ月で第6刷目の重版。発行部数 2万部達成。 技術書で1万部超えればベストセラーと のことですが、それも超えてまだまだ売 れています。
もうちょっと詳しい職歴とか ミノ駆動 @MinoDriven 電子機器メーカーや大手精密機器メーカー、そし てクラウドワークスを経て、2021年4月に READYFOR株式会社にジョイン。 アプリケーションアーキテクトとして、レガシーシス テムのリファクタリングや拡張性向上設計など、シ ステム設計に従事。 『良いコード/悪いコードで学ぶ設計入門』の他、
クソコード動画シリーズの作者。
本日のお題
設計しないと不幸になる
そして より良い設計アプローチをしないと 不幸になる
私と同じ不幸を 再生産してほしくない そんな思いを伝える内容です
僕が体験した「不幸」とは?
プロジェクト炎上
日常的なプロジェクト炎上 派遣さんも含めて40-50人の開発体制。 仕様書通りに動作するよう、実装だけをひたすら繰り返し。 設計はほとんどしていないに等しい状態。 開発中、バグが大量に出る。バグを直した影響で他の箇所にバグ が発生するのは茶飯事。
残業40-60時間は当たり前。 体力ミジンコの私、疲れ果てる。
PL「つらい残業を乗り切れるよう、 昼休みにバスケをやって体力をつけよう!」
書籍『リファクタリング』との出会い
運命を変えた本『リファクタリング』 何か打開策はないものかと職場の本棚を 漁っていたら書籍『リファクタリング』を偶然発 見。「コードが理解しやすくなる」「バグが少な くなる」の記述を見て衝撃を覚えました。 仕事中、製品コードを利用し、裏でコソコソリ ファクタリングひたすら練習(※もちろんコミッ トはしてません)。
設計があまりに面白かったので、『ドメイン駆動設計』や『レガシーコード改善 ガイド』など設計関連の書籍を買い漁り、買いすぎだと嫁に叱られつつも、さら に設計スキルを高めていきました。
リファクタリングプロジェクト事件
リファクタリングプロジェクトの発足 先のソフトウェア製品が致命的なバグを何度も再発させてしまい、 大問題に。 設計レベルの見直しが必要と判断され、リファクタリングプロジェク トが発足する流れへ。私もいの一番で立候補する。
私の失敗 「全部リファクタリングするんだ」と、リソース、 コスト無視で推し進めようとした。 ガッチガチの設計ガイドラインを策定し、「全 部この通りに設計し直せ」と、各モジュールの 要件やトレードオフも考えずに、無理に押し 通そうとした。
リファクタリングプロジェクトに人を取られ、ただでさえ開発の鈍 化が懸念される中、無理強いをさせられた側からは不満が噴 出。 「ミノ駆動は学者風情の理想論者」などと陰口を言われるのも当 然だった。
設計でのつまづき まとめ • 組織全体でほとんど設計されていなかったために、バグが大 量に埋め込まれる事態が日常化していた。 • コスト戦略をろくに考えず、全体をリファクタリングしようとした。 • 厳格な設計ガイドラインを無理強いし、無用にハードルを高め てしまった。
当時は何がまずかったのか いろいろ分かってなかった……
わからん殺し 「わからん殺し」とは、対戦ゲームにおいて、相手側が対策できていない戦法で 一方的になぶり殺す事の俗称。やられた側からすると「よくわからない内に倒さ れていた」感覚。 何か上手くいかないときは、課題や解決方法が認識できていないことが多い。 今ある知識だけでなんとかしようとすると上手くいかない。「セルフわからん殺 し」に陥っている。 様々なことを学び直すキッカケになりました。
学び直しで得た知識の例 • 書籍『ドメイン駆動設計』 ◦ システムで最も価値を付加すべき「コアドメイン」の概念を知ったこと で、設計コストの選択と集中を学んだ。 • 書籍『レガシーソフトウェア改善ガイド』 ◦ リファクタリング対象の選定には、価値、難度、リスクの3軸で評価する
ことを学んだ。 ◦ チームから合意を得るための交渉のしかたを学んだ。 ◦ ソフトランディングするための進め方を学んだ。 etc…
失敗経験と学びをどう活かしているか
認識の共有
課題感の共有 「巨大なRailsアプリに蓄積した負債を解消し、開発生産性を向上 したい」 この課題を解決することのみに注力する設計であって、他の機能 開発を妨げたり、いたずらにリソースを食い潰すような意図はない ことを強調。
解決手段の理由や背景を共有 RailsはActiveRecordが中心であるために、随所でDB知識と密 結合になる。 Railsアプリが巨大化してくると、Rails-wayのやり方では辛くなっ てくる。 ゆえに打開策として、DDDの考え方を取り入れる。DB知識と疎結 合にする、よりビジネスに追従容易なドメイン層を形成するため。
選択と集中、コスト戦略の共有 変更頻度の高いコアな機能に設計コストを集中する。 負債の酷くない箇所や、コアでない箇所は従来通りRails-wayで 良い。無理はしない。
その他認識共有 勉強会で設計知識を共有 メンバーとの課題感、設計に対する認識合わせ スモールステップで実施 小さな成功体験の積み重ねと共有
説明コストはかなりかかりましたが 設計の理解を得られ ソフトランディングに成功しました
やったことは チームビルディングそのものでした
チームビルディングなくして設計は上手くいかない 高い 開発生産性 設計 チームビルディング ここをないがしろにすると、2階にあ る設計に登れない! 技術的負債と設計は認知困難だ からこそ、意思共有は丁寧に!
設計も常に学びの日々です
モデリングと認知科学 モデリングは設計の要です。 物事をどう見るかで概念の認識が変わりモデルも変化します。 より本質をついた、高品質なモデリングをするには、概念をどう解 釈するかを深く知る必要があります。 そのため私は最近、認知科学や哲学を勉強しています。
アクチュアル(現働的) ヴァーチャル(潜在的) 「自転車に乗る人」と「自転車」の、 物理的存在に囚われがち。 存在の脱構築 人 vs 自転車といった区別なく、全てのもの が複雑に関係し合う次元として解釈。モデリ ングで役に立つ考え方。
『現代思想入門』著:千葉雅也、 2022年刊行、講談社
物理的存在としてモ デリング 利用者 User 利用者:モデルが1:1では 巨大化複雑化し、 使いにくいモデルになりがち
存在の脱構築 利用者 購入側 アカウント 個人 プロフィール 認証 認可 出品側 アカウント
会員特典設定 物理的存在から離れ、役に立つ目的単位で モデリングすると、1:Nの関係性になる(こと がとても多い)。
エヴァンス本 シェアパイの例 ブレイクスルー シェアパイ ローン出資 ローン調整 「シェアパイ」という概念を見出したことで、ローンの金額計算誤差 や特殊ケースに対応するための複雑なロジックが消え去った。顧客 にもわかりやすい概念として定着した。
「売買契約」という法的概念とすることで支払条件(支払期日など) の存在を認知できる。法的な有効性を発揮できるモデルとなる。 商品購入?? 法的な意味付け 商品購入 ID 購入日時 受取希望日 売買契約 ID
契約締結日時 引渡希望日 支払期日 決済方法
クロージング
誰しも仕事で辛い局面に 立たされたことがあるはず
不貞腐れたり 誰かを恨んだり 仕事を投げ出したくなったり…
私は様々な失敗経験をないがしろにせず その後の開発などに活かしてきました
これまでの失敗がなければ この本は完成しなかったでしょう
失敗を放っておいて イヤな記憶として こびりつかせておくよりも…
どうせなら成功のために 活用した方がスッキリしますよね
どうやったら失敗を 上手く活用できるのだろう?
【重要】 失敗の活用には知恵が要る 知恵がないと失敗のまま腐り 不幸を再生産する
書籍『リファクタリング』でバグを埋め込みやすい構造とそうでない構造を見分 ける観点を獲得し、原因不明だったバグ頻発の原因を知りました。 書籍『ドメイン駆動設計』でコアドメインの概念を知り、闇雲に設計するのではな く、コアに集中する重要性を学びました。 書籍『レガシーソフトウェア改善ガイド』で、組織で設計を推進する上での戦略 性を知り、軋轢を生まずに設計改善をソフトランディングするノウハウを獲得し ました。 認知科学関連の書籍からの学びが、モデリングの精度向上に寄与しつつあり ます。
知恵は失敗を宝に変える
本日このあとの登壇者の発表や 様々な技術書から学びを深め 失敗を宝に変えていこう