# インターン参加で得た知見や感じたこと この記事は[CPS Lab Advent Calendar](https://adventar.org/calendars/3974)2019 15日目の記事です 14日目は[こちら](https://hackmd.io/@Cx80ALYHTnCN8wOzn5gXzA/BkdWrkYaS)から 16日目はこちらから ## はじめに こんにちは 久しぶりに部活動に顔を出したら全身筋肉痛になった、なるせいです。 僕もOBにハードワークさせていた立場なので因果応報だなと感じています。 さて、CPS Lab Advent Calendarの15日目を担当させていただくのですが、 内容は現在参加させていただいている長期インターンでの知見や感想を備忘録的にまとめようかなと思います。 イメージとしては、「何となく使っていた感覚が薄らいだ!」「なんやこれ便利やないかい!」「もっと早く知りたかった!」みたいになったインターンで改めて恩恵を感じたものや初めて知ったことって感じです。 CPS Labの皆さんは内定者インターンやら長期インターンやらバリバリ行っている方々がとても多いと思うので、そんなん知っているわということが多くなってしまうかも知れませんが、お付き合いいただければ幸いです。 以下お品書き 1. 参加している長期インターンの基礎情報 2. GitやGitLabの使い方周り 3. レビュー文化 4. 命名の難しさ 5. プロジェクトのフォルダ構造 6. StoryBook 7. CI(Jenkins)とreg-suit 8. 使用しているフレームワークのソースコードを読む大切さ 10. 検証班 11. アジャイル開発 --- ## 参加している長期インターンの基礎情報 先にも述べたとおり現在長期インターンに参加しています。 8月から参加していまして現在4ヶ月程経ちました。 内容は **Vue.jsを用いたモバイル版Webアプリケーションのフロントエンド開発** です。 ## GitやGitLabの使い方周り ![GitLab](https://upload.wikimedia.org/wikipedia/commons/thumb/c/c6/GitLab_logo.png/220px-GitLab_logo.png "GitLab") ちなみに、インターンに参加する前の僕のGitの習熟度は 個人開発の履歴を付けようという程度なので割と絶望的でした。 平たくいうとcommitとPushさえ出来れば満足できるような感じです。 以下の点に知見を得ました。 * Gitの基本操作 * コミットの粒度 * コミットメッセージ ### Gitの基本操作 ちょっとコミットを修正したかったり他のブランチの変更を反映させたかったりする時に使うコマンドがちゃんとGitにはありますが、僕は正直存在すら知らなかったものもありました。 例えば以下のようなコマンド達です。 * reset * amend * cherry pick * rebase 特にamendとかcherry pickとかは本当に聞いたこともなくて、 >「それチェリーピックしてもらって…」 って言われた時は、 >「(え、なに桜?いやそれはチェリーブロッサムか…)」 なんて考えてしまっていたものです。 まあでもここら辺の話はちゃんと勉強している人たちは インターンで初めて知るなんて事もないでしょう。 付け焼き刃で恥を晒しましたというだけのお話です。 知らんかったという方は是非調べてみてください! ### コミットの粒度 上記のようなコマンドを駆使してコミットをある程度自由に作れるようになったら、 **コミットをまとめるように**とご指摘をいただきました。 **コミットメッセージにフィットするコミットの内容を心がける** と言ったら当然のような感じではありますが、大事だなと思いました。 ### コミットメッセージ 上記でも少しコミットメッセージの話を出しましたが、 インターン先ではコミットメッセージのテンプレートがありました。 まあこれは外部サービス(RedMine)と連携するためってのもあるのですが、 統一性を持たせて見通しをよくするという意図も感じられました。 何てったって**チーム開発**なのでこう言ったルールの徹底の重要さを感じました。 ## レビュー文化 これは一番感銘を受けて助かったことかもしれないです。 自分のコードをまじまじと他人に見てもらう何てこと今までそうなかったからです。 あっても授業で提出したコードを採点して見てもらうというだけで 返ってくるのは成績と名を呈しているS,A,B,Cの評価だけです。 具体的にここがダメだからやり直しってのはあんまりなかった話でした。 インターン先は(恐らく)コードレビューの文化がしっかりある会社でして、 序盤の頃はほぼ全部突っ返されるどころか、 >「とりあえずここまで直して」 と言われていました。 直して戻したら続きが始まるわけですね。 最近は割と通るようになったので嬉しいですが、 今度は後述する検証班との戦いが始まっています。 ## 命名の難しさ 突然ですが、ここで私のレビュー突っ返されたランキングを発表しますと、 1. 変数名をもっと具体的に書いてください 2. 関数名をもっと処理に適した名前にしてください 3. このパッケージもう使ってないから消してください(これは本当にアホ) です! **命名わかんない!!** 別にふざけていたわけではないのに かなりの頻度で指摘をいただくことが多かった命名。 例えばboolean型の変数は `is~~`を何の気もなしに選択していたのですが、 `can~~`とか`has~~`とかの方が良いといったことがありますね! 言われればそうなんですが、 これを適切に初手から選択するのに序盤は苦労していました。 とりあえず以下のことが重要だと感じました * ある程度の英単語は覚えておきましょう * 慣例には従いましょう * 処理の内容を中心に考えましょう 特に三つ目は結構練習しないといけないなと感じています。 現在もまだまだ特訓中です。 ちなみになのですが、 インターン前からも僕は割と命名を気にかけていた**つもり**でした。 ただやはり**レビューしてもらわないとわからないな**という話です。 インターンに行かずとも、 バリバリ働いている先輩方に一度見てもらうのも良いことだなと思います。 ## プロジェクトのフォルダ構造 ここからはより内部的な話をしたいと思います。 二度目ですがチーム開発するにあたって ルールの徹底ってのはとても大事だなと思いました。 それがプロジェクトのフォルダ構造にも感じられました。 すごくざっくりいうと、 **かなり細かくフォルダの階層が刻んであった**のです。 大きなプロダクトを作ることになればなるほど こういったフォルダ構造のルールはとても大事なんだなと思いましたし、 何よりあまりの見通しの良さに感涙しました。 現在個人的なプロジェクトもリスペクト~~パクら~~して弄っていますが、 開発時のストレスがすごい減ってとっても楽しくなりました。 ## StoryBook ![StoryBook](https://cdn-ssl-devio-img.classmethod.jp/wp-content/uploads/2019/04/ba62c3e58340a68260ce48cf7bd43830.png "StoryBook") UIの開発するのにこれ無しだと嫌だあああという気持ちになってしまいました。 StoryBookはコンポーネントのカタログみたいなものだそうで、 コンポーネント化したUI達や実際の画面UIなどを一覧表示で見ることができるのです。 変更もリアルタイムで反映されますし、デモデータを渡して挙動の確認もできますし、複数のシチュエーションに対してカタログを増やすこともできます。 つらつら書いてもわからんと思うので、具体的やってたことは、 **APIの処理はひとまず置いておいてまずStoryBook上でUI開発を行う**といった感じです。 ルーティングとか取り敢えずは気にしなくていいので、ガンガンUI開発をすることができます。 またコンポーネントのカタログなので、 >「目的のUIを表現してくれるコンポーネントどこだっけ」 といった時も、このStoryBookのなかを捜索するだけで済みます。 とっても便利で感動したものの一つです。 ## CI(Jenkins)とreg-suit ### CIとCIツールのJenkins ![Jenkins](https://upload.wikimedia.org/wikipedia/commons/thumb/e/e3/Jenkins_logo_with_title.svg/230px-Jenkins_logo_with_title.svg.png "Jenkins") > CIとは、Continuous Integrationの略で、継続的インテグレーションと呼ばれています。 CI(継続的インテグレーション)では、開発者が自分のコード変更を頻繁にセントラルリポジトリにマージし、その度に自動化されたビルドとテストを実行します。 小さなサイクルでインテグレーションを繰り返し行い、インテグレーションのエラーを素早く修正することによりチームは統合されたソフトウェアをより迅速に開発できるようになります。 -https://cloudbees.techmatrix.jp/devops/ci/ これを実現してくれる優秀な執事としてJenkinsさんがいます。 やってくれることはまんま上記の説明通りです > 「PullRequestを送ったらなんかクルクルし始めてコメント欄にURLがポンっと出てくる…。そのリンクを踏んだら`yarn serve`とかで立ててた画面と同じものが見られる…。 え、何それめちゃくちゃ便利じゃん。 これマージして本当にちゃんと動くのか心配だなとか思わなくてもいいのかよ」 知ってる人からしたら当たり前かもしれないですが、ファーストインプレッションでは僕はえらく感嘆しました。 Jenkins以外にもCircleCIというものもあるらしく個人的に勉強したいです(理由はNoOpsあたりの話) ### reg-suit キーワードは`Visual Regression Test`です。 >「Webページのスクリーンショットを以前のバージョンと比べて、ピクセルレベルでの差分を検出するテスト手法」 -https://techblog.lclco.com/entry/2017/01/02/204804 というとてもわかりやすい説明に尽きます。 このスクショっていうやつに関して前述したStoryBookのコンポーネントカタログをバシバシ撮ってます。 一番効力を感じるのは、 **いろんな箇所に使われているコンポーネントを修正した時**です。 全ての使用箇所を完全把握することや、手作業で確認を行うことは結構な労力です。 reg-suitが回ると、 >「こことこことここがなんか差分出てるで!大丈夫か??」 > と言ってきます。それが想定内の変更だったらヨシ!違ったら確認する形です。 この話に関しては[某先輩のスライド](https://logmi.jp/tech/articles/321974)がとても良いです(小声) reg-suitで[画像検索](https://www.google.com/search?q=reg-suit&sxsrf=ACYBGNREf0G5Xdw1CPvWW1cCsQ7p9kXdMg:1576383469427&source=lnms&tbm=isch&sa=X&ved=2ahUKEwj-_uWF5rbmAhW1JaYKHQK3BgMQ_AUoAnoECAwQBA&biw=1440&bih=821#imgrc=_)すると候補欄に「とべ」ってキーワードが出てくるんすよね… なんでそこが切り取られたのか… ## 使用しているフレームワークのソースコードを読む大切さ ここからは少しマインド的な心がけです。 わりかし最近の話なのですが、 インターン先でアサインしているプロダクトには実はPC版がありまして、 こっちのが本家みたいな感じなのである程度仕様を合わせる必要があります。 そんな中で使用しているフレームワークが PCとモバイルでバージョンが違ったために差異が生じてしまった というシュチュエーションがありました。 これはフレームワークのソースコードとにらめっこする事で気づけました (使用する正規表現が変わっていたんです)。 インターン始める前の頃、 **フレームワークのソースコードなんて読めるわけがない** とか思っていた節がありました。 しかし、チーム開発ですので他者のコードを読む頻度が爆発的に増えました。 そんな中、 いざ件のフレームワークのソースを読むってなった時は少し緊張しましたが、 実際はそんなに苦しいわけもなく普通に読めるもんだなと思いました。 ただこれには **他人のコードを読むようになった** というバックグラウンドがついてまわるのかなと感じます。 何気ないことかもしれませんがこの漠然とした恐怖感がなくなったのは個人的には 背中を押してくれる大きな発見でした。 ## 検証班 プロダクトを作っている会社なら何処でもあるのかなと思う検証班。 まずあらゆるデバイスを使って検証し、 細やかな差異やバグを発見するのが素直にすごいなと感じます。 **ただまあ検証が通らない通らない** いつまでたってもマージできません。 特に最近初めてiosとandroid間での異なる挙動のするバグを体験しました。 噂に聞いてた闇をやっと感じられた気がします(?) それはさておき、何を体感したかと言いますと、 **他所の班に仕事を依頼する** ということです。 ここで会社なんだなという感覚を感じました。 部署とかそういうのは誰でも知っていることですが、 そこに内在するコミュニケーションを取る力や円滑に連携を取れるのかなどはかなりナイーブな話だと気づかされました。 そういったものを取り持ってくれるPMなどの役職の重要性も肌で感じるようになりました。 ## アジャイル開発 ここまでツラツラと書かせていただきましたが、今回のインターンでの開発手法はアジャイル型開発でした。 この経験はとてもためになるものであると僕は考えています。 実際にスプリントレビューに参加して自分のスプリントの成果発表などを行ったりしています。 --- ## 終わりに 色々と書いてしまいましたがインターンから最も感じた印象は、 **チーム開発をするにあたって破茶滅茶なことにならないように守るべきルールを徹底している** といったところです。 このルールは実に合理的で綺麗なものだなと感じました。 そして、そのルールを遂行する上でStoryBookやJenkinsやreg-suitなどの 便利なツール群の手助けを借りること、 また最終的には人と人とのコミュニケーションを いかに取るかというところまで内包されるものなのかなと感じました。 …知見というよりかはポエムみたいになりましたが、 誰かにへーそうなんだーと思っていただけたら嬉しいです。 説得力がないのでダメ押ししときますが、 たった4ヶ月のインターンでも爆発的な知見を頂けたのは事実です。 かなり見える世界が変わりました。 ありがとうございました! ###### tags: `プライベートブログ`