モブプロしてみた2
ラボアドベントカレンダー 5日目（5/1）です。5/1の31時にポストしてますが、5/1です。いいね？
4/30に行ったモブプロの様子をお伝えします。
※ モブプロ慣れていません
※ Clean Architecture は、原点のブログ（翻訳版）は読んだけど、本は読んでなく、割とオレオレです。
※ 僕は、悩むくらいならクソなものでもいいから書き始めよう派です（マクドナルドメソッド大好き）
作っているもの
都内某所にあるラボのためのアプリです。
Clean Arthicecture的な話
・ src/domains は、Use Case と Entity をひとまとめにしたものです
・ src/adapters は、interface adapter 層です
脱脂綿さんのターン
まずは脱脂綿さんがドライバーを開始しました。
モブプロ1の時に、作成したdomains/tips の createTips ですが、相談の結果要らんよねということになりました。
実際にウェブUIを組み立てていく時に、使い道がピンと来ねーぞ、皆は画面イメージどういうの考えてるの？からの画面イメージのすりあわせが始まりました。
元々、createTips というユースケースは、僕が別途開発中のもの（Clean Architectureの実験を兼ねてるやつ）のコードを元に作ったんですが、ラボアプリにおけるTipsとは性質が異なるため、ユースケース自体が適さないものでした！
まぁ、そういう間違いも簡単にみんなの目と手で修正出来るのがモブプロのいいところだよね！と前向きに捉えましょう。
相談の結果、Tips一覧を管理する画面が1つ生えました。
・ 文字列入力フィールド（input or textare）がある
・ ADDボタンがあり、これを押すと、Tipsがリポジトリに追加される
・ この画面自体はTips一覧を表示する機能も持ち、Filter部分でフィルタリングできるようにする（たぶんソートも）
・ 一覧には、Tipsの文章と編集ボタンがある（書いてないけど削除ボタンとかも）
・ 編集ボタンを押すと、文字列入力フィールドに旧来のTipsが入り、ボタンを押すとアップデートする
画面イメージの共有って重要だよね！という話でした。出来ればFigmaを使った画面イメージ共有をやっていきたいところです！！！
さて、今回書いたAddTipsは、ADDボタンを押した時の挙動である、Tipsをリポジトリに登録するユースケースです。
もっとさんのターン
次は、つよつよエンジニア mottox2 さんです。
ADDボタンを押したら、先ほど作成したaddTipsユースケースを叩くというコードです。個人的にはボタンは <button onClick={}> で作っちゃう派ですが、formにしておくと、enterの処理もついでやってくれたりするのでこっちの方がまっとうなコードになります。モブプロ、学びがある！
・ コールバックをuseCallback フックでリファクタリング
React HooksなFunctionComponentなので、何かあるたびにコンポーネント関数、その都度 handleSubmit が生成されては form に登録されます。
そこで useCallback を使うことで、不要な handleSubmit 生成をしないようにします。React Hooksで、ちょっと面倒なあたりと言えます。
ここまでで、Tipsを入力してADDボタンを押したらlocalStorageに保存されるまでができあがりました。実際にブラウザ上で試してみて、Chrome devtoolの Applicationタブから、localStorageにデータが保存されていることを確認できました。
作業の流れとして考えていることですが、Clean Architectureなどのlayered architecture でユニットテストを使った開発は、ウェブ開発からすると、一段階抽象化されたものだったので、バランスを取るためにつなぎ込みを書いて、ウェブとして動くものを作ってみるという流れを取りました。
抽象化されたコードと、実際にウェブとして動くコードを繰り返すと、思考モードや視覚・聴覚などのモード遷移としてバランスがとれるかなーというのが僕の持論ではあります。（ほんとは一日目、ここまでこれたら、コーディング・ユニットテスティング・localStorageによる実際のデータが入るまでを体験できて、面白いかなーくらいに考えていた）
・ 一覧を取得するために localStorage.findAll を作成
入力するだけだとdevtoolを使わないと確認できないため、次は一覧を表示できるようにします。
そこでまずはadapters/local-storageで、findAllを作成します。
ユニットテストでは1つのユースケース（jestのtest関数）のみにしていますが、本来であれば複数のユースケースに分割することが望ましいかもしれません。
分割すると、どこに問題があったかを把握しやすいことと、コードをぱっと見た時に把握しやすいというメリットがあります。
・ 単体のキーを取得できるテスト
・ 無関係なキーを排除するテスト
・ 複数のキーを取得できるテスト
このような分割が考えられますが、単体と複数のテストを分割するのはやり過ぎかも？とか、これくらいの事例なら1つのテストで十分でしょ？などあります。
もしかしたら、このあとfindAllを捨てるかもしれません。凝りすぎたテストを書くと、その時にダメージがでかくなります。
分量がそれぞれ少なく、テンポ良く書けたので3つ連続のコミットになりました。次はドライバーが変わります。
Forteさんのターン
・ 一覧を取得するユースケースとして fetchAllTips を作成
ぶっちゃけ、ネーミングはめっちゃ悩むところです。allTipsなのか、Tipsesなのか。そもそも最初からTip/Tips にしとけば良かったのか？tipsはtipの複数形だけど、最初からtipsという1つの単語だよねという。dataと同じようなもんですかね。datumなんて使わんでしょ的な。
英語力が弱い面々なので、どれが正解なのか悩ましかったですが、ひとまずallTips としておきました。allじゃないTipsの集合体はどう表すべきなんでしょうね？？？
ここでメンバーから「TipsRepositoryPortとTipsPortってなんで分けてるの？」という質問が入りました。これは、TipsRepositoryPortというリポジトリパターンのポートと、プレゼンテーション層のためのTipsPortを分けるためです。
名前としては、TipsPortじゃなくて、TipsPresentationPort の方が良かったのかもしれません。その場でぱっと思いつかなくてTipsPortになっています。
僕のターン
この日最後のドライバーは僕でした。
参加者のうち2名がReact Hooks知らない（というか元々Javaやってる2人）だったため、ここで useEffect の説明をもっとさんがしてくれたりしつつ、useEffectを使って、一覧を読み込む処理を追加しました。
useEffectの第二引数をいったん [] にしているため、追加したあとに明示的にリロードが必要なのはご愛敬です。
allTipsの名前がかぶるため引数の方をtipsesにしたりしています…。ここらへんどうするのがベストなんですかねー。ステート用の変数名と、ハンドラの引数が同じ用途の場合よく困ります。開き直ってシャドウイング（つまりステート変数とハンドラ引数を同じ名前にする）してしまうという邪悪な手もありますし、allTips2 みたいな邪悪な名前にするという手もあります。
ちなみに domains/tips の方は気にしないでください…。
まとめ
ここでは書いてないですが、メンバー全員、様々な学びがありました。JavaScriptに慣れてない2人はJavaScriptについての理解が深まったり、設計や画面イメージの共有って大切だよね！という初歩的なところに立ち戻ったり、クリーンアーキテクチャーだとこんな風になるのか！（ただし、オレオレなので…）とか、こんなショートカットキーあるの！とか。
モブプロは、バックグラウンドの違う人間が集まってわいわいやると、とても楽しいです。
この記事が気に入ったらサポートをしてみませんか？