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