DMMのサマーインターンに参加した
サマーインターンのURLどこだっけ...？（笑）
参加した経緯
自分は、まだ参加すらしてなかったジロッカソンで世界を取ることを約束した。
逆求人なのに、出てすらいなかったハッカソンのアイディアについて、面白そうに聞いて頂きありがとうございました！
そして、世界を取った。
この有言実行が実ったのか、DMMのインターンに参加させて頂いた。
インターンで何をやったか
menusという健康的な献立レシピをレコメンドするサービスのバックエンドエンジニアを1ヶ月間やっていた。
DMMでは、menusは新規サービスに当たる？のだが、大きいIT企業での新規サービスの開発・雰囲気が知りたくてmenusの事業部を選んだ
このmenusがリプレイス段階で、menusのAPIをDjagoからRailsへ移植・改善を行った。
主には、この画面のAPIを担当した。現在は、それぞれの項目を編集後、右上の保存を押さないと更新されないので、それぞれの項目を編集後、独立してPatch処理を投げるように改善しながらリプレイスする。項目によっては独立して更新ではない部分もあった(これが、ちょっと大変だった)
仕様が曖昧だったので、PO(プロジェクトオーナー)に仕様を突き詰めたり、場合によっては栄養士さんに確認していただかないといけない部分だったりがあった。社員の方にフォロー頂きながら進めたが、DB設計からAPI実装までやりきった。
流れは、
インターンに参加して思ったこと
仕様をPO,アプリチームに確認する
自分みたいに、途中からジョインするような人(前からいる人も)は、とにかくコレが大事だと思った。実装中に、リプレイス前のアプリ(現行)のもので見つかった仕様なども逐次確認していた。
あとは、アプリ側が逐次APIを叩くか、キャッシュするかとかはサーバーだけで考えるものじゃないし、アプリ側の処理によってはAPIのパラメータに含める内容も変わって来る。
SQLの発行回数を考える
当たり前のことだが、テストでも、SQLの発行回数を考えるのは重要だと思った。
コミットログ
これを一番指摘された気がする。
コミットしたソースコードで何をしたかは、コードを見ればわかるので、「何をしたか」ではなく、「何でこうしたか」を書くべき。コミットログに関しては、短いよりは長いほうが良い。
自分は「何でこうしたか」は、基本的にPR に書いていたが、このやり方では、GithubからBitbucketに乗り換えたりした時にログが残らなくなってしまう（乗り換えなければ気にしなくても良いのかも…）。でも、レビューされる時など、なんのための変更かわかるようにすることは重要だと思った。将来の負債にも関わる大事なことだと思った。
レビューする側になる
自分がインターンであるとか、立場に関わらず人のコードをレビューする。インターン参加はじめの頃は、たまに[ask]を投げる程度であったが、後半の方は自分が指摘されたことを共有する意味でもレビューすることができた気がする。
他の人のインターン内容が聞ける
DMMは、事業の幅が広いので、他の部署でインターンしている学生がいる。DMMにインターンに来ている学生は、みんな超優秀でコミュ力が高かったので、わかりやすく何をしているか教えてくれる。（ビッグデータ、プラットフォーム、インフラ...etc）
残念だったこと
作成した機能が、実際に世に放たれて、ユーザーの反応とかが見れたら最高だったと思ったが、それができなかったのが心残りという感じ。
六本木の飯は美味い
下の2つはまじでおすすめ
