心理的安全を担保するために、友達同士で設計について語る会を開いた
はじめに
おばんです、最近腰が痛くて爆発🚀💥している田中です。
今日は心理的安全を担保した設計の勉強会をやりました。 コンセプトはこんな感じ。
「設計」というと「怖い」という語がうしろにきがちなテーマなので、見知った人を集めて小規模に、心理的安全性を高めつつやろうと思います。 解釈が合ってる、間違ってるとかは気にせず、気軽にYATTEIKI。
設計の話ってマサカリが飛び交いがちで、いろんな人のいろんな解釈があって怖いということには共感していたので、「じゃあひとまず友達同士でやったら、心理的安全を担保しつつ、認識のすり合わせとかできるのでは？」と思ったのでやりました。
参加者の一人であるハゼさん(@haze_it_ac)もまとめを書いてくれました。
やったこと、話したこと
自己紹介
- 初めてリアルで顔を合わせる人同士もいたので、名前とidを言ってもらった
- 普段やっていること、得意とすることによって「設計」という言葉に持っているイメージは異なると思ったので、技術領域とかを言ってもらった
- 主な参加者の技術領域のキーワードは次のような感じ
設計とは
- いろんな種類の設計がある
- アプリケーション設計
- Web
- モバイル
- エンタープライズ
- インフラ設計
- テスト設計
- etc...
- アプリケーション設計
- 設計にもいろいろあるので、どの設計の話か絞って、その設計に必要なものは何かから話がしたい
- たとえば
- アプリケーション設計
- GUIに関する知識
- プラットフォームに関する知識
- インフラ設計
- ネットワークに関する知識
- セキュリティに関する知識
- 「どこを専門にするかの話はあるけど、それぞれ関連しないわけでもないので、知識はあったほうが良いよね」という話も出た
- アプリケーション設計
- 参加者がアプリケーションエンジニアが多かったので、ひとまずアプリケーション設計という単位に絞って話を進めることになった
- この前提をふまえて、みんなはアプリケーション設計について何に困っているの？をざっくばらんに話していくことになった
フレームワークに依存したコードが辛い問題
- フレームワーク前提で開発をすると、細かな調整が効かなかったり、依存しているためにそのフレームワークと心中することがあるのがつらい
- フレームワークは怠惰に済ませるためのものなのではないか？
- 完全に切り離してしまうならフレームワークとしての意味がないはず
- フレームワークにも設計思想がある
- どこからフレームワークに依存するか、という程度問題の話もある
- フルスタックフレームワークいらなくね？問題
- 設計に強い人は小さいフレームワークを組み合わせる
- そうじゃないとよくわからんのをがーっと入れちゃう
- フレームワークの良さは、全体をいい感じにして細かいことを考えなくて済む点
- フルスタックフレームワークでもコントロールできるものとできないものがある
- 設計に弱い人でもちゃんと揃えられるようにフレームワークを用いるという観点も必要
- いろんな開発メンバーがいる中で、どうやって認識合わせをやっていくか
- パターンを当てはめるときに、メンバー間の知識量の差をどう埋めていくか
- 多くの場合は共通認識がとれないままプロジェクトが走り出してしんどくなる
MVホニャララがわからん問題
- 「GUIアーキテクチャ」と「システムアーキテクチャ」という分類がある
- GUIアーキテクチャ
- MVC, MVP, MVVM, Flux, Reduxなど
- UIに重きを置いてパターンの分類
- Model: 画面に関係ないものすべて
- View: 画面の表示
- Controller/Presenter/ViewModel: ModelとViewの間でどうやり取りするか、どうデータを同期させるかなど
- システムアーキテクチャ
- ヘキサゴナル, オニオン, クリーンなど
- UIよりも大きな範囲であり、Modelの部分にどういうパターンをあてはめるべきかまで語られている
- layerという概念もあり、描画に関わる部分・アプリケーション固有の部分・外部のシステムとつながる部分・データそのもの まで語っている
- なぜパターンで混乱するのか？
- 人によって解釈が違うから
- 例えばMVPの中でも色々な形があり、それが広まるごとに人々は誤解していく
- 原点と、開発メンバー間で簡単にでも、コードに落とし込んで認識を合わせるのが大事
- データの同期方法、
- データの置き場所など
- GUIアーキテクチャのパターンはいろいろあるけど、データの同期方法と、どこにどういうデータを置くかの違いを把握していくとわかりやすい
- 具体的な書き方がわからん！問題
- 設計コンセプトだけ言われても、自分が関わっている領域・言語での良い書き方がわからない！
- 「（わからないが）わかる！」
- 良い感じにまとめてくれてるところを探そう
- https://peaks.cc/books/architecture_patterns
- https://peaks.cc/iOS_architecture
- http://amzn.asia/d/441IluL
- https://www.slideshare.net/pospome/go-80591000
- GUIアーキテクチャとシステムアーキテクチャの違い
- サーバーサイドとクライアントサイドで関心が違う
アーキテクチャの管理をどうやっていくか問題
- 依存関係の把握とか
- コードレビューでカバーする
- 組織がスケールしない場合はこれで回る
- 「強いレビュワーがやめたらどうなる？」
- 「知らんのか」
- 「組織が死ぬ」
- 正確には強いレビュワーが辞めてしまう状況が出来てしまったら、組織が死んでいるという話
- ドキュメントでカバーする
- ドキュメントの解釈違いも発生する...
- そもそもドキュメントが古いとか、足りないとか...
- レビューのタイミング
- 実装する前のレビュー
- 実装した後のレビュー
- 実装する前のレビューの認識が合っていなければ、実装した後のレビューも合わないよね
- 実装した後にレビューすると、設計がダメだった時の手戻りコスト高いよね
- Design Doc
- コードの近くにREADMEを置いて設計の話をまとめておく
- 各パーツの大本となる部分のディレクトリに置いておく
- 少なくともその時点での設計の意思決定の経緯をまとめておける
とまあ、こんな話をとりとめもなくざくざく話していったりしました。
