Slide 1
Slide 1 text
疎結合 と 認知
疎結合 と 認知
Gunma.web #44
Gunma.web #44
@kanayannet
@kanayannet
Slide 2
Slide 2 text
近況報告
(
前座
)
近況報告
(
前座
)
今更ですが...
Ruby
技術者認定試験 Silver
合格
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
次は
GOLD
目指します
次は
GOLD
目指します
Slide 5
Slide 5 text
今のネタが伝わった方は世代がバレ
ry..
今のネタが伝わった方は世代がバレ
ry..
Slide 6
Slide 6 text
ここから本題です
ここから本題です
Slide 7
Slide 7 text
今回の目的
今回の目的
疎結合 のアーキテクチャにすると..
「その仕組み覚えずらい」という人が出てくる
何故、覚えずらいと感じるのか？紐解く
Slide 8
Slide 8 text
凄い技術の発表じゃないよ
凄い技術の発表じゃないよ
でも凄く重要な事です。
Slide 9
Slide 9 text
今回の大前提
今回の大前提
密結合 =
悪 と断罪したい訳ではない
機能を集約化するために、やる場合もある
もちろん「覚えずらい」という人が悪いという訳でもない
原因を取り除いてスムーズに物事を進めるために
自分も勉強するために
Slide 10
Slide 10 text
疎結合とは？
疎結合とは？
細分化された個々のコンポーネント同士の結びつきが緩やか
独立性が強い状態
個々のコンポーネント同士は連携しているが、依存している
事が少ない
Slide 11
Slide 11 text
もっと具体的に
もっと具体的に
それ単体でも動作可能である
それ単体でテストが可能である
Slide 12
Slide 12 text
どれが一番疎でしょうか？
どれが一番疎でしょうか？
rubygems, cpan
など
自作のモジュール群
マイクロサービス
Slide 13
Slide 13 text
クリーンアーキテクチャでは
クリーンアーキテクチャでは
Slide 14
Slide 14 text
ソースレベル
コンポーネント間の通信には、単純な関数呼び出しを使用
デプロイレベル
あるモジュールのソースコードに対する変更が、ほかのモ
ジュールに影響を与えない単位
サービスレベル
物理的な場所に依存しない、通信で繋がっている
Slide 15
Slide 15 text
特徴
特徴
覚えずらい人の場合
Slide 16
Slide 16 text
どんな時に覚えずらい？
どんな時に覚えずらい？
一つの画面で
ソースコードを追えなくなった
ソースコードを追えなくなる
処理を追えなくなる
Slide 17
Slide 17 text
処理を追えなくなる
処理を追えなくなる
これが「覚えずらい」の正体
ソースコードの改修一切なくリリースまで行くことはない
追えないのは致命的
Slide 18
Slide 18 text
という事は
...
という事は
...
Slide 19
Slide 19 text
RDB
の正規化
RDB
の正規化
table
を複数に分けて共通のID
で管理
これも同じように覚えずらいのでは？
Slide 20
Slide 20 text
同じレコードに
...
同じレコードに
...
全カラムが入っている方が覚えやすい
結構あるある
Slide 21
Slide 21 text
class
の継承
class
の継承
同じ処理を様々なclass
内で使いたい
同じように覚えずらいか？
Slide 22
Slide 22 text
複数の
class
に
...
複数の
class
に
...
同じような method
が書いてある方が覚えやすかったりする
Slide 23
Slide 23 text
把握できる人と
把握できる人と
何が違うのか？
何が違うのか？
Slide 24
Slide 24 text
情報非対称性
情報非対称性
エンジニア組織論でも出ましたね。
「見えてるもの」が違う
エンジニア同士でもあるある話
「相手」の立場になって考える
Slide 25
Slide 25 text
特徴
特徴
「覚えられる人」の場合
Slide 26
Slide 26 text
絵・図で表現している
ホワイトボードに絵を描くと伝わる ->
あるある
Slide 27
Slide 27 text
No content
Slide 28
Slide 28 text
道具の使い方
道具の使い方
複数画面を並べて眺めている
エディタの画面分割を上手く使っている
そもそも一つの画面で追ってない
Slide 29
Slide 29 text
単純に「慣れ」
単純に「慣れ」
頭の中で通信の線が引けている
Slide 30
Slide 30 text
解消方法
解消方法
Slide 31
Slide 31 text
もちろんケースバイケース
もちろんケースバイケース
人によってポイント違う場合あるある
「そのコードの書き方知らなかった」
これも「あるある」話
Slide 32
Slide 32 text
道具の使い方問題
道具の使い方問題
画面分割やmethod
の追い方を「一緒」に探す
「解らないもの」を認め合える文化
これ大事
Slide 33
Slide 33 text
苦戦ポイント
苦戦ポイント
エディタは人それぞれ違う
使われる事が多いエディタに集約されるかな?
その場で情報交換しやすい方向
くれぐれも「vim
」は強要しない
自分が使っていても、正直おすすめしない
Slide 34
Slide 34 text
あ、ちなみに
...
あ、ちなみに
...
vim
だと「:sp
ファイル名」で分割できます
「:!fgrep "
検索文字列" */*/*.rb
」
rails
とかだと検索しやすいかな？
Slide 35
Slide 35 text
絵や図で描く
絵や図で描く
面倒くさがると描かなくなるんだけど...
ここも「重要」です。
コードを追えなくなる方が「もっと面倒」
Slide 36
Slide 36 text
絵や図のフォーマット
絵や図のフォーマット
ゆるく決める
そんなに拘らない
伝わって「頭の中で整理できる」方を優先
Slide 37
Slide 37 text
まとめ
まとめ
Slide 38
Slide 38 text
処理を追えなくなるのは
...
処理を追えなくなるのは
...
追えてる人と見えてるものが違う
Slide 39
Slide 39 text
把握出来る人を集めれば
...?
把握出来る人を集めれば
...?
手っ取り早そうな話だが、中々集めづらかったりする
業務知識をオブジェクトにしたものだったりすると特に...
人を選ばずにどうにか出来ないか？
Slide 40
Slide 40 text
処理を追えない事が
処理を追えない事が
「悪い訳」じゃない
「悪い訳」じゃない
Slide 41
Slide 41 text
「見え方」を同じにする
もしかしたら「自分が抽象化し過ぎている」かも？
これも、あるある話
謙虚さ重要
Slide 42
Slide 42 text
良い悪い で判断しない
良い悪い で判断しない
エンジニアなんで
合理的な判断をしたい
人 対 人 にしない
人々 対 課題にする
Slide 43
Slide 43 text
まずは「動くように」する
まずは「動くように」する
仕事なんで
動かないソフトはNG
その上で運用・開発しやすいように
教える事が最優先ではない
Slide 44
Slide 44 text
しかし
...
しかし
...
メンテできなくなったソフトは価値を失う
プロダクトの考え方
サービスが長続きするよう、開発し続けられるように
Slide 45
Slide 45 text
バランス重要
バランス重要
Slide 46
Slide 46 text
ご清聴
ご清聴
ありがとうございまし
ありがとうございまし
た。
た。