freeeの2weeksインターンに参加した振り返り

# freee エンジニアインターン
9月11日から9月22日の２週間にfreeeさんのインターンに参加しました！
グローバルチームに配属され、GoとReactを用いた開発を携わった。

## Day 1

環境設定やPCセットアップを行なった。SSHでEC2をリモートアクセスするのが初めてなので、それがすごく面白かった！Goで簡単なsyntaxと構造が分かるくらいだから、もっとGoを勉強した方がいいだろうと感じている。

雰囲気はオンラインなのでイメージしにくいところはあるけど、インターン生同士と社員の交流がとてもやっていて、情報の共有とかもしっかり行なっているという印象。
しかし、ドキュメントがめちゃくちゃ詳しい！freeeの「あえ共」カルチャーなのかな？社内記事もたくさんあり、slackで色々な質問がある。遠慮なく質問することができる。フリーな空間や働き方ができる気がする。

セキュリティがすごくしっかりしている。多くのユーザーがいるサービス・企業。
グローバルチームが去年からなので、やや新しいチーム

## Day 2

日本らしくない働き方（時間ではなく、アウトプットがあればOK）
グローバルチームは結構スタートアップの感じもするし、外国人がたくさんいるかな？

15分ルール
・一人で15分考えて、他の人を聞いた方がいい
・じゃないと他の人の時間を奪ってしまうが、それ以上時間かかると自分の時間も奪ってしまう

https://zenn.dev/nameless_sn/articles/question_handbook

夕会で自分の振り返りもでき、インターン生同士の作業状態や学びが参考できるから、ここはすごくいいなと思う。

forkしたレポをupstreamブランチにsyncする時に以下のコマンドを打つ

```
# git remote add upstream url をした後に、GitHub上でsyncを行うこともできるが、CLIでやるときに
git fetch upstream
git merge upstream/master
git push origin master
```

https://qiita.com/jsasaki/items/f77c23f4fea3f7edb812

## Day 3

インターン生同士で新機能追加、デザインが既にある。仕様を考える上で、issue切って、実装に入った。2人ともGoでバックエンド触りたいからペアプロやってみた（自分はドライバーで面白かった！自分が思ったことを直接言えるし、一緒に考える人がいるから理解度が増えたと思う）

学び
- マイグレーションを行う時に葉っぱからやっていく（dependencyが少ないところから）
- タスクのdependencies（例：タスクAを先にやらないとBに進めないとき）基本的にそのPRからブランチを切る

https://stackoverflow.com/questions/51378279/dependent-task-and-pull-request

ここで記事書いてみた！

https://qiita.com/chanon-mike/items/9da267d7ae87e9b32fef


今日で気づいたのが、オンラインにも関わらず、コミュニケーションをすごくできた。非同期コミューニケーションはこういう感じだなーと思った。チーム内だけで5カ国出身の人がいるし、言語バリアもあるかもしれないけど、仕事が順序に進んでいるのがすごい！こういう多様な環境が日本の企業に見えるのが意外だった。

フィードバック
- キャッチアップ、タスク着手が早い
- 小さいタスクでも当日でPRを作成できた
- どんどんタスクが欲しいと言ってくれたので、すごく良かった
- タスクの理解やコミューニケーションができた

## Day 4

仕様を把握できて実装に入ったけど、途中で曖昧なこともあるのに確認してなかったので、それはもっと注意した方がいいかも。社内パッケージ利用するので、どういう意味なのかを他のレポを参考にしながらコードの意味を深めた。

Goは書いてて楽しい！やはり、読みやすいのが一番かな？でも、色々慣れなくわからない概念がある、例えば、method receiverやGoでのpointerなどだ。コードが見れる間で、レポを参考にしながら勉強しといた方がいい！（VSCodeでJUMPできないのがちょっと面倒... IntelliJでJUMPできると聞いたなー）

Reactのnamed exportはできるだけ使ったほうがエラーが少ない。理由は、importの名前を変更したらeditorによってトラックされないこともある。コンポーネントだとdefault exportがいいかもしれないけど、apiやactionだとどの関数がどこに使われているのかわからない。

フィードバック
- プロダクトをもっと深く理解して、なぜやるのかをもっと理解した方が成長する
- 他のチームがもっとユーザーデータが厳しいかもしれないから、設計が厳しくやる（短い間だからこそ設計をちゃんとやる）

Factory Pattern

- 日常的に使っていないパターンは多草なるけど、factoryパターンはまだ使われている
- Objectが大きければ大きいほど、作るのが面倒くさい
- 簡単に作れるようにする
- 特にmockデータとかで、一部の情報を用意して、簡単に作ってくれる

https://refactoring.guru/design-patterns/factory-method

https://sourcemaking.com/design_patterns

デザインパターンとかですごくわかりやすく書いてくれるサイトです！

## Day 5

感想
- 一周目の最終日になった！頑張ろう！
- オンラインで国が違ったことにも関わらず、しっかりコミュニケーションとってて、チームは仲がいい
- 夕会の振り返りがやはりいい！自分の振り返り＋他の人の学びと進捗

Good Communication Practice

学び
- 元々あるコードのスタイルを真似してコードを書いたけど、古いコードにもなるし、前のコードも今のユースケースと合わない時もあるから、それを意識してコードを書いた方がいい。でも、やはり正解はないかな？状況を見るって感じ。
    - 今回の具体例：前は編集する必要があるから、stateで管理するけど、今はreadだけなので、stateが必要ない。しかし、前のコードを真似して、stateで管理してしまった。
- Goとかで理解すると思ったが、理解しなかったコードもあるので、やはり調べながら進む必要があるんじゃないかと思う
- 大規模チーム開発でよく使っているgit commandを覚えるべき。`git stash`や前のコミットを戻すなど色々vscode上で操作するよりもCLIで打って覚えたい。

フィードバック
- 全て理解する必要はない。実際の仕事でも、大体入社すると0->1のプロダクトでなければ、既にあるプロジェクトに入ると思うから、よくわからないものはいっぱいあるだろう。
- ジュニアはミスが許されるから、疑っていいし、色々質問する機会だ！
- シニアが全てを知るわけでもないので、疑ったら質問する（初日はオンラインでなれないのもあるけど、今はきけいに質問できた！）

## Day 6

2週目の週明け！
あえ共で自分の趣味とかについて話した！

Throttle and Debounceの説明（以下は英語でメモしておきます〜）

Throttle
- Limit the amount of request call in the interval of time
- Triggered events: is the number of time request is called
- Handled events: is the number of time request is successfully handle

Debouncing
- Debouncing waits for a certain time before invoking the function again.
- Example 1: In an auction, someone bid for $100, auctioner wait for 5 seconds before deciding the deal, if no one bid, that bidder win, else starting a new timer for another bidder.
- Example 2: User typing a keyword, and waiting for some cooloff time for last type character before executing an event.

https://stackoverflow.com/questions/25991367/difference-between-throttling-and-debouncing-a-function

https://www.youtube.com/watch?v=E9XcoEMu1lk

react-selectのv2からv5にマイグレーションを行うかどうかをPR basedで議論した
throttle-debounceのtypesを追加（documentを読みながら適切なバージョンを選んだ）

## Day 7

TypeScriptのutility type（Partial、Pick、Requiredなど）はなかなか個人で使わなかったので面白かった。便利なので、今後もっと使ってみたい。（zodとかまで必要ないかな？大規模プログラムでなければ）

ここのインターンでのコード読む時間・理解が結構早かったと感じた。

## Day 8

開発できる日のラスト！頑張ろう！

Golangで0、falseを渡すときにnullになることがあるので、ポインターにする必要がある。
例：
```go
type Example struct {
    test bool `json:"test" binding:"required"`
}
```
falseを渡すとエラーが出るので、ポインターをつける！
```go
type Example struct {
    test *bool `json:"test" binding:"required"`
}
```
こういう感じで解決できる！

Nested try catchブロックでエラーがわかりにくい。ちゃんとエラーをthrowするのかを確認し、バグを起きないように考えた方がいいかも。

アジャイル開発でのタスク管理がわかった、今後のチーム開発でのissueの書き方やPRの書き方を参考にする

## Day 9 (Last Day)

オフィスツアをして、スティッカーやTシャツをいただきました！
オフィスの皆仲がいいなと思います！基本的にオンラインなのにコミュニケーションがちゃんとしていて、楽しく仕事できると感じている。

お疲れ様会では他のインターン生と交流でき、就活の状況、やったことなどについて色々話した。
最後にfreee Tech Nightがあるので、そこの社員さんと色々話して交流した！

## まとめ

成果
- 作業フローのUX改善で作業完了が約2倍早くなり、自然なフローに改善できた
- 元々エンジニアが直接データを追加するが、admin画面から追加できるようにした
- JSからTSに移動（途中）

チームメンバーからのメッセージで
- 初日からコミュニケーションがすごくできた！
- 技術力があり、綺麗なコードのPRを出せる。また、タスクがどんどん消費して、新しいチケットをどんどん追加しないといけない（ありがとうございます！）
- 熱意をもらって、インターンの時思い出したらい。そう聞くとめちゃくちゃ嬉しいです！そう聞くと、働いていくというのが熱意がだんだん減っていくというのが当然かもしれない。ずっと、このような好奇心や学ぶmindsetを持って行動していきたい

学んだこと
- Agile開発
    - Agileボードの管理方法
    - issueやPRの書き方で背景、やったこと
- もっとWHYを重視したい！
    - なぜその実装をするのか？なぜこのメソッドを使って、このような実装をするのか？など理由を元にした行動ができるといいと思う
- テストについて考える習慣がついたので、テストコードをもっと書こう！
- 記事などアウトプットをたくさんする！思ったこと全てをメモしたらいいんじゃないかと思う。（ログ、日報、学んだことなど）
- やはりエンジニアって楽しい！この気持ちをキープして行きたい


感想
- 交流が多い、1on1、フィードバック、インターン生同士など
- 社員同士の環境ですごく仲がよく、発言しやすい環境になっている
- 非同期でいろいろな国、出身にもかかわらず、コミュニケーションが良かった
- 皆の成果発表で見る、すごく価値がある機能を開発していると感じている！
- フィードバックをちゃんととって、嬉しいアップデートをユーザーに届ける環境だと思う
- 成果発表会で皆の成果がすごい！課題をちゃんと理解して、2週間の短い間でも価値があるものを開発できたし、学んだことを参考にした
- 色々なチームの成果発表を見て、一つのIT企業（freee）はどういうチームがあるのか、それぞれはどういう仕事をやっているのかをイメージできた。これはすごいと思う！たとえば、SRE、セキュリティーなど色々なよくわからないチームっがるけど、成果発表によってイメージがついた！
- freeeではdocumentがすごくしっかりしている。環境構築、設計の背景・実装、出会ったトラブルの共有など共有の文化がすごい！エンジニアはdocumentをたくさん残るべきと聞いたことがあるけど、それはこういうことなんだなーってわかった

すごく楽しい2週間でした！ありがとうございました！