はじめに
エキサイト株式会社の就業型インターン「Booost!!!」に9月から取り組みました加来 安東(かく あんとう)です。今回インターンで取り組んだこと、自分の学べたことなど振り返ります。
自己紹介
私は、現在、情報系大学の情報メディア工学科の3年として在籍をしております。
プログラミング自体は大学からスタートで、関数？ 構造体？なんじゃそれと超がつくほどの初心者でした。
そこから時間を見つけては自主学習をしてみたり、個人開発で商品在庫管理アプリを作ってみたり、ハッカソンやインターンに参加をしボコボコにされたり、と色んなことを経験してきました。
これまで参加してきたサマーインターンでは、期間が短いのもあり、がっつり会社の実務を経験することはなく、インターンで実際の業務に取り組んで成果を出すというのは、今回が初めてでした。
配属先で取り組んだこと
Life&Wellness事業部で、電話占いサービスにおいて、特定の占い師を目立たせるバッチを表示する機能の改修に取り組みました。
自分が得られた学び
クリーンアーキテクチャの概念について
元々、Go + クリーンアーキテクチャで、バックエンドを作っていたのもあり、概念については押さえていました。
クリーンアーキテクチャで重要なことは以下の3つだと思います。
- controller → usecase → repository → infrastruture(外部DB,外部API) という外から内へ依存すること(依存性逆転)
- 依存性逆転には、interfaceを利用し、抽象化されたものに依存するようにする。→ 実機能ではなくあくまで抽象化された機能に依存しているため、依存先の変更による影響を受けない。これがコードの保守性・拡張性、モックによる差し替えが簡単でテストのしやすさに繋がる。
- controllerはHTTP処理のみ、repositoryは、DBの永続化処理のみなどの責務の分離
今回はこれに加えて、service層やviewModelなどより細かい層に分割していました。
これは、規模が中規模〜大規模であるからが故に、細かく分割しているのかな？と思っていたのですが、開発チームごと文化が反映された形が今のアーキテクチャだと教えてもらいました。
実務でクリーンアーキテクチャが実際にどのように構築されているかを見て、どう動いているのかを確認する経験はとても貴重なものになりました。
また、実装する処理について、どの層に担わせるのが適切かを考える良い機会にもなりました。
例えば今回の、バッチを付与するかしないかの判断では、当初ビジネスロジックに関する処理のため、usecaseにその処理を書けばいいのでは？と思っていたのですが、これは、バッチを付与する + 他のキャンペーン処理など複雑な処理を実装する場合は、usecaseに担わせるべきですが、今回は対象の占い師の先生が取ってこれる、存在しているのならバッチを付与して表示するというシンプルな実装なので、ViewModel側でいるかいないかの判定メソッドを作成して、Bladeで表示という形が一番適切だと知ることができました。
しっかりと根拠や理由を持った上で、実装を行わなければ、後で自分が何をしているのかわからなくなってくる問題が起きるのだなと分かりました。
今後しっかり判断するための軸を持った上で実装に取り組まなければと感じました。
不要なtry/catchの使用 (なんとなくで実装しない・書いたコードに責任を持つ)
自分は普段の開発の時、APIを叩いた時try/catchで囲む癖がありました。
今回のコード作成でも、try/catchを多用してしました。
しかし、例外を出す必要性がないため、try/catchを使わなくていいというレビューをいただいた時、自分って特に理由や背景も持たずになんとなくでtry/catchを使用しているのは？と思い、try/catchについてもう一度復習することにしました。
try/catchを使う際に考えるべきことは以下の2点だと考えています。
- try内でエラーが発生する可能性ないなら、そもそもtry/catchを使う必要がない。
- catchとしてはtryで拾ったエラー(例外)に対して追加で新しい処理を加えたい場合に使用される(catchの用途の一つ)
自分はここら辺のことを何も考えずに、API処理に対して、try/catchで囲っていました。
これは良くない動きをしたなと反省しています。
就業中に、エンジニアとして自分の作った処理、実装に責任を持たないといけないと教えていただきました。
大切なのは、コードに対してなぜこの実装をしたのか？どういう背景なのか？の根拠を持って実装することであると、それが責任を持つことだと学ぶことができました。
自分の作ったコードに対して、理由や根拠をしっかり持つことは今後の開発でも活かすことができると思った重要な概念でした。
依存性注入について
テストコードの作成は、今回が初めてでした。テストコードの作成が一番難しかったです。
GETAPI、POSTAPIそれぞれに対しての作成に取り組んだのですが、特に印象に残っている部分は依存性注入についてです。
特に時間について取り扱うときに、依存性注入の考えが必要になります。
テストをする時、input に対して output が不変なものが求められます。
実行ごとに結果が変わっている時、テストがうまくいっているのか判断ができないからです。
時間というのは、実行ごとに値が変わってしまう変化があるものです。これを不変なものにしたいです。
その時に使われる方法が依存性注入という方法で、テスト関数が外部のオブジェクトに依存するように仕向けたものです。
具体的には、時間に関するクラスのインスタンスを外部で生成してから、その値を関数に渡すことで、外部に依存させるようにする。
これによって、時間が不変なものでなくなり、テストとして求められる形になります。
この概念は今まで学んだことがなかったので、テストをする際はただコードを作っているだけでなく、様々なことを考慮して作らないといけないのだなと面白い発見が多々ありました。
開発する時に特に意識したこと (自分が普段から意識していること)
教えてもらった内容、アドバイスを聞いて終わりにしない
人間は忘れやすい生き物です。
聞いてそうなのねとその時理解できていても時間が経てばやっぱり忘れてしまいます。
朝会や質問中に教えていただいた内容は、終わってから必ず自分でもう一度整理することをしています。
これには以下の2点の目的があります。
- 記録として残しておくことによって、振り返りをしやすくするため。
- 自分で本当に理解しているか？言語化できるか？を確認するため。
2については、特に重要です。自分が目指しているのは、小学生にも説明できるレベルで言語化が行えるかということです。
このインターンで一番避けたかったのが、わかった気になっているということです。
なので、わからないなと思った部分は、素直にわからないと言って、ぼんやりとした理解から確固たる理解へと落とし込みました。ただでさえAIが発達していて、エンジニアとしての在り方が変わろうとしています。
AIは、自分の持っている知識0から1の1を10や20にしてくれる存在だと思っています。
逆を言えば、AIが0から1を生み出すことはできない、必ず人間の手が必要になります。
自分で理解することをサボってしまうと、AIの答えが果たして正しいものなのか？求めているものなのか？の判断すらできないと思います。
なので、私はしっかり理解した知識を自分のものにするということを現在、今後も大事にしていこうと思います。
積極的にコミュニケーションを取ること
就業期間中は、積極的にコミュニケーションを取ることを意識しました。
具体的には、自分の業務の進捗や状況をslackの自分のチャネルに発信することをしました。
これは、自分で抱えていることが正しいことなのか、それとも違っている部分があるのかを判断することができず、情報を開示して第三者に見てもらうことによって、ズレや認識の違いを早急に知れたらという考えがありました。
また、疑問点は、なるべくすぐ質問することを徹底しました。
しかし、積極的に質問をしすぎたあまり、相手の時間を多く取らせてしまった部分もあり、あるいは自分で調べれば解決できそうな内容ももしかしたらあったのでは？と思いました。
これについては、
- 事前に質問内容をまとめる
- 会話を始まる前に、〇〇の2点について質問したいですと要件を伝える
これらを意識するだけでも、相手側がどれくらいの時間がかかるかの見積もりを行えるので、その配慮を行うべきだったと反省しています。
