新卒がベンチャーで3ヶ月働いてみて

新卒エンジニアの氏家です。今年の4月にvivitにジョインしてから3ヶ月が経とうとしています。 1ヶ月ごとに開発チームを移りながら様々なvivitの事業とそれを支える技術に触れてきました。 (主にWebメディアhinataの開発を行うmediaチーム→キャンプ用品のレンタルサービスを提供するhinataレンタルの開発を行うrentalチーム→主にインフラや各事業の開発環境の改善などを行う事業横断チーム)

今回は私がこの3ヶ月で学んだことや、vivitの技術開発部で働いてみて率直に感じたことを話していきたいと思います。

学んだこと

コードレビューの重要性

私が1番成長を感じたタイミングはコードレビューをされているときでした。 自分の書いたコードに対して指摘していただくことで、いかに読みづらく、冗長だったのかが分かります。 さらに「こうしたほうが良い」というアドバイスまでしてくださるので、その時だけでなく次に活かすことができます。

自分がレビュワーのときも先輩のコードを見て学ぶいい機会なので、分からないからと適当にApproveせずに、どのような意図でコードを書いたかなども意識しながらレビューしています。 (と言いながら難しい実装や自分の知らない領域のPRをレビューするときは周りの様子を見ながらなんとなくApproveしてしまっているので、分からないものは自分で調べたり、素直に分からないと言えるようになりたいです)

コードレビューはコード品質の向上や変更の共有だけでなく、知識を得るという点においても重要なものだと学びました。

趣味と業務の違い

私は学生の頃から趣味でプログラミングをしていました。 単純な技術への興味から勉強することもあれば、ものづくりのための手段として使用することもあります。

しかし趣味のプログラミングが自己満足の域を出ず、自分のコードを他の人に見せることが無かったため、コードの可読性を意識することもなければ保守性などについて気にすることもありませんでした。 あくまで動けばいい、自分が読めればいいの精神で培ってきた「趣味のプログラミングスキル」は、あまり役に立たないことがこの3ヶ月で分かりました。

もちろん基本的な構文やコーディングの知識を知っていて良かったと思う場面はありましたが、それらは意識していなくても勝手に身に付いていくものだと思います。

コードを書くうえで可読性や保守性が重要であることは理解しているつもりですが、実際に業務として取り組まなければその重要性に気付けないので、 可読性、保守性の高いコードを書くスキルや、適した実装方法を選択するスキルなどはこれから働いていくなかで身に付けていきたいです。

余談

私はコードを書くこと自体が好きで、今でも趣味でwebアプリケーションを作って遊んだりしています。 「趣味でそこそこの規模のアプリケーションを作れるようになる」というざっくりとした目標があるのですが、徐々に技術の幅が広がり、より複雑な問題を解決するアプリケーションが作れるようになっている気がします。

業務で培ったプログラミングスキルで趣味が捗り、趣味のアプリケーション開発の経験が業務に活かされていると感じます。 いつか自分の中で趣味と業務の境目が無くなり、どちらでも質の高いコードが書けるようになれたらいいなと思っています。

vivitの技術開発部で働いてみて

最初に感じたこと

まず最初に感じたことは「エンジニアとして成長できそう」ということです。単純なプログラミングのスキルだけでなく、コミュニケーション能力や課題解決能力など、エンジニアとして働くうえで重要な部分を伸ばしていけると感じました。

vivitの技術開発部では自分が何をやりたいか、どのように成長したいかなどをなるべく尊重してくださるので、自分のキャリアパスに沿って働いていける環境だと思います。

また、vivitのエンジニアは知識量が豊富だと感じていて、新しい技術や開発のベストプラクティス、フレームワークのアップデート情報などを共有してくれます。 vivitではモダンな技術を積極的に取り入れているので、常に様々なところにアンテナを張り、開発に役立つ情報を収集していきたいです。

エンジニアの雰囲気

もう1つ働いていて感じたことは、エンジニアの雰囲気が良いということです。これに関しては運が良かったとしか言えないのですが、やはり働く上で人間関係は重要な要素の1つです。

就活で分かるのは会社の事業や働き方だけで、インターンに参加しても「インターン生を相手にしているときのエンジニア」しか分からないので、こればかりは実際に働いてみないと分かりません。

まだ入社して間もないですが、なんとなく会話されているときやSlackでチャットしている様子を見ると、お互いリスペクトがあるのだと感じます。

私に対しても偉そうにものを言ったりいい加減な指示を出す方は一人もおらず、分からない部分は丁寧に教えてくださったり、私の成長を考えてタスクを選んで振ってくださるので、素敵なエンジニアばかりで本当に運が良かったです。

社員50人程度のベンチャー企業でここまで環境に恵まれるとは思っていなかったので、その恵まれた環境に感謝しながら、エンジニアとして成長していけたらと思います。

おわりに

あっという間の3ヶ月でしたが、今の自分には何が足りなくて、何をする必要があるのかが明確になりました。 これからエンジニアとして10年20年働いていくために、今からできることをやっていきたいです。

私事ですが、今までのような1ヶ月ごとにチームを変える働き方から変わり、7月からは新規事業の開発に携わる予定です。

まだまだ分からないことだらけで多くの人に迷惑をかけると思いますが、これからも「成長する」「業務をこなす」の2つに重点を置いて取り組んでいけたらと思います。


vivitではアウトドア事業で共に働く仲間を募集しています。興味がある方は下記リンクからお願いいたします。 www.wantedly.com

リーダブルコードから学ぶ、新卒エンジニアが特に気を付けたいコードの書き方

新卒エンジニアの氏家です。 私は普段読書をしないのですが、私が尊敬するエンジニアは様々な技術書や指南書を読んでいるので、私も読書する習慣を身につけることにしました。

最初の1冊目として、「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック」を会社の福利厚生で購入しました。

www.oreilly.co.jp

これを選んだ理由は、多くのエンジニアから良書だと勧められていたのと、これから開発する上で「良いコード」を書けるようになりたいと思ったからです。(単純)

リーダブルコードの概要や具体的な内容については他のエンジニアの方々が丁寧に紹介されているので、ここではリーダブルコードを読んで学んだ、新卒エンジニアという立場の僕が特に気を付けたいと思ったコードの書き方について話していきたいと思います。

抽象度の低い単語を選ぶ

例えばcheckStrという関数があったとき、値の有無、文字列の長さ、条件に合致しているかどうかなど、具体的に文字列の何をチェックしているのか分かりません。

checkという単語の意味が広すぎるので、書き方を変えたり、類語を調べるなどして、より抽象度の低い命名を心がけるようにします。 (例えば値の有無を確認したければisEmptyexists、ある条件を満たしているか(有効かどうか)を調べたければisValidなど)

リーダブルコードではこれらを「カラフルな単語を探す」と表記していて、

シソーラス(類語辞典)を使って調べよう。友達にもっといい名前がないかと聞いてみよう。英語は豊かな言語だから、選べる単語はたくさんあるはずだ。

とあります。

たまに抽象的な単語の代替案が思い付かなかったり、仕様と微妙に異なる英単語を選択してしまったりすることがありますが、 英単語が分からないのは単なる知識不足なので、他の方のコードを読んだり自分で調べたりして、自分の中の「命名で使える英単語辞典」を更新していきたいです。 (だからといってあまり使用されないような難しい単語を使わないよう、どこまで明確にするかの線引をする必要があります。)

まだコードを書き慣れてないときだからこそ、意味が明確な命名になるよう、使用する単語を選ぶクセを身に付けたいです。

コメントを書く

まず前提として、見ただけで何をしているか理解できるコードについてコメントを書く必要はないはずです。 というよりも、見ただけで何をしているか理解できるコードを書けるようにならなくてはいけません。

しかし、それでも複雑になってしまうコードや読み手に伝えたいこと(コードからは分からない仕様や前提条件など)はコメントとして残しておく必要があります。

次の定数を見てみましょう。

const ENTERABLE_NUM = 2

なぜENTERABLE_NUM = 2なのか、理由を知らない人が見ても分かるように以下のようにコメントを書きました。

// 東京はまん延防止等重点措置下のため
// 酒類を提供する飲食店に入れるのは2人まで
const ENTERABLE_NUM = 2

このコメントがあることでなぜENTERABLE_NUM = 2なのかが明確になりました。

コメントの書き方

上記の例では仕様をそのまま書いただけなのでコメントの書き方で悩むことは無かったですが、コードによってはどのようにコメントを書けばいいか分からなくなってしまうことがあります。

リーダブルコードではこうした状況に直面したとき、

  • 頭のなかにあるコメントをとにかく書き出す。
  • コメントを読んで、(どちらかと言えば)改善が必要なものを見つける。
  • 改善する。

という3つのステップを踏む方法が紹介されています。 まず伝えたいこと、コメントで残しておきたいことをつらつらと書き出し、文言や書き方を改善したほうが良さそうなものを探し、分かりやすいよう改善する。 たったそれだけですが、悩んだ結果まとまらずコメントを残さないということが無くなります。

他のコードにはコメントが無いから、うまくコメントを書けないから、と躊躇せずに、コメントが必要だと感じたらまずは書き出すようにしたいです。

巨大な式を分割する

例えば以下の様なコードがあったとします。

if(textValue.split(" ").length > 2) {
  ....

このコードでは、入力された名前にミドルネームが含まれているか確認しているのですが、ぱっと見で何をしているか分かりません。次のコードではどうでしょうか。

const containsMiddleName = textValue.split(" ").length > 2
if(containsMiddleName) {
  ....

コード自体は1行増えましたが、このように式を一度変数に代入することで、ミドルネームが含まれているときに特定の処理を実行しようとしていることがすぐに分かります。 この変数は「説明変数」と呼ばれており、名前の通り式の意味を説明してくれています。

他にも、複数の条件が入り組んだ複雑な条件式をそれぞれ分割して書いたり、関数の引数に含まれる長い計算式を一度変数に格納したりすることで、コードが格段に読みやすくなります。

冗長なコードを書かないよう意識していると、なるべく短く書こうと可読性を無視してしまいがちです。 必要ならば変数を増やす、式を分割するというテクニックを覚えておくことで、より「良いコード」が書けるようになると思います。

おわりに

リーダブルコードを読んだからといってすぐに可読性の高いコードが書けるようになるというわけではありませんが、念頭に置いておくことで今までよりも可読性を意識しながらコードを書けるようになると思っています。

また、内容を忘れてしまったり、コードを書いていく上で自然と身についてしまうような「よくないクセ」を矯正する意味でも、定期的にリーダブルコードを読むようにします。

インプットを増やすためにも、今後も色々な本を読んでいきたいです。

vivitエンジニアのGit, GitHub周りの環境を調査してみた

新卒エンジニアの氏家です。 私が現在所属しているrentalチーム(キャンプ用品レンタルサービスhinataレンタルの開発を行うチーム)では、Gitの運用にRebase運用(逆Merge運用)が採用されています。

Rebase運用とは、作業ブランチをmasterにマージする前にrebaseを行い、最新のmasterから作業ブランチが伸びている状態にすることで未然に問題を発見できたり、ブランチが複雑に入り組まずブランチの確認がしやすくなるため、チーム開発で良く取り入れられる運用方法の1つです。

調査のきっかけ

私はrentalチームにきて初めてこの運用方法を知り、こまめにrebaseするように教わりましたが、Git CLIで慣れないrebase作業を行うのはとても大変でした。 そんなとき、同じチームの先輩にGitのGUIツールを教えていただき、このrebase作業がとても簡単に行えるようになりました。 どうやら僕の知らないGit周りの便利なツールが他にもたくさんあるようです。 これからGit運用の効率を上げていくためにも、他にどのようなものがあるのか知りたいと思いました。

そこでvivitのエンジニアの方々に、Git, GitHub周りで使用しているツールやサービス、エディタの拡張機能でどのようなものを使っているか調査してみました。

調査

調査内容は「Git,GitHub周りのツールやサービス、拡張機能を使用しているかどうか」です。 使用している場合は何を使用しているか、Git CLIのみの方はなぜ他のツールを使用しないかお聞きしました。

f:id:rugk:20210604192615p:plain
Git, GitHub周りの環境調査

vivitのエンジニア10名にご回答いただいたところ、8名の方が「使用している」を選択されました。 では、どのようなツールが使用されているのか見ていきましょう。

Gitクライアントツール

Fork

回答が1番多かったのがこのGitクライアントツールのForkです。GUI操作でGitの管理ができます。 git-fork.com

私がrebaseで苦戦しているときに教えていただいたツールもこちらになります。作業ブランチにチェックアウトし、master → rebaseを選択するだけで簡単にrebaseすることができました。

コミットツリーやファイル差分などが見やすく、Git運用を快適にするためのGUIツールといえます。 お試しで利用する分には無料ですが、長期利用は有料でライセンス購入が必要です。

用途・理由
  • 差分を把握し、部分コミットできます。日本語に対応していないですが、シンプルなUIで使いやすいです。 (marietty)

Sourcetree

GitクライアントツールといえばSourcetreeも有名です。こちらもGUI操作で簡単にGitの管理を行うことができます。 www.sourcetreeapp.com

用途・理由
  • ブランチ作成・切り替え、リベース、プル、他人のブランチ差分を見る時に使用。視覚的に分かりやすい (YT)

GitHub Desktop

GitHubが提供しているGitクライアントツールのGitHub Desktopは、GitHubを運用するためのデスクトップアプリケーションです。 初めてチーム開発でGitHubを運用するという方でも、GUI操作で簡単に操作することができます。 バージョンアップを重ねるごとに使いやすさが増しているようなので、これを機に私も導入を検討しています。 desktop.github.com

用途・理由
  • 一般的なGitの操作。コマンド覚えるのが面倒なので。(murayama)

CLIクライアント、拡張機能

tig

tigはCUIリポジトリブラウザです。 様々なビューのモードがあり、コミットログやマージコミットの差分などを分かりやすく表示させることができます。 ローカルでのGit操作はtigで行うことができるので、慣れればGit CLIより直感的に操作することができそうです。 github.com

用途・理由
  • ローカルでの操作で使用。e.g. add,commit,checkout (関)

git-completion/git-prompt

ターミナルのプロンプトに常にブランチ名を表示させることができるgit-completionと、gitコマンドをtab補完できるようにするgit-promptは、Git CLIでGit操作する方には特に重宝するスクリプトのようです。 github.com

用途・理由
  • GitPrompt → fastlaneやbundlerなど、ターミナルで作業する時に自分がどこのブランチにいるかが一目で分かるようになって良い(YT)
  • GitCompletion → なんだかんだCLIでGit操作する時が多い。そういう時にとっても便利(YT)

テキストエディタ拡張機能

GitLens

ファイルの変更差分を分かりやすく表示してくれたり、コミットログを行単位で確認することができるVSCode拡張機能です。 テキストエディタVSCodeを使用されている方の多くはGitLensを追加していました。 gitlens.amod.io

用途・理由
  • コミットログや変更差分を確認するのに使っています(氏家)
  • エディタ上でファイル差分を表示(関)

GitHub Pull Requests and Issues

GitHubが提供するVSCode拡張機能です。リポジトリのPRをエディタ上で確認でき、PRの変更差分をVSCodeのDiffで表示してくれるのでコードレビューのときに重宝します。

marketplace.visualstudio.com

fugitive.vim

vimでGitの操作が行えるプラグインのfugitive.vimを利用しているエンジニアの方もいました。 vimから抜けること無くGitを操作できるので、Vimmerにとっては魅力的なプラグインのようです。(私には分かりません)

github.com

その他

ほかにもGitHub CLIやGoLandのコンフリクト解消機能、各エディタのSource Controlを利用している方もいました。 用途にあったツールを適切に使い分けてGit運用できれば、今よりも格段に作業効率が上がる予感がします。

Git CLIのみ

一方で、Gitの運用はGit CLIだけで事足りているという方もいました。 開発全般をコマンド操作で済ませたい場合や、Git CLIでの運用に慣れている場合は、わざわざ他のツールを導入する必要はないようです。

他のツールを使用しない理由

CIなど、gitコマンド使いたくなる場面があるので、Git CLI は最低限知っておきたい。あと、他のツールの使い方を覚える気がない笑(井島)

CLIに慣れていて(名嘉眞)

終わりに

今回はvivitエンジニアのGit, GitHub周りの環境について紹介しましたが、いかがだったでしょうか。

これからチーム開発でGit運用を始める方や今よりも作業効率を上げたいという方の参考になれば幸いです。

新卒エンジニアがチーム開発で気を付けていること

今年の4月から新卒エンジニアとしてvivit株式会社で働いている氏家です。 5月に入り、インターンでもお世話になっていたmediaチーム(主にWebメディアhinataの開発を行うチーム)から、キャンプ用品のレンタルサービスを提供するhinataレンタルの開発を行うrentalチームに移動しました。

チームが変わり、開発環境や使用言語もガラリと変わりましたが、業務をする上で気を付けていきたいことは共通していました。 今回は新卒エンジニアの私が慣れないチーム開発をしていくなかで、慣れてないからこそ気を付けていることをいくつか紹介していきたいと思います。

考えたうえで聞く

私はよく、分からないことがあっても人に聞かずにずっと考えてしまいます。 人に聞いてしまうと、自分で考えたり調べたりするスキルが身に付かず、一人で考えなければならないような状況になったときに困ってしまうと考えているからです。

特に「考えれば分かるもの」に関しては分かるまで考え続け、多くの時間を消費してしまいます。 しかし、そのせいでタスクの期限を過ぎてしまったり、他の実装に遅れが出てチームに迷惑をかけてしまっては元も子もありません。 逆に何でもすぐに聞いていては考えたり調べたりするスキルが培われないので、どこまで考えて、どこから聞くのかの線引をする必要があります。

私は30分考えて分からなかったら聞く、今書いているコードが動かなかったら聞く、などの自分ルールを設けて、ある程度自分でやったうえで分からなかったらすぐ聞くようにしています。

事実と意見を分ける

チーム開発でのコミュニケーションはとても重要なものだと実感しています。 特に報告、連絡、相談の際には事実と意見を分けて伝えることを心がけています。

話し手が伝えたい内容と、聞き手が受け取る内容に相違が無いよう、事実を伝えるときは事実のみを述べ、そこに自分が思ったことや感じたことを含めないようにします。 事実と意見が混同してしまうと聞き手に誤った解釈をさせてしまい、業務に支障が出てしまいます。

これはvivitに入社して最初に行われたエンジニア研修でも話されていた内容で、早い段階から意識することができました。 もし意識せずチーム開発に取り組んでいたら、状況の説明に時間がかかってしまったり、意図をうまく伝えることができず相手に迷惑をかけてしまっていたでしょう。

情報共有をする

少なくとも同じチームの方々には、自分が何の作業をしていて、何に困っているのかなどを共有する必要があります。 特に私のような新卒で入ったばかりのエンジニアは、どの程度のことが分かっていて、何が分からないのか共有しなければ先輩方はどうサポートすれば良いのか分からないはずです。

黙々と作業しているのか、分からずに躓いているのか、別の作業をしているのかも、共有しなければ分かりません。

vivitではSlackに個人の分報*チャンネルがあるので、これから何をするか、今何をやっているか、何で悩んでいるのかなどをなるべく共有しています。 vivitのエンジニアは困っていたらすぐサポートしてくれるので、ちょっとした疑問なども分報チャンネルに書き込むようにしています。

*分報については以下の記事で説明されています。

craftsman-software.com

既存のコードを正としない

例えば機能追加のタスクを振られ、実装方法が分からなかったときは、他の同じような機能や動作をする箇所のコードを参考にすることがあります。 おそらくそのコードを書いたのはエンジニア歴の長い、自分よりも技術力がある方なので、そのコードに習って実装すれば間違いないと考え、そのコードを正として実装を進めます。

しかし、実際にそのコードが正しいコードとは限りません。 「正しいコード」がどういうものなのかという定義は難しいですが、仕様通りで、保守性があり、無駄がない、可読性の高いコードであるかどうかは担保されていません。 もしかするとまだ発見されていない未知のバグを含んでいるかもしれません。 「実装方法」という問題に対しての「答え」としてただ真似るのではなく、あくまで例の一つとして参考にしながら実装方法を考えることが大切だと思います。

もちろん既存のコード通りに実装した方が良いケースもありますが、既存のコードを疑う癖を身に付ければ、より良い実装方法を選択することができると考えています。

おわりに

チーム開発するうえで気を付けなければいけないことは他にもたくさんありますが、今回は私個人が気を付けていることについて紹介しました。

今は会社の各プロダクトについて理解を深めたり、今後のキャリアプランについて考えるために、1ヶ月ごとに開発チームを移って業務させていただいていますが、 同じチームに長くいると環境に慣れてしまい、今まで気を付けていたことができなくなったりしてしまうと思うので、自分は何に気を付けてチーム開発に取り組むべきか、どうすればチーム開発が上手くいくか考える癖を身に付けていきたいです。

おまけ

Slackの分報チャンネルではちょっとした疑問や気付きを共有していますが、エンジニアの方々がすぐにサポートしてくれます。

f:id:rugk:20210521160021p:plain
サポートしてくださるエンジニアの方々

テスト初心者がRSpecで必要十分なテストを書く

今年の4月から新卒エンジニアとしてvivit株式会社で働いている氏家です。 私は現在、主にアウトドアWebメディアhinataの開発を行うmediaチームに所属しており、Railsを中心にコードを書いております。

最近、ある機能の実装のためコントローラにメソッドを追加しそのテストをRSpecで書いていたのですが、テスト(この場合は単体テスト)についての知識が乏しく、どのように書けばいいか分からず苦戦しました。 しかしこのタスクに着手しているとき、ちょうどソフトウェアテストをテーマにエンジニア研修が実施されており、自分の書いたテストのどこが不適切なのかを知ることができました。

今回は僕のようなテスト初心者がどのようなマインドでテストを書いていたのかと、必要十分なテストを書くために学んだことを話していけたらと思います。

メソッドの仕様

コントローラに追加するメソッドは「データベースのcategoriesテーブルから値を取得し、変数に格納する」という単純なものです。 このメソッドはあらゆる場面で使用されるため、ApplicationControllerに記述しています。

# frozen_string_literal: true

class ApplicationController < ActionController::Base

~~~

before_action :set_categories

~~~

def set_categories
  @categories = Category.where.not(priority: 0).order(priority: :desc).limit(6)
end

取得する条件は「priorityカラムが0ではないレコードをpriorityの降順に6つまで取得すること」です。

必要十分なテストとは

テストはただ書けばいいというものではなく、テストケースが メソッドが仕様通りの動作をするかどうか(正常時、異常時の双方) を網羅している必要があります。 さらに、1つの動作を確認するのに同じようなテストケースが複数あったり回りくどい書き方をしていても意味がなく、テストの実行時間が遅くなる原因になってしまいます。

メソッドが取りうる動作を、最低限のテストケースで網羅することが必要十分なテストといえます。

最初に書いたテスト

まず僕がテストについて理解せず書いたset_categoriesメソッドのテストがこちらです。

# frozen_string_literal: true

require 'rails_helper'

RSpec.describe ApplicationController, type: :controller do

~~~

  describe '#set_categories' do
    let!(:category1) { FactoryBot.create(:category, name: 'カテゴリ1', priority: 6) }
    let!(:category2) { FactoryBot.create(:category, name: 'カテゴリ2', priority: 5) }
    let!(:category3) { FactoryBot.create(:category, name: 'カテゴリ3', priority: 4) }
    let!(:category4) { FactoryBot.create(:category, name: 'カテゴリ4', priority: 3) }
    let!(:category5) { FactoryBot.create(:category, name: 'カテゴリ5', priority: 2) }
    let!(:category6) { FactoryBot.create(:category, name: 'カテゴリ6', priority: 1) }
    subject { controller.send(:set_categories) }

    context 'カテゴリが6つ以下の場合' do
      it 'priorityの順にすべて取得する' do
        is_expected.to match([category6, category5, category4, category3, category2, category1])
      end
    end

    context 'カテゴリが7つ以上場の場合' do
      let!(:category1) { FactoryBot.create(:category, name: 'カテゴリ1', priority: 8) }
      let!(:category7) { FactoryBot.create(:category, name: 'カテゴリ7', priority: 7) }
      it 'priorityの順で6つだけ取得する' do
        is_expected.to match([category6, category5, category4, category3, category2, category7])
      end
    end
  end
end

僕が必要だと感じたテストケースは、降順に取得できるかどうか7つ以上取得していないかどうかの2つでした。

コードを順番に見ていきます。

前提

まずFactoryBot.createでカテゴリを6つ作成します。テストケース毎に作成させたかったためlet!としています。

テストケース1

1つ目のテストケースではカテゴリがpriorityの降順で取得されているか確認したかったので、matchマッチャで順番通りに格納されているか確認します。

テストケース2

2つ目のテストケースではメソッドの.limit(6)が正常に動作しているか確認するため、追加でcategory7を作成しました。その際、category1priorityの値を変えて新しく作成することで、降順で取得されているかどうかを確実なものにしようと考えました。

エンジニア研修で学んだ内容と先輩エンジニアのフィードバックから、このテストはテストケースが不十分であり、かつ書き方にもいくつか問題があることがわかりました。 特にlet!で余計なデータを作ることは、テストの実行速度が遅くなる原因になるうえに、テストケース前に全て実行されてしまうのであまり使うべきではないことを学びました。

必要十分なテスト

まず必要十分なテストケースを考えるために、改めてメソッドの仕様を確認してみます。

def set_categories
  @categories = Category.where.not(priority: 0).order(priority: :desc).limit(6)
end

このメソッドはcategoriesテーブルからpriorityが0ではないレコードをpriorityの降順に6つまで取得し、@categoriesに格納します。つまり以下のような仕様になります。

  • priorityが0ではないレコードを取得すること
  • priorityの降順で取得すること
  • 最大6つまで取得すること
  • @categoriesに格納されること

それぞれのテストケースを作成することを考えると、例えば「priorityの降順に取得すること」をテストするのにテスト用のカテゴリが6つもいらなかったり、「priorityが0ではないレコードを取得すること」をテストするテストケースが不足していることが分かります。

以上の点を踏まえ、必要十分なテストを目指し修正したset_categoriesメソッドのテストは以下のようになりました。

# frozen_string_literal: true

require 'rails_helper'

RSpec.describe ApplicationController, type: :controller do

~~~

  describe '#set_categories' do
    subject { controller.send(:set_categories) }

    context do
      before do
        FactoryBot.create(:category, priority: 1)
        FactoryBot.create(:category, priority: 2)
        FactoryBot.create(:category, priority: 0)
      end

      it 'priorityが0でないカテゴリをpriorityの降順ですべて取得する' do
        res = subject
        expect(res.size).to eq 2
        expect(res.first.priority).to eq 2
        expect(res.last.priority).to eq 1
      end

      before { subject }

      it '@categoriesに格納される' do
        expect(assigns(:categories)).not_to be_nil
      end
    end

    context 'カテゴリが7つ以上ある場合' do
      before do
        FactoryBot.create(:category, priority: 1)
        FactoryBot.create(:category, priority: 2)
        FactoryBot.create(:category, priority: 3)
        FactoryBot.create(:category, priority: 4)
        FactoryBot.create(:category, priority: 5)
        FactoryBot.create(:category, priority: 6)
        FactoryBot.create(:category, priority: 7)
      end

      it 'priorityの降順で6つ取得する' do
        res = subject
        expect(res.size).to eq 6
        expect(res.first.priority).to eq 7
        expect(res.last.priority).to eq 2
      end
    end

    context '該当するカテゴリが無い場合' do
      before do
        FactoryBot.create(:category, priority: 0)
        subject
      end

      it '@categoriesに空の配列が格納される' do
        expect(assigns(:categories)).to eq []
      end
    end
  end
end

順番に見ていきます。

テストケース1

まず1つ目のテストケースでは、以下の仕様をテストしています。

  • priorityが0ではないレコードを取得すること
  • priorityの降順で取得すること
  • @categoriesに格納されること

1つ目の仕様のテストのためにpriorityが0のカテゴリが1つと、priorityの値が違うカテゴリを2つ作成しています。先ほどのテストと違い、let!インスタンス変数を定義しておらず、テストするのに最低限のレコードしか作成していません。

テストの内容も、わざわざマッチャを使用して順番まで完全に一致しているか見る必要がなく、priority: 1priority: 2として作られたカテゴリを取得した際に、最初のカテゴリのpriorityが2、最後のカテゴリのpriorityが1であれば降順で取得できていることが分かります。 配列の大きさを確認することで、priorityが0のカテゴリは含まれていないことも確認できます。

テストケース2

2つ目のテストケースでは以下の仕様をテストしています。

  • 最大6つまで取得すること
  • priorityの降順で取得すること

6つまでしか取得しないことをテストするのにカテゴリを7つ作成する必要がありますが、先ほど同様にインスタンス変数を定義する必要はありません。 配列の大きさと最初と最後のpriorityの値を見て、降順で6つ取得されているかをテストします。

テストケース3

3つ目のテストケースは、「何も取得できなかった場合(異常時)」をテストしています。

priorityの値が0のカテゴリを1つだけ作成し、set_categoriesが実行されたとき、@categoriesには空の配列が格納されることを確認します。

まとめ

これからはテストを書く際、以下のような部分に気を付けていきたいと思いました。

  • 異常時のことも考える
  • 不要なコードを書かない(テストが遅くなる)
  • そもそも機能の実装時に仕様を正しく理解しておく

特に不要なコードを書かないようにするためには、それが不要かどうか知らなくてはいけないし、考えれなくてはいけません。 テストを書く回数を重ね、何が最適であるかを模索するのも必要十分なテストを書くうえで必要です。

おわりに

メソッドの仕様や異常時の振る舞いを最低限の処理、テストケースで確認することができたと思っていますが、まだテストケースが不十分だったり余計な処理が含まれているかもしれません。 今までテストを作成するという文化を知らずに生きてきたのでまだ苦手意識がありますが、テストを作成する際は必要十分なテストになるよう心がけていきたいです。

新卒でベンチャーに入社した話

技術開発部の氏家です。 私は今年の4月に新卒でvivit株式会社に入社し、現在エンジニアとして働いています。 今回は私がvivitへの入社を決めた理由や入社前のインターンでしたこと、入社前と入社後のギャップについて話していけたらと思います。

vivitへの入社を決めた理由

vivitと出会ったのは私がエンジニアの就活イベントに参加したときでした。 マッチングした企業と就活生が1on1形式の面談をしてすり合わせするというもので、事前プレゼンで社風や事業に興味を持ちvivitとの面談を希望しました。

無事vivitとの面談が叶い、話していくうちに今何をやっていてこれから何をやろうとしているのか、もし自分が入社したらどのような業務をするのか知り、エンジニアとして成長していくのに理想的な環境だと感じました。 たくさんの企業を見て回り、将来のビジョンを考えたときにvivitが1番合っていると考え入社を決めました。

余談ですが、私が就活していたときの企業選びの軸は1つで、事業を好きになれそうかどうかだけでした。 携わる業務にやりがいや面白さを見出せれば、その業務を好きになり、もっと頑張ろうと思えるはずです。 「好きこそものの上手なれ」という言葉の通り、本当に好きなものは自然と上達していくと考えています。

入社前の長期インターン

大学4年生の夏季休暇中、約1ヶ月ほどvivitにインターンとしてお邪魔していました。 内容はざっくり言うと、実際の業務をやりながら学ぶというもので、MAUが350万を超えるアウトドアwebメディアのhinataというサービスの業務に携わることになりました。

hinataのメインはRuby on Railsで作られており、RailsどころかRubyすら触ったことが無かった私は初歩的なところで躓いていましたが、調べたりエンジニアの方々に教わりながら業務をこなしていました。 自分の好きなことを業務として取り組めること困ったときすぐにサポートしてくれる職場の環境に感謝しながらインターンに取り組み、4月から働けることを楽しみにしていました。

入社前と入社後のギャップ

エンジニアとして仕事ができるという期待で胸を膨らませていましたが、新卒1年目の自分がすぐに業務でコードをかけるとは考えていませんでした。 最初は研修を受けたり、初歩的な業務を任されると思っていたからです。 企業によっては3ヶ月~半年かけて研修を行うところもあり、インターンのときとは立場が違うことも理解していたのでしばらくは辛抱だと自分に言い聞かせていました。

しかし、4月1日の入社式で自分がインターンのときと同じmediaチーム(主にhinataの業務)への配属が決まった次の日にタスクが振られ、コードを書くことになりました。

ああ、ベンチャーって本当に良いなって思いました。

ちなみに研修自体は長期間を確保して実施されているわけではないですが普通にあります。 外部のビジネス研修を受けさせていただいたり、毎週エンジニア研修と称してチーム開発のノウハウや昨今の技術的な話をしていただいています。 今年の新卒エンジニアは僕1人だけなのですが、多くの時間とコストを割いて実施してくださっているので、それに見合うだけのインプットをし、これからの業務に活かしていきたいです。

おわりに

まだ入社したばかりで基本的な仕事もこなせていない私ですが、業務を通して少しずつ成長を感じています。 頼られるエンジニアになれるよう日々精進していきたいと思います。

突撃!隣のキーボード 2021

はじめに

フロントエンドエンジニアの関(@kur0buchi)です。

新型コロナウイルス感染症(COVID-19)により世の中の様々なコトモノが変わっていった2020年も明けたものの、未だ家にいる方が長い日を過ごす方も多いのではないかと思います。在宅での仕事を快適にしようとデスク周りの整備に務める方も多いのではないでしょうか。

今回はパソコン仕事には欠かせない「キーボード」にフォーカスして弊社の技術開発部にアンケートを取りました!
長引くテレワークで気分転換が欲しいという方も、一番多く触れるであろうキーボードにちょっとこだわってみてはいかがでしょうか。

本記事は同名タイトルで様々な企業様が書かれている記事に便乗したものとなっております。以下にその一部を紹介しますので、興味が湧いたという方は以下の記事もご覧になってください。

www.m3tech.blog

tech.fusic.co.jp

blog.yushakobo.jp

メンバーのキーボード

村山

f:id:KeytacK:20210210143105j:plain

ひとこと

キーボードの打鍵が気持ち悪くなければあと何でも大丈夫です!

筆者コメント

我らが技術開発部マネージャー、村山のキーボードは「孤高の遺伝子を受け継ぐ真の最高峰」でおなじみ Happy Hacking Keyboard (通称 HHKB) です!
実は弊社開発部は HHKB ユーザが結構多く、一時期並んだ机が一列 HHKB といった状況があったりしました。
「打鍵が気持ち悪くなければあと何でも」と言って HHKB を選ぶあたりなんとなくこだわりも感じますね!(?)

ijima

f:id:KeytacK:20210210191655j:plain

ひとこと

静電容量無接点方式を試したかったのと、テンキーがほしかった

筆者コメント

こちらはエンジニアのみならず弁護士や小説家など、幅広い分野で人気(公式サイトより)の静電容量無接点方式キーボード、東プレ REALFORCE for Mac です!
待望の Mac 向けキーボードとして話題になったキーボードですね、テンキーレスモデルも人気ですが、インフラエンジニアとしてパラメータ操作等数字を扱うことが多いとフルサイズも欲しくなりますね!

shimar

f:id:KeytacK:20210210143927p:plain

ひとこと

カラーキートップを着けて使っています

筆者コメント

こちらは HHKB にオプションのキートップを着けてますね!
HHKB はメカニカルキーボードと違ってキーキャップが特殊でアレンジがしにくいイメージがありますが、公式でカラーキートップを出していたりするので結構遊べますね!

小石

f:id:KeytacK:20210210144140j:plain

ひとこと

中古のHHKBです。会社とキーボード揃えたかったので買いました。満足してます。
写真のキッチンタイマーはポモドーロタイマーとして活用してます。

筆者コメント

リモートワークに合わせて HHKB を買い足すという人も……!
一般的なキーボードと比べるとキー数も少なく Professional モデルになると方向キーまでなくなってしまったりと「使いづらそう」というイメージがあったりもしますが、慣れてしまうとコードを書くのに凄く合理的な作りだったりもするので手放せなくなるキーボードですね!

@taroodr

f:id:KeytacK:20210210144242j:plain

ひとこと

つい一週間ほど前に購入しました。
手首が痛むので体への負担がなるべく少ないものを選んで使っています。

筆者コメント

キーボードは静電容量タイプだけではありません! Mistel BAROCCO はメカニカルスイッチ(写真は CHERRY MX 静音赤軸モデル)採用の分割キーボードです!
巷では「肩が開いて人間工学的に良い」なんて言われたりする分割キーボードですが、実際自分の思う自然な姿勢でタイプができるためかなりオススメです。

これがやりたかっただけだろのコーナーです

f:id:KeytacK:20210210144700j:plain

Lily58 + Domikey SA Dolch Orange + DUROCK T1
いわゆる「自作キーボード」と呼ばれる、キットを購入して自分で組み立てるタイプのキーボードを使っています。
私が使っているのは Lily58 という分割式のキーボードで、会社用と自宅用で2台作るほど愛用しています。
少ないキー数と特徴的な配列で限りなく最小限の手の動きで全てのキーをタイプできるよう設計されているので、慣れたときの快適さは言葉では言い表せられません。
細かく紹介していくとキリがないのでいずれ機会があれば。

f:id:KeytacK:20210210144825j:plain

FILCO Majestouch 2SS TKL
今回のアンケートでは静電容量無接点方式のキーボードが多かったので、どうしても紹介したいメカニカルキーボードをもう一つ紹介します。
王道一直線のメカニカルキーボードといえばこの Majestouch シリーズかと思います。軸も多種多様でサイズもフルから60%まで用意されているので、買ったことないけど外付けキーボードが気になるという方にお勧めしやすいシリーズです。
(写真は2021年1月に発売されたばかりのスピード銀軸モデル)

他にも……

実は以前にもアンケートを実施し、筆者都合で記事化には至らなかったキーボードの写真をご紹介します!
ご協力頂いた方にはこの場をお借りしてお詫びと感謝を申し上げます
m(_ _)m

f:id:KeytacK:20210210145042j:plain

f:id:KeytacK:20210210145118j:plain

f:id:KeytacK:20210210145204j:plain

f:id:KeytacK:20210210145245j:plain

おわりに

今回紹介したキーボードは高額なキーボードばかりでしたが、もっと安価で使い勝手のいい高コスパなキーボードもたくさんあります!
在宅ワークが捗らないなぁと感じる方も是非外付けキーボードをご検討してみてはいかがでしょうか?

求人

vivitではコダワリ派のあなたの応募もお待ちしております

www.wantedly.com