プログラミング２年目の2024年に勉強した技術・書籍の振り返り

こんにちは、学生エンジニアのMasamichiです。2025年もついに始まってしまいますね。今年もより一層プログラミングに励もうと思います。

さて、今回はプログラミング２年目の僕が大学に入学してから、プログラミング2年目となる2024年にした勉強の内容をざっくり振り返ります。


※去年書いた記事がそこそこバズったので、シリーズ化してみました

https://qiita.com/masamichi2004/items/f3a8a9c4ebaa0928d7ff

# TypeScript
この一年を通して最も勉強した言語です。プログラミング自体はPython入りで始めたので、初めての静的型付け言語でした（とは言いつつもコンパイル過程で型は無くなるのだが、）。他にも、厳密なコンストラクタの概念や、インターフェースとインプリメントの概念など、オブジェクト指向やソフトウェア一般における理論を一通り学習することができました。

また、JavaScript自体の仕組みを学習する場面も度々あり、アロー関数のthisの挙動や、Object.keys()の順序保持、ECMAScriptの仕様調査など、ディープなJavaScript自体の学習も行いました。

https://typescriptbook.jp/reference/functions/function-expression-vs-arrow-functions

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Object/keys

https://tc39.es/ecma262/

TypeScriptを勉強する上で、あまり書籍を使うような場面はなかったのですが（オンライン上のJS PrimerやサバイバルTypeScriptが優秀すぎる）、四方から集めたインプットをうまく体系化する確認用で、オライリーの「プログラミングTypeScript」にはすごく助けていただきました。

https://www.oreilly.co.jp//books/9784873119045/

## NestJS
https://nestjs.com/

サマーインターン先の企業で使っていたためキャッチアップしました。NestJSは**デフォルトでTypeScriptをサポートしており、三層アーキテクチャなのも魅力的**です。また、モジュール管理やDIを簡単に行えるデザインになっており、とても勉強になりました。個人的に好きなフレームワークなので、インターン期間中にかなりNestJSの仕様について研究しました。

NestJSはデコレータが豊富で、DIも@Injectable というデコレータをつけるだけで簡単に実装できます。これは、Reflectionという、クラスやクラスメンバにデコレータを追加したり、メタデータ管理を簡単に行える、強力なTypeScriptの仕様に基づいています。詳しく書くと、一本の記事が書けてしまうので省略します🙋

https://www.wolksoftware.com/blog/decorators-metadata-reflection-in-typescript-from-novice-to-expert-part-4

## Next.js App Router
https://nextjs.org/docs/app

2024年の最初の頃に、長期インターンで働いていた会社が採用していたのでキャッチアップしました。ディレクトリ構造から自動でルーティングを行う機能を搭載していたり、use serverとuse clientの適切な切り替え、APIルーティング機能の追加など、てんこ盛りです。元々Vue自体は触ったことがある程度だったので、これが実質的に初めての、ちゃんとしたフロントエンド開発体験でした。また、apiディレクトリ内でPrismaなどのORMを使用することで、フルスタックのような振る舞いもできるので、非常に面白かったです。

複数社でのNext.jsの経験を通して、ローディング管理やエラー管理、Suspense対応、フラグメント、クライアントキャッシュ、App Router×Prisma、垂直マイクロフロントエンドなど、さまざまな技術に触れることができました。（完全に理解できているわけじゃないので、これからも継続的に理解に励みたい）

https://vercel.com/blog/how-vercel-adopted-microfrontends

## Jest
https://typescriptbook.jp/tutorials/jest

まともなテストが書けるようになりました。これまでは、PRを後押しするなんちゃってテスト君だったので、大企業のインターンに参加して、まともなテスト駆動開発をする必要に迫られました。テストを重んじる開発では、**テストケースは言わば仕様書**だと考えるため、網羅性が完全で、構造的な単体テストを書く能力が求められました。このおかげで、この一年の中で一番エンジニアとして成長する機会になりました。

# LangChain
https://www.langchain.com/

ここ一年で**RAG**に対する世間の意識は一層強まったと思っています。自分は幸運なことにも、日本の中で先駆けてRAGを実践投入している企業で長期インターンをすることがきました。RAGを使用したアプリケーションを実際に開発し、その仕組みを学習することで、世の中で語られる生成AIなるものに対し、より一歩踏み込んだ概念の理解をすることができました。

>Cosense(旧Scrapbox)に、新歓に関する各情報を載せておくことで、LINE上で新歓に関する質問に、リアルタイムでお姫様っぽく回答してくれるBotを作成しました。詳細は[こちら](https://x.com/masamichi2004/status/1767418703585652824)
>![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3583931/9d000425-8edb-48c1-8f5f-b25f4512a63a.png)

まだ実際に買ってないものを載せるのはアレなんですが、めっちゃ気になってるので買おうと思ってますという宣伝。

https://gihyo.jp/book/2024/978-4-297-14530-9

# GraphQL
https://graphql.org/

この一年で一番長く勉強した技術Part2です。GraphQLはRESTとこなる新型のデータ通信クエリ言語で、得意テーマだったので、自身の所属するプログラミングサークルで、春に勉強会を開きました。

https://speakerdeck.com/masamichi2004/get-started-with-graphqlmian-qiang-hui-zi-liao

GraphQLの特性や、オーバーフェッチ問題、スキーマ駆動開発、エラーハンドリング、モデルリゾルバ、DataLoader、BFFアーキテクチャなど、特徴とProsConsをてんこ盛りにして紹介しています。これからGraphQLを始めたいというかたに向けて、10分程度で概要が雰囲気を掴めるようにデザインしました。ぜひご一読ください。

自分自身も、GraphQLについて、独学やLayerXのサマーインターンを通して、かなり多くの経験値をいただきました。

また、脳内の情報を補完したり、体系化するために、オライリーの「初めてのGraphQL」を熟読しました。

https://www.oreilly.co.jp/books/9784873118932/

# Google Cloud Platform
https://cloud.google.com/docs/overview?hl=ja

クラウド技術をちゃんと扱えるようになったことも、今年の功績だと思っています。初めてDevインターンをした会社が、ゴリゴリにGCPの会社だったので、AWSではなくGCPを使うようになりました。Cloud Run(Jobs)でETLのバッチアプリケーションを作成したり、BQ取り込みのデータパイプラインや、Dataformで複雑なBQ操作のクエリと単体テストを書いたり、など色々やりました。またCloud BuildとGithub Actionsを繋いで、CI/CDパイプラインを作成したりなど、さわったクラウドはほぼGCPだけですが、色々な試行錯誤を行いました。

https://cloud.google.com/dataform/docs/overview?hl=ja

余談ですが、最近のCodatumの進化が目覚ましいので、そろそろBigQuery Studioからcodatumに変えるのは面白そうだなと思ってます。コンフリクトしない複数人の同時編集ができるようになったらしいです（ヤバすぎ）。

https://codatum.jp/blog/engineering/yjs-deep-dive

# Terraform
https://www.terraform.io/

インフラを、GUIやコンソールで操作することなく、コードで表現し管理することができるIaC（**Infrastructure as Code**）という技術です。ゴリゴリにサーバーレースアーキテクチャを構築する、モダンなSaaS企業で働いて、初めて出会しました。この辺りはそこまで理解できているわけではないので、一通り動かせるようになりましたが、書き残すことは控えておきます（インフラ警察怖い）。

現時点での個人的な認識としては、**正確で再現性のある環境構築**がメリットなのかなと思ってます←。環境の同一性を担保するため、異常や差分を認識しやすいなと感じました。ただ自分がplanしてクソ差分が出たり、applyするのはまだちょっと怖いので、あんまりさりたくないなぁという印象です。

# ドメイン駆動設計（DDD）
サマーインターンで行った企業が、ドメイン駆動設計を行っていたためかなり手厚く学習しました。「ドメインの関心ごとと技術の関心ごとを分離する」や、「エンティティパターンでドメインモデル貧血を防ぐ」、「アプリケーションサービスとドメインサービスの分離」など具体的なデザインを教えてもらいました。

元々はクリーンアーキテクチャ最強！信者だったので、ある程度の責務の分離については理解していましたが、DDDを学習したことで、ドメインとインフラの分離の本質を知ることができました（クソ長くなりそうなので別記事にします）。独学する上では、オライリーの「**ドメイン駆動設計をはじめよう**」を読みこみました。業務→ドメインモデル→実装→進化（スケール・リアーキ）の流れで、具体的にDDDがどういう概念で設計されていくのかを、経典を優しくしたような方で解説されています（オライリーにしては珍しくわかりやすい系）

https://www.oreilly.co.jp/books/9784814400737/

ちなみに経典とはこいつのことです（エリックエヴァンスのドメイン駆動設計）:

https://amzn.asia/d/4GuzIEF



# Ruby on Rails
勉強中の技術です。現在スーパーロング長期インターン中で、しばらくRubyを使うことになりそうなので勉強しています。MVCアーキテクチャで、Railsのルール（Rails Way）で開発できるので、結構サラッと開発できるのが魅力的です（Next.jsなどでも使われる「**設定より規約**」の原則が用いられている）。何よりActiveRecordがぐう有能であるため、リレーションやORマッピングの操作がすごくやりやすいなと感じました。

**あくまで個人の意見ですが**、Railsでの開発は、*Railsがインターフェースになって、Rubyというユビキタス言語を使ってドメインモデルを作っている印象*です。基本はRailsが提供するActionController, ActiveRecord, ActionViewなどを継承し、指定された名前でメソッドを定義するため、インターフェース→インプリメントという流れではなく、インプリメント→インターフェースを定義している感覚が強いなと感じました（実際DBの永続化処理とかは、ActiveRecordがやってくれるし、インフラ層的な立ち回りはRails側がやってる印象）。

このことからも、書籍とかより実際に実装を見て勉強した方が早そうなので、困った時は、Railsガイドとリポジトリを見るようにしてます。


https://railsguides.jp/

https://github.com/rails/rails

この辺りは、かなり未開拓な部分が多いので、また一通り勉強してみて、考察記事を書けたらいいなと思ってます。


# おわりに;余談
今年一年もあっという間でした。私は今年の最初に「**勝利**」という抱負を立てたのですが、色々な人や運の巡り合わせもあって、まさに勝利を体現したような一年でした。来年はさらに伸びるように、また抱負を立てて、一年頑張りたいと思います。皆さん、2024年もお疲れ様でした🙋