Cyber AgentのエンジニアJOBに参加した

この記事はなに？

Cyber AgentのエンジニアJOBというイベントに応募し，1ヶ月インターンさせていただいた時の記録と，得られたものや，反省点などを書いたもの．

参加させていただいた部署は，FRESH LIVEという，ライブ配信サービスを行う部署．

8月は，この部署で1ヶ月フルタイムで働いた．

したかった経験

自分はスタートアップでエンジニアとして，1年半働いていた．当初はギリギリ動くプログラムがかけるくらいの超初心者だったが，とりあえず飛び込んでみたのが今から1年9ヶ月ほど前．そこから1年半強経ち，新しい環境に飛び込んでみたくなったため，今年の6月に退職し，こちらの部署にお世話になることとなった．

挑戦はいっぱいしたいが，1ヶ月という短い期間なので，ある程度目標を立てて参加した．部署を決める前に，人事の方に相談(希望)した内容が以下の点．

吸収したいこと

• 大規模トラフィックあるいは大規模トラフィックの経験
  • 前の会社で大規模データの壁にぶつかり，解決法を模索したため
  • インフラレベルでの解決法など
• 高品質なサービスを継続して提供できるエンジニアのレベルを肌で感じたかった
  • テストをまともに書いたことがなかったので，テストをどこまで書くのかなど．
  • 開発スピードや，知識量，アウトプットや考え方など．
• インフラ周り
  • 調べたところ，k8sの導入などが進んでいた

希望したこと

• バックエンド
• 言語はなんでもいい！
• メディア系の事業部

これらの希望を出したところ，FRESH LIVEで働くこととなった．

何をやったか

FRESH LIVEでは，マイクロサービスアーキテクチャを採用している．また，言語はKotlin(つまりサーバーサイドKotlin)を採用している．こちらのスライドに書いてある．

この一連のアーキテクチャにおいて，とあるマイクロサービスの実装を1ヶ月でやってみた．要件としては，

• 機能追加時に柔軟に対応できる設計
• gRPC通信
• Kotlin(本当はGo(これなら書いたことあった)でもよかったらしいが，事業部の方針としてKotlinだったのでKotlinで頑張ってみることにした)
• Spring Boot 2
• Gradle

記録

最初の方

これで1ヶ月頑張るということで，インターン2日目くらいに要件が固まったが，当初は2つ目以降の要件がどうすればいいのか検討もつかない状態だった．

そもそもその単語が指し示す技術がどこでどうやって動くのかすらわからなかったので，最初の数日は，調べたりイメージをつかむことに費やした．特に，自分はJava及びJVMを使ったことがなかったため，Spring Boot 2とGradleもわけわからなかったし，Kotlinがどういうノリで動くのかもわからなかった．また，調べれば調べるほど知らない単語が出てくるので，脳みそが限界を迎えた時もあった．

gRPC通信に関しては，Javaと分離できる技術だったので，一旦Goで動かしてみて，イメージを掴んだ．

設計

2週目からは，設計を始めた．が，設計はアウトプットが出にくい故に，今やっていることが正しいのかわからなくなる時があり，気を紛らわせるために，Gradleを調べつつ書いていったり，Kotlin書いてみたりしてた．

機能追加時に柔軟に対応できる設計ということで，イメージを鮮明にする意味でも，一旦Kotlin書き始めたのは，間違っていなかったと思う．

リクエストのインタフェースの設計

リクエストのインタフェースの設計をする上で，gRPCというRESTとはまた違ったものになるので，慣れるのがとても大変だった．ここら辺は，ドキュメントを読んだり，他のリポジトリを参考にしたり，ツッコミをもらいながら，だんだん確立させていったが，最後の方までなかなか最適な答えにたどり着けず，設計の難しさを感じた．

OOPの設計

オブジェクト指向言語をちゃんと触ったのが初めてだったため，ここの設計もかなり苦労した．(概念は調べたりすることでわかってはいたり，すでにあるクラスを使うくらいはできたが，設計を1からした経験がなかったという意味の初めて)

設計やクラスについてググってみると，なかなか自分の知りたい情報にたどり着けず，こういう領域はまたちゃんと勉強しないとできるようにはならないんだなと感じた(なんとなくやセンス()だけでは全然ダメ)．

また，指摘を受けたのが，クラス名などの名前がめちゃくちゃで，何をやっているクラスなのか名前からわからないという点．これはあんまり意識できていなかったというか，言われて，「あ，たしかに」と思った．こうなってしまった理由として，クラスに対して,そのクラスが何をして，何を知っていて，何をするクラスなのかというのをあまり意識せず，今までの関数に切り出すぞくらいの気持ちでやっていたのがよくなかった．

DIという概念

これは実装を進めていく過程で指摘を受けた事項．上述の通り，自分は恥ずかしながら，今までテストをまともに書いたことがなかった．今回はそのコンプレックスを解消すべく，テストを書くことにしていたのだが，そこでDIという概念を教えていただいた．

DIというのは，現在の自分の理解では，

クラス内でインスタンス化すると，クラスの単体テストを実行する時に，モック化できていないと，結局そのあとに続くクラスを全て実装するまでテストができない．

そのため，クラスのインスタンス生成をDIコンテナに任せ，そこからクラスの引数として，DIコンテナからオブジェクトを受け取る．

Springにはそれを簡単にしてくれる仕組みがあるので，それを使うと，DI化できる！テストを書く時，オブジェクトをモック化できる！

という感じ．

デザインパターン領域は今まで全く意識を向けなかった領域だったのだが，DIの話を聞いて，なるほどと思った．

おそらくこういうのは，適当に作った結果苦しんだ人が，後世の人が苦しまないように知恵を絞った結果だと思うので，一回適当に書いて苦しむと，より恩恵を受けられるのかなと感じた．

実装

実装自体は，設計が決まれば進めていくだけだった，

機能的には膨大な要件ではなかったので，コード量的にも多くなかった．

Kotlinの文法などに関しては，途中から結構慣れてきた(詳しい部分はわからない，ビルドでエラーを吐く頻度が減っていったという意味)ので，あまり問題にはならなかった．

設計の適当さによって頭を整理できずにコードを書くことがあった．これをメンターの方に相談したところ，「設計の方が頭も時間も使う」と言われ，それを身を以て実感した感じとなった．

結果

求められていた2個の機能のうち，1個しか実装を開始することができなかった．

その，できた1個も，機能として完璧になったとは言えない結果になった(単純な実装になってしまった)．

しかし，Kotlin的なコードの書き方やテストなど，「それっぽいコードにはなってきた」とは言っていただけた．

感想(主に今後の課題)

アウトプットの質

基本的にアウトプットを文章で伝えていたのだが，これがなかなかうまくできなかった．自分の頭にあるイメージを断片的にしか伝えられず，メンターの方に思考を整理してもらってやっと共有できる状態になった．

設計が大事

設計がとても大事．とりあえず書き始めるというスタイルは後々の苦労を招くことがわかった．

実装前に，全ての処理を頭の中に思い浮かべて「あとは書くだけ」という状態にしなけばならない．

今後はもっと詳細に設計をイメージして，アウトプットを書いていこうと思った．

一ヶ月をやり直せるなら、設計段階でもっと先を見通せと自分に言いたい。

JVMわけわからん

今までJVM言語を避けて生きてきた．今後もそのままだと，エンジニアとしてちょっとまずい気がしていたのだが，巨大なすぎてなかなか一歩を踏み出せなかった．しかしその壁を，このインターンで越えることができたので本当によかった．

ただ，どこで落ちているのかなどが文法エラー以外でわからないことが多かった．今後も勉強して頑張っていけたらと思う．

まとめ

1ヶ月，自分の中ではかなり頑張った方だと思うが，振り返ってみると，成果物があまりない．もっと実装を早くできていたら，それらのデプロイに伴って，インフラを触ることができたのに，と思うと自分の実力不足がとても悔しい．

当初の目標でいうと，インフラを触ることはできなかったが，これについては，メンターの方にお話を伺うことができた．当然ここに詳細は書けないが，インフラの自動化ってめっちゃ楽しそうだなと思った．

当初の目標だった高品質なサービスを継続して提供できるエンジニアのレベルを肌で感じたかったに関してはなんとなくわかった気がする．これはうまく言葉では言い表せないが，体感できた．

Slackに自分の分報があって，そこに疑問などを投げたらすぐに返事をいただけたり，コードレビューを"ど素人みたいな"コードにしていただけたり，細かくフィードバックをいただけたりと，知らないことだらけの技術の中で，とても安心感があった．また，ランチにも頻繁に連れていっていただき，色々な方と話すことができたのもとてもよかった．

1ヶ月という短い期間ではあったが，とっても学びや反省の多い1ヶ月だった．

最後になりますが，サポートしていただいたみなさま，ありがとうございました！苦しみつつも，本当にいい時間を過ごせました．