こんにちは。2024年8月にCA Tech JOBに参加させて頂いたインターン生の加茂友基です。
約3週間、LDH所属アーティストの動画・MV視聴サービス「CL」のフロントエンド開発に携わせてもらいました。
今回のインターンで学んだことをまとめていきたいと思います。
CA Tech JOBに参加した理由
私がCA Tech JOBに参加した理由は、クオリティーの高いプロダクトの開発現場を見てみたかったからです。私はプライベートでよく個人開発をしており、自分自身で試行錯誤して開発を進めています。しかし、自分が正しいことをしているのか、間違えたことをしているのか、よくわからない状態になることが多々あります。レベルの高い環境に飛び込んで、質の高いアプリケーションを開発するための知識をつけたいと思い、参加しました。
期間中のタスク
シリーズとアーティストを紐づけたUI
CLには、各アーティストのページがあります。
そのページにアーティストの番組シリーズを表示するタスクを任せてもらいました。
また、各アーティストのシリーズ一覧ページも作成させてもらいました。
フォーマッター・リンターの移行
CLでは、フォーマッターはPrettierを、リンターはESLintを採用しています。
これらをフォーマッター兼リンターのBiomeに置き換えるというタスクです。
Biomeに置き換えることで、フォーマッターとリンターを1つに統合することができ、
ルールの競合が起きにくくなります。
また、BiomeはRust製のため、CI実行速度が格段に上がるのもメリットの1つです。
学んだこと・気づいたこと
膨大なコード群を読んで
CLはフロントエンドのリポジトリだけでも、コードが膨大です。
チームに参加してから最初の3日間は、アーキテクチャの理解に時間がかかりました。
ただ、コードを読み進めていくにつれて、とてもきれいに整理整頓されているなと感じました。
例えば、データフェッチはoperation→usecase→serviceというように、依存関係をクリアになっており、
一度理解してしまえば、困ることはありませんでした。
フェッチしたデータはselectorを経由して使用します。
各レイヤー層が最小の責務を持つように徹底されており、保守しやすい構造になっていました。
データフェッチ周りは、ステートの更新とAPIリクエストが複雑に絡み合って、
汚いコードになりがちなので、とても勉強になりました。
品質を担保するための工夫
・Desing Docの大切さ
CLのWebチームでは、タスクに着手する前にDesign Docという設計ドキュメントを書きます。
Design Docには何を、何のために、どのように解決するかを書きます。
これを書くことにより、実装の全体像や背景を他の人と共有でき、コードの保守がしやすくなります。
業務中に過去のエンジニアの方のDesign Docを読むことがあり、実装した本人に聞かずとも
コードの理解ができました。
このようなことから、Design Docは品質の担保のために大切だと思いました。
・レビューが広い視野を与える
CLのWebチームは全員がレビュアーの役割を持ちます。インターン生の私もレビューをさせて頂きました。
実際にコードレビューで、疑問に思ったことを聞いてみて、自分とは違う考え方で実装していることに気付かされました。
個人開発だとどうしても考え方が凝り固まってしまうので、柔軟な発想をするためにもレビューは大事だなと再認識しました。
私は、レビューは自分のミスを客観的に指摘してもらえるものだと思っていたのですが、
指摘の場というよりも考えを深める場であるという認識に変わりました。
・開発者体験を大事にする
CLのWebチームでは、コードのリファクタリングやテストの自動化など、開発者体験を
向上させるために様々な工夫が凝らされています。
例えば、PRを出した時に、フォーマット・リンターチェック、単体テスト、VRTレポート、E2Eテスト
などが自動で実行されます。
また、Wrikeというタスク管理ツールを使用しているのですが、PRを出した際にタスクの状態が
自動更新されるようになっています。
このような工夫は、業務の効率化、品質の向上に寄与するため、とても健全な開発環境だなと感じました。
エンジニア同士のコミュニケーション
チーム開発において、コードに関する相談は日常茶飯事です。
メンターの方に相談する際に、自分の考えていることをうまく言語化できないということが
よくありました。
プログラミングは抽象的な概念であるため、自分が理解していることを
人に伝えるのはかなり難しいと感じました。
専門用語を使うことで、コミュニケーションコストを減らせますが、
私は感覚的な理解をすることが多いため、単語を用いた説明があまりできませんでした。
これからは、単語を用いた記号的理解を意識していきたいと思いました。
他職種の方とのコミュニケーション
ありがたいことに、今回の業務では様々なミーティングに参加させてもらいました。
そのため、デザイナーさんやPMの方とコミュニケーションを取る機会がありました。
デザイナーやPMの方は、コード設計がどのようになっているかが分からないため、
実装にかかるコスト、既存のコンポーネントを使い回せるかなど、エンジニアしか分からないことを
的確に共有するのが大事だと学びました。
また、個人開発では、仕様の変更のコストはそこまで大きくないのですが、大規模なアプリケーションではとても大きくなってしまうため、事前のすり合わせがとても大事だと実感しました。
数字に繋げるための開発
CLでは、ただ機能の修正や開発をするだけではなく、それによって数字にどのような影響を与えたのかをしっかり分析します。また、集計ログをもとにエンジニア、デザイナー、PMの方々で次のアクションを考えます。開発が手段ではなく、目的になってしまうのはよくあることだと思うのですが、CLでは開発=手段という考えを徹底しており、とても勉強になりました。また、職種を超えてチームで色んなアイデアを出し合うのはとても楽しかったし、プロダクトに関われている実感があってとてもいいなと思いました。
理解という状態を考え直す
今回、私はESLint + PrettierをBiomeへの移行を任されました。
Biomeは型情報が必要なルールを搭載していないため、
ESLintのルールを完全にカバーできないという問題がありました。
私は、そもそもESLintの一部のルールは型情報を参照していることを知りませんでした。
結局、トレーナーの方に相談して、2人でtypescript-eslintの公式ドキュメントを眺めながら
1時間ほど議論しました。
この経験から、普段つかっている技術を全然分かっていないことに気づきました。
他にも、リンターのルール設定を相談した際には、eslint-plugin-airbnbのソースコードを
眺める時間もあり、ソースコードを読んで理解を深めることが大事だと気付かされました。
成果
シリーズとアーティストを紐づけたUI
２つのページにカルーセルを追加
新規ページを作成
フォーマッター・リンターをBiomeへ移行
リンター → 速度を約28%向上
フォーマッター → 速度を約94%向上
最後に
約3週間、CLのチームの一員として色んな貴重な機会を与えていただいた、トレーナーのよっしーさん、CLチームの皆さん、本当にありがとうございました。短い期間でしたが、エンジニアとして大事なことをたくさん学べたと思います。さらに技術力をつけるためにこれからも頑張ろうと思います。
CA Tech JOB、オススメです！