２ヶ月前の内定者バイトを今更振り返る
こんにちは！
8~9月にサイバーエージェントにて内定者アルバイト(エンジニア)してきましたので、
軽く振り返りの意味を込めて記事にしました。終わってから2ヶ月も経ってしまってしまいました…
配属部署について
OPENREC.tvというサイバーエージェントの子会社CyberZで展開しているサービスのサーバサイドエンジニアとして配属されました。
OPENREC.tvはゲーム動画配信プラットフォームで、OPENRECキットといったゲーム配信に特化した面白い機能を提供しています。OPENRECキットは、配信を豪華に演出できるエフェクトツールで、視聴者とのコミュニケーションに連動して動くスタンプを自作して表示したりできます。
今回の目標
今回の内定者バイトで身に付けたかったことは以下でした。
- 保守運用を見越した設計や実装ができるようにする
- 今まで触ってこなかった言語に触れる
学生レベルではどうしても運用のことをあまり考えず、実装することが多いため、この機会で少しでも意識できるようにしたいと思っていました。
言語はあくまで開発するツールなので、開発方法やプロダクトに適した言語を選んで利用できるのが理想です。そのため、選択肢が多いことはエンジニアの武器だと思うので今回今まで触れてこなかった言語に挑戦しようと思いました。（中途半端に使える言語がたくさんあっても仕方ないですが…）
割り当てられたタスク
今回割り当てられたタスクは大まかに以下のようなものです。
CRUD+APIについて
Kotlin(CRUD+API)とTypeScript(API/BFF)を扱いました
（どちらもほぼ初めて触る言語です）。
CRUDやAPIに関してはそんなに説明する必要もないと思うので、
軽く触れるだけにします。
KotlinはWebフレームワークとしてKtor、ORMはExposedを利用して、TypeScriptのフレームワークとしてはExpressを利用しました。
比較的シンプルな言語だったのに加えて、コーディングルールがしっかりしていたため、とても書きやすかったです。仮に自分が今後所属するチームで新しい言語を導入する場合、このような環境を目指すべきだと思いました。
ログ設計について
「ログの目的やフォーマットは大事だ」
という記事はよく目にしますが、どういう手順で何を基準に決めていけばいいか、というのを説明するのは難しいと思います。経験則や勘に頼っているところが多く、正解もないものだと個人的に思っています。
ただ一番大事なのは「いざという時にログで流れを追うことできる」ということです。
今回、私はユーザから問い合わせがあった際に調査/対応しなければいけない場合を想定して取り組みました。シーケンス図とソースコードをみながらユーザが損をするケースを列挙し、対応や補填をすればいいかを考えることで、ログとして必要な情報を検討しました。
学び
学びは正直たくさんありました。
自分のコードの癖の把握
自分がよくやっている書き方とかレビュー反映を一部忘れるとか、普段の自分では気づきにくい、よくないコードや取り組み方をしっかり知ることができました。
（コードレビューが本当にすごかったです、感謝しかないです）
設計書の更新と開発速度のバランスに適応する
開発しつつ設計書を更新するというのは大切なことですが、設計書の更新をせず開発をするというのはよくあることです。
ドキュメントにはない設計（インタフェース部分）や共通認識がたまにあったりして、社員さんと自分の認識に相違が若干生まれたりしたこともありました。
もう少し現場の状況を把握しながら、取り組んでいればうまく回避できたかなと思います。また、設計書で足りない部分をいつの間にか補完していたということもよくなかったと思いました。補完自体は悪くないと思いますが、確認をちゃんと取らなかったことは失敗だったと思います。自分は補完する人間なんだと把握できただけでも、この失敗はあって良かったと思います。
システムの中で何を正しいとするか
これが一番印象に残っているのですが、ログ設計をしていく中で「何を信頼するのか」をしっかり決めないと、うまく流れを追うことはできないと指摘されました。
実際に、「ログは欠損/重複するもの」「DBは不正な値が入ったら終わり」「コードが正しく動作するとは限らない」「ユーザが嘘をついているかもしれない」という感じで全てを疑って総合的に判断するというスタイルだったので、軸が定まっていませんでした。
そこで言われた一言が
「ユーザに届く情報はDBのデータ、
ユーザにとっては届いた結果が全て」
これはよく考えれば当たり前のことではありますが、当時の私は衝撃を受けました。DBのデータに関係なしに、ユーザにはその情報が届き、その結果によってユーザは行動を起こすということです。
DBの変更履歴は別のDBに保存することで変更したことを保証できますが、誰からのアクセスでどんなデータによってその変更が行われたのかまでは把握できません。
そこで、ログを使ってデータを追えるようにするんだと理解しました。ログと全体的な関係が見えてきて大変勉強になりました。
Clean Architecture
想定外の大きい収穫としてはClean Architectureについて理解できたことです。チーム内のWikiにあった簡単な解説がかなり分かり易かったこともあり、実装しながらどの層がどんな役割を担っていて、どこと繋がりどんな流れで実行されていくかがわかりました。
今の自分の立ち位置
自分がどの程度のエンジニアで、実際の現場で何ができるのかというのを、今までは把握する機会と余裕がなかったのですが、今回は研究とかPBLではなく実際の現場における自分のレベルを少しは知ることができました。
まとめ
非常に成長することができ、楽しかった１ヶ月間でした！！学生では普段経験することないことばかり経験することができ、本当に感謝しています。
本当に社員みなさんが優しく良い人たちで安心して取り組むことができました。機能提案して実装している同期もいました。（本当にすごい……！）
自分も次は新機能を提案したいなとか、ぜひ次もサービスに携わりたいなと思いました。
