疎結合と認知

Transcript

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