途中参加のプロジェクトに慣れるまで

近況

　最近、これまでとは違うプロジェクトに途中参加することになって、大きな環境の変化に対応する日々を過ごしていました。

　これまではフロントエンド・バックエンドの両方を触っていましたが、今はほぼフロントエンド専任です。

　技術的にはNuxt.jsが中心で、Angularに似ているとはいえ、その違いを吸収するのに時間を使っていました。

　事前にNuxtとVueの情報を拾っていたので「たぶん、行けるだろう」と思いきや、プロジェクトの理解に半日ぐらいかかって、自分の中で困惑することが多かったので、その知見を書いてみようと思います。

プロジェクトを理解するまで

実際の画面を触ってみる

　参加するころには大体の画面はできていたので、とりあえず何も考えずに触ってみました。ある意味、ユーザー目線に近かったので、この時の気持ちを書いておけばよかったのでは、と今更ながら思ったりします。

　何となく20分ぐらい触って大体の機能を拾っただろう、とこの時点では思っていたのですが、ここで開けなかったページがあったみたいです。

　手探りだと体系的にはいかないですね。ちなみに仕様書はあったそうですが、「最初は書いていたけど、更新されている自信はない」といわれたので、あまり確認していません。

フォルダ階層をざっとみる

　Nuxtは基本階層が決まっているので簡単かなと思ってみていました。

　２階層目以降は、スマートフォンとPCでコンポーネントを分けているという話を事前に聞いていたので、まだつかめました。

　3階層目はドメインごとに切られていましたが、ここがわからなかったです。実際の画面の言葉は日本語で、ファイル名は英語なのでそこが微妙にしっくりきませんでした。

　それでもなんとなくは理解して、これで仕事できるかなと思いました。

直近のIssueを直してみる

　Issueをつぶすのが当面の仕事だと言われていたので、直近3つぐらいのものを適当に取り出して、直せれば理解できたんじゃないかと勝手に考えて、やってみました。

　ですが、全然できませんでした。

　Issueは大体ドメインの言葉で書かれていて、それがどこに当たるのか全く分からないという感じです。Issueも砕けた表現が多く、暗黙的に大体知っているよねみたいなコンテキストで書かれている気がしました。

　なので、まずIssueの内容が理解できなかったので、その対策を考えました。

用語表を作る

　とりあえず、ドメインで使われている用語、変数名、意味の対応表をひたすら作っていきました。

　コンポーネント志向なので、その階層も意識しながらひたすら書き込んでいきます。

　そうすると明らかに同じ意味でありながら、違う変数名があったり、違う階層なのに名前が近いものなど不思議なものもいくつかありました。

　そういう絶妙なものが理解を難しくしていたところもあり、それをはっきりと定義づけできるとやっとIssueの意味が理解できるようになりました。

コンポーネントを図にする

　最後にIssueはデザインを修正するものだったのですが、意味が分かってもコンポーネントの配置関係がわからないと直せないなとなりました。

　最初は開発者ツールでやっていましたが、同時の視認性が弱いなぁと思って、スケッチブックにページごとにコンポーネントの配置を書きました。

　それで見ると、どこがデザインの要なのかがわかって、それでIssueの解法がわかりました。そこまでくると、他のIssueもやっつけられそうになったので、理解を終えました。

知見

Issue駆動でプロジェクトをとらえる

　最初は漠然とプロジェクトを見ていましたが、「何を知りたいのか」「何を直したいのか」をはっきりと定義することで理解が加速した気がします。

　それがIssueである必要はないと思うのですが、はっきりとした問いを立ててそこから理解するようにするとものの見方が定まるように思います。

用語を理解する

　用語の問題がここまで大きいとはあまり考えていなかったです。バックエンドのロジックであれば、DDD的なものの見方が大事だと思っていたのですが、フロントエンドの部品もドメイン的な性質が大きいんだなと感じました。

　名前と意味を正確に定義するということ、フォルダの切り方の大切さと、最初にそれを説明するのが結構大事なんだなと思いました。こういうのもREADMEにあってもいいのかもしれないですね。

手を動かす大事さ

　見るとか、理解するという感覚は漠然としやすいです。なので、書くことが大事な気がします。

　コンポーネント図を作っていると見やすいというのもありますし、能動的な頭の働きがあって、疑問とかも浮かびやすいです。なので、最近は複雑なことを始めるときは大抵紙から始めます。

　Scrapboxとかに表を書くこともありますが、どちらにせよ見るではなく新しく作るのがいい気がします。

まとめ

　今までライブラリとかを覗くことが多かったので、「今回も大丈夫だろう」という謎の自信があったのですが、実際業務レベルで理解するとなると戸惑うところが大きかったです。

　これまではベストプラクティスの勉強が多かったのですが、そこにドメインが絡んできたり、デザイン回りの話が絡んだりで必要な見方が違ったんだろうなと思います。

　その中で問題を整理しながら、理解のための手順を踏めたのはいい経験になりました。

　あとから、Vue.jsのDevtoolsを使えば、もっと早かったのでは思いましたが、紙に書くのが少し楽になるぐらいの感じでしょうね。

　新しくライブラリを見るときあたりに、こういう視点で見れたらまた知見がありそうなので、それもやってみたいです。