はじめに
こんにちは。kouです。
昨年8月1日、株式会社NoSchool に入社し、オンライン家庭教師サービス『マナリンク』の開発に本格的に携わり始めてちょうど1年が経過しました。
この1年間、マナリンクの開発に携わる中で様々な学びがありました。
今回、入社1年という区切りにこの1年間の学びを、簡単にですが並べてみようと思います。
この1年間で学んだことは多くありますが、それらを全て挙げるのはキリがない上に、記事としても読みにくいものになってしまうため、中でも学びが大きかった部分に絞って紹介します（今回は主に設計とテスト周りについて取り上げています）。
自己紹介
本題に入る前に軽めの自己紹介をしておきます。
kouという名前で活動しています。
2021年の7月からエンジニアとして働き始め、現在でエンジニア歴2年程度です。
昨年8月、NoSchool入社時点での設計・テスト周りに関するレベルは以下のような状況でした。
- テストコードについては、存在は認知していたが具体的なテストコードの書き方や、なぜテストコードを書いたほうが良いのかといったことはまるで理解していなかった。
- 設計についても、自分で一から考えるというよりは、既存の設計にそのまま乗る形で実装等をしていたため、自分で設計をしっかり考えたことはあまりなく、どういう設計がより良い設計であるのかなどについて全く知見がなかった。
開発担当領域
現在の自分の業務での開発担当領域は以下の通りです。
主にはWebフロントエンドとバックエンドを横断して開発しています（アプリはまだまだ少なめ）。
- Webフロントエンド開発（Nuxt.js / Next.js）
- バックエンド開発（Laravel）
- アプリ開発（React Native）
目次
- 学び①：テストコードを書く習慣がついた
- 学び②：設計周りに意識を向けられるようになってきた（保守性や拡張性の考慮など）
- 学び③：複数選択肢を挙げた上でその中での優劣を判断できるようになってきた
学び
さて、本題です。
この1年、自分の中で大きな学びとなっていることを3つ挙げました。
学び①：テストコードを書く習慣がついた
テストコードは、マナリンク開発を通した学んだことの中でもとても学びの大きい部分でした。
そもそも、これまで自分はあまりテストコードというものを本格的に書くという習慣がなく、テストコードというものにちゃんと向き合ったのはマナリンクの開発を通してが初めてでした。
昨年8月に参画したばかりの頃は、既存のテストコードを参考にしつつ、ほとんど見様見真似のような形でテストコードの実装を進めていくのが精一杯でした。この頃は「モック」という言葉の意味すらもよく分かっていない程度には何も分かっていなかったような気がします。
マナリンクのバックエンド開発では、テストコードは基本的に必須で書く方針になっており[1]、テストコードの書き方は業務をこなす中で自然と書けるようになっていきました。
テストコードを書く回数を少しずつ重ねていく中で、「どのようにテストコードを書くのか」というHOWの部分以上に、「なぜテストコードを書くのか」というWHYの部分を考え学ぶことができたことは、個人的に大きなポイントでした。
その後も、自分の書いたコードに対して、「テストコードが書きやすい/書きにくい」といったことを感じる経験などを通して、「テストコードが書きやすい = 良い設計の兆候」「テストコードが書きにくい = あまり良くない設計の兆候」 というようなことを身を持って実感したり、テストコードがあることによってリファクタリングする際の安心感が明らかに違うことを実感したりと、テストコードを書くようになってから見えてきたことは数知れません。
今では、以下のWantedly記事にもある通りですが、少し前に開発した機能では、提出したPull Requestのコード全体のうち約半分がテストコードになっている程度には、テストコードを念頭に置いて日々実装に励んでいます。笑
[上記記事より抜粋]
テストコードをたくさん書きましたね。「誰が」「誰と誰の部屋を」閉じるかによってケースが複数ケースあったため、実際に動かして動作確認をするよりもテストコードをしっかり書くことでこのあたりの実装の正しさを担保するようにしていました。コード量だけで見ると、Pull Requestの書いたコードのうち約半分程度がテストコードのコードでした(笑)。
余談ですが、「テストの書きやすい設計」というものを学んだ一番最初のきっかけは、弊社CTO作成のTechpit教材でした（とても良い教材なので隙あらば宣伝）。👀
学び②：設計周りに意識を向けられるようになってきた（保守性や拡張性の考慮など）
設計というものを明確に意識し始めるようになったのも、マナリンクの開発業務についてからでした。
設計というと幅広いですが、ここでは「ドメインモデル設計」「DB設計」「クラス設計」「コンポーネント設計」などのような設計を主に指しています。
機能開発の要件が来た際、闇雲にテーブルやクラスなどを作成するのではなく、「仮にこういう要件が追加されたらどうだろう？」や「逆にこの要件がなくなるとしたらどうだろう？」など、今後改修されうることを事前に想定して実装に取り組むことができるようになってきました。
以下のWantedly記事は、自分が以前担当した機能の開発ストーリーです。
比較的分かりやすい部類ではあるものの、クラスの拡張性を意識して改修を行なったことが書かれています。
ただ、自分は割りと形から入りがちなところがあるため、「良いとされている型(=設計手法など)がなぜ良いとされているのか」というような、その本質を見定めて理解することがまだまだ不得意です。なので、今後も設計を考える際は、あまり表層だけに囚われず、「何のために設計を頑張るのか」などは考え続けるようにしたいと思っています。
学び③：複数選択肢を挙げた上でその中での優劣を判断できるようになってきた
学び②で挙げた「設計周りの話」に近い話ですが、何かの実現方法を模索する場合に、複数の選択肢を検討・比較できるようになってきたことも自分の中で大きな学びの一つでした。
何かの機能開発を要求された際、多くの場合その実現方法は一通りではなく、複数通りの解決策が存在するケースが多いかと思います。
これまで自分は、ある要求に対しての解決策を深く検討することができておらず、言ってしまえば一番始めに考えついたことが唯一の解決策であるかのように思い込んで突き進んでしまうことがありました。
マナリンクでの開発を通して、何かの要件を実現しようとする際、パッと思いついた手段に飛びつかず、一度冷静に他の方法でも実現できないかを検討する癖が少しずつついてきました。
勿論、まだまだ改善の余地はあるものの、最近ではChatGPTという強い味方も現れました。
ChatGPTの登場によって、より手軽に壁打ちの相談をするということが可能になりました。自分でまずは複数個の選択肢を挙げ、その中でそれぞれのメリット・デメリットを判断した上で自分の中で有力候補を選び、それを持ってChatGPTに壁打ちをお願いして、漏れている選択肢や漏れている観点等がないかをざっと確認してもらう、といったことを通してこの精度をより高めるように努めています（どうしてもChatGPTに対して長い文章を打つのは面倒臭いのですが笑）。
おわりに
ざっくりとでしたが、マナリンク開発を通しての学びを幾つか紹介しました。
今後も幅広く、様々な学びを深めたいと思います💪
この記事を見てもしご興味を持たれた方がいらっしゃいましたら、是非お気軽にお話できると嬉しいです！
-
ほぼ必須でテストコードを書くという習慣も相俟って、現在でもバックエンドのカバレッジは85%以上という高い数値になっています。 ↩︎
オンライン家庭教師マナリンクを運営するスタートアップNoSchoolのテックブログです。 manalink.jp/ 創業以来年次200％前後で売上成長しつつ、技術面・組織面での課題に日々向き合っています。 カジュアル面談はこちら！ forms.gle/fGAk3vDqKv4Dg2MN7
Discussion