ゆるふわ技術日誌

エンジニア見習いの悪戦苦闘日記

グループ開発をしてみて得た知見をメモる #309

毎日技術日誌

謎の開発合宿を終えた

2日間の開発合宿に参加していました。

テーマが決められていて、今回は8人のチームでWebサービスを開発しました。

作ったものとかはまぁTwitterとかから察してもらうとして、グループで一つのプロダクトを開発してみて得た知見や反省を忘れないように列挙してみる。

分担は正解、その分仕様はしっかり定義しよう

Webサービスを作るということで、サーバーサイドのプログラムを担当する人とフロントエンドを書く人で担当を分けて開発を行うことにしました。(私はフロントエンド担当)

これは、(うまくいけば)正解なんじゃないかと感じました。

ただ、「どんな技術を使うのか」とか「ライブラリはあれが便利」とかそんな話で初っ端に盛り上がってしまって、いざ作り始めようとする直前に「どのような機能を実装するか」とか「その機能を実装するにはこのようなAPIが必要」とかいう話をほぼすっ飛ばして作り始めてしまいました。

結果として、フロントエンドを書いていた私は、自分が作るのであればこんな感じで実装するだろうという想像＋作業しながらの雑な会話だけで、APIの仕様を思い描いて実装をすすめることになってしまいました。

フロントエンドとバックエンドを分けて開発することに決めたのには、最悪サーバーサイドの実装に遅れが出てもモックAPIを立てて実装を進められるのではないか、という目論見がありましたが、それをやった結果、僕とサーバーサイド担当の認識の乖離が更に広がって大量の修正をする羽目になったという…。

多少、たくさんの時間を使ってでも仕様の定義はしっかりと行ってそれをチーム全員の共通認識にするこれは必須だろうと思いました。

てかそれを夏に学んだのに今回実践できなかったのが悔やまれる。

技術的美しさには意味がある

2日の開発期間で、アイデアの確定＋実装ということでほぼハッカソン状態(ハッカソン出たことないけど)だったので、技術的に美しいつくりに凝っている時間はないと判断して手当たり次第実装を進める、という方針で作業を進めました。

結論から言うとこれは、(部分的には正解だけど)基本的にはやってはいけないと感じました。

確かに最初は、サクサクと実装を進めることができたのですが、ある程度コードが大きくなってきて機能を増やしていくフェーズに入ったときにだんだんと、「このファイルはどこに置くんだ」とか一つの機能を実現するコードが複数のファイルに横たわっている(e.g. APIを叩く部分をmoduleとして切り出したのに、使う側がaxios(HTTPライブラリ)の仕様を知っている必要がある)とかいう事態が連発してみるみる地獄のクソコードへと進化していきました…。

設計とかは大規模なプロジェクトに必要なもので、短時間でちゃちゃっとアプリケーションを作るだけなら必要ないと思っていましたが、それは大きな誤りで効率よく開発を進めたいとき、つまり時間的余裕がないときにも有効だと感じました。

これも、時間を少し使ってでも設計をやってから実装に入るべきであったと思っています。

ほうれんそうは大事

プロジェクトの進め方、的な話ですが、自分の担当でない部分についても進捗状況については全員で共有すべきであったと感じました。

私もそうだったので人のことは言えないですが、開発が加速してくるとテンションが上がって自分の担当に熱中してしまって、周りの状況が見えなくなりがちだと感じました。

仮に、最初の段階で十分に仕様などについて打ち合わせをしてたとしても、ちょっとした認識の差から実装にギャップが生まれてしまうということはありがちなのではないかと思いました。

進捗共有は大事だと思った、という話。(困ってることとかも共有したら、解決策を知っている人がいるかもしれないし…!)

といった感じでしょうか…。

まぁとにかく、技術的な意味よりもこういったチームでやらないとわからない知見をたくさん得た2日間でした。

自分たち以外のチームの発表もきいたのですが、どのチームも全体のアーキテクチャを紙に描いたものとか、クラス図とかが出てきたので多分僕の言っていることは間違ってないんだと思う。

何をやるにもコミュニケーションだし、最後は言葉で自分の思っていることを伝えられないと、上に書いたことは達成されないので、言語化する訓練(と言っても何をしていったらいいのかはよくわかってないけど)をやれるとよいのかなぁと思いました。

雑談

帰ってきたらすっごい眠くなった。

今回はフロントエンドはSPAを使ったので、APIをインタフェースに分担すればいいというのはわかるのですが、(だからこそAPI仕様を定めて、共有しておくべきだった)これがもし、ViewにWebフレームワークのテンプレートを使用するという仕様だったとしたら何を共通認識にして分業したらいいのかがよくわからなかったです。(だからSPAを採用した)

今回サーバーサイドはRailsを用いていたので、分業するとなるとViewを書くひととModelとControllerを書く人という分担になるのでしょうか…?

自分が下手なのかもしれないですが、ModelやControllerの実装を知らずにViewだけを書くのは無理があると感じています。なので、これもSPAの利点なのかな?と思って発表のときにﾁﾗｯと言ってみたのですが、無反応だったので経験豊富な人たち的にはどういう感想を抱くのかが気になりました…というのを思い出したので書いてみた。

↓

これ質問してみようと思って文章にして考えてたらなんとなく答えが見えた気がします。

多分フロントエンドの部分とバックエンドの部分をどうしても並行して開発したいということになると、Controllerの部分の外部仕様(なにをなんて名前で返すか)を固めて、その後分担という感じになるんじゃないかと思いました。(要はインタフェースになるのがAPIなのかControllerなのかという違い?)

Controllerをmockできたらなお、やりやすいんだろうなと思ったのですが、調べて出てくるのはRspecのstubの話だけで、Viewの開発をするときに使うものではないみたいなので、どうやってやっていくのが正しいのかなぁとまた疑問が増えてしまいました。(そもそもModelやControllerの実装が終わらないままにViewを作るのはアンチパターンなのかな?)