Rails開発経験8年選手がC#.NETの開発をキャッチアップするまでの流れ

WEMEX株式会社 Advent Calendar 2023の6日目です。本記事では、バックエンド開発ではRailsを主戦場に経験を積んできた筆者がC#.NET開発をキャッチアップするまでの流れについてまとめてみました。

はじめに

私は、もともと新規で立ち上げたビジネスのプロダクト開発に従事するためにRailsエンジニアとしてWEMEXに入社しましたが、数ヶ月前より、C#.NETのプロジェクトに携わっています。従来から開発していたRailsのプロジェクトの開発も並行してはいますが、プロジェクトの進捗具合により、今はC#.NETのプロジェクトに割く時間が多いという状況です。

これまでももともと担当していたプロジェクト以外の開発を臨時的に、または主担当として担当をすることはあったので、プロジェクトが変わること自体は珍しいことではありません。しかし、今回がちょっと変わったのは、使用する技術がRailsではなくC#.NETだということです。ただし、フロントエンドとバックエンドは分かれており、WebのAPIをC#.NETで開発するという、最近では一般的な構成です。Webに関してはRailsで随分と経験を積んできたものの、C#.NETでの開発経験はまったくありません。早急にキャッチアップする必要に迫られ、1ヶ月程度かかってようやく、不具合報告があれば修正箇所を特定したり、一つのエンドポイントを開発できるようになりました。

自身の開発歴のおさらい

まず簡単に私自身の開発歴を紹介したいと思います。
私は、新卒でSIerに入り、入社直後の研修ではバックエンドの言語としてJavaの勉強をしました。したがってJavaの基本的な文法に関しては把握はしていました。しかし、８年以上Javaでの開発をしていませんでしたし、SIerにいたときは研修を除けばSEとしてパートナー企業の進捗管理の仕事がメインであったため、ほとんど仕事でプログラミングをするということはしておらず、Javaは素人と言っていいレベルです。とはいえ、JavaとC#の文法は非常に近しいところが多いですので、当時の記憶は役に立ったと思います。
その後早々にWeb系に転職してからはRailsがメインで、それ以外に仕事で経験のあるバックエンド開発はPython（WebフレームワークはFastAPI）ぐらいです（ほんの少しだけ）。ちなみにフロントエンドで経験が長いのはVue.js、そのほかにネイティブアプリではFlutterあたりが仕事で使ったことのあるフレームワークやライブラリになります。
プライベートでは、KotlinでAndroidアプリ開発を少しだけしたり、Reactの開発をしたこともありますが、あくまでプライベートレベルです。
以上をまとめると、Rails開発しかできない平凡なエンジニアと言えると思います。

C#の文法の勉強はしない

今回C#.NETをキャッチアップするにあたり、C#の文法の勉強はいっさい行わないようにしました。というのも、C#にしろRubyにしろオブジェクト指向言語であり、静的型付けか動的型付けかの違いはありますが、コードを読むことはできると思ったのと、実際既存のコードで何をやっているかは理解することはできたのであえて文法にフォーカスして学び直すということはしませんでした。実際に実装する時に記述が分からなければ調べれば何とかなるだろうと思っていました。
一方でフレームワーク特有のものについては理解する必要がありました。とはいってもフレームワークをどこから勉強するか分からなかったので、.NETの入門書を１冊買いました。

.NETの基本の把握

今回調べてみてWebにフォーカスをあてた.NETを浅く広く把握するための書籍はそこまで多くありません。特にWebアプリ開発にフォーカスをあて、データベースも含めて解説してある本を読みたいと思っていました。
最終的に手に取ったのが、この手の超入門本の類を多く執筆している掌田津耶乃氏のC#フレームワーク ASP.NET Core入門 .NET 7対応でした。この本は.NETの変遷から、Razer,　MVC,　Blazorのそれぞれの開発やEntity Framework (EF) Coreなど幅広く記載があります。書籍の内容としてはスキャッフォールディングされたコードの解説にプラスアルファを添えたものが多いのですが、.NET経験ゼロの浅く広く私にとっては非常に適した１冊でした。特にVisualStudioの使い方はWindows版とMac版、dotnetコマンドを使った場合の記述があり、会社の貸与PCがMacである私にとってはありがたいものでした。
プロジェクトのコードをみる前に買ったもので、実のプロジェクトでは、EFCoreよりも、Dapperが使われているケースが多かったり、開発環境に関してもMacでReSharperを利用するためにRiderを使っていたりと違いはあるものの、基本となるVisualStudioを一度触ったことがあるかどうかというところは、理解のしやすさに大きな違いがあったと思います。

開発環境構築

なにはともあれ、開発環境をローカルに構築でき、デバッグができるところまでいけば一つの峠を越した気持ちになります。C#の開発においてIDEはほぼ必須なので、IDEを正しく動かせれば問題ありません。ローカルの開発環境は、最近では、データベースをDockerで用意し、そこにWebアプリケーション側からアクセスするという形で環境構築することが多いです。Railsにおいても私の場合、アプリケーションを動かすのはMac上で行なっていました（Dockerを使うと遅くて開発効率が落ちた経験があるため）。その点、今回参画したプロジェクトでも同様にデータベースだけDockerで用意する形になっており、その構成はすぐに把握できました¹。
ただし、Mac用の起動プロファイルは設定されておらず²、launchSettings.jsonを修正（Mac用のプロファイルを追加）する必要がありましたが、大きなトラブルなくローカルで開発環境を構築できました³。

デバッグ

ローカルに開発環境が構築できたら、次はどのようにデバッグするかです。私の場合、Railsでのデバッグは主に２つの方法を用いていました。1つ目は、binding.irbを用いて、そこで止めて変数の値を確認する方法。2つ目は、Rails.logger.debugを用いてログに変数の値を出力して確認する方法です。Rubyの良いところは、オブジェクトをログに出力する際、いい感じで属性も含めて文字列にしてくれることです。C#で素朴にToString()をやってもオブジェクトのクラス名等はわかるものの、属性値まで把握することはできません。そこはこれまで行なっていたRailsとのデバッグ方法の違いだなと思いました。
C#.NETでのデバッグは主にIDEからブレークポイントを設定して、動かしてブレークポイントのところで止めることでその時点の変数の中身を見たり、コードを実行することで、デバッグを行います。
個人的にはデバッグ手法がわかれば開発はできると思っています。Rails開発においても経験を積む中でデバッグしやすい方法を模索してきました。C#.NETにおいても、すばやいデバッグができるように試行錯誤を進めていこうと思います。

DI（Dependensy Injection)

Railsと.NETにおいて、大きな違いがあるとすればその一つが、DI（Dependensy Injection）でしょう。.NETにおいては、Program.csにおいて、AddScopedやAddTransienを用いてDIを実現します。本記事では、DIについての詳細は省きますが、本家のASP.NET Core での依存関係の挿入やASP.NET CoreにおけるDI(Dependency Injection)など他記事や書籍が詳しいと思いますので紹介します。

C#風味のコードを書くために

最初に「C#の文法の勉強はしない」という旨の記載をしましたが、とはいうものの、C#のイディオムや、C#らしいコードというのは存在します。そこは、勉強する必要があると感じていました。C#はマイクロソフトが開発した言語ということもあり、広く使われ、歴史もあります。幸にしてそうしたC#のイディオムや定石をまとめてくれた「実戦で役立つ C#プログラミングのイディオム/定石&パターン」という書籍があり、こちらを購入しました。
実際に開発している間に、この本を読んでコードを改めたケースもあり非常に勉強になりました⁴。

最後に

以上が、Rails開発経験8年の私が、C#.NETの開発をキャッチアップするまでの流れについて記載しました。今回、プロジェクトにアサインされることが決まり、実際に自分の開発が軌道に乗るまでは、不安な部分も多くありましたが、WebのプロジェクトということはRailsと共通で、C#とrubyもオブジェクト志向言語という点も共通です。Web開発やオブジェクト志向という本質的なところを理解していれば、RailsエンジニアでもC#プロジェクトにスムーズに参画できるのではないでしょうか。また、JavaもC#と非常に近しい言語であるので、同様のことがいえるのではないかと思っています。
Rubyエンジニアの中にはRubyしかやってこなくて不安を持っている人がいるかもしれません。今回はC#.NETという状況でしたが、基礎をしっかりと学んでいれば、その時々に応じて必要とされる環境に適応できるのではないかと思いました。

1. フロントエンドエンジニアの方のためにWebアプリケーションもDockerで動くように準備はされていました。 ↩

2. これまでの開発はWindowsで行われていて、今回新たに参画したメンバーの何名かがMacで開発していました。 ↩

3. 強いて言えばIDEで起動プロファイルを指定する方法がわからなかったのですが、いろいろ触っていて把握できました。ネット情報の情報はWindows上でのVisualStudioの使い方が多く、検索性が若干悪いと思います。Windowsで開発するのが良いんだろうなとは思います。 ↩

4. 例えば初歩的な例ですが、stringに+=で文字列を追加するよりも、StringBuilderを利用した方が良いなど。 ↩