はじめに
エンジニアとして働き始めた当初、私はインタプリタ言語の心地よい世界に浸っていました。変数を宣言すれば勝手に箱が用意され、不要になればガベージコレクションが掃除してくれる。そんな「メモリを意識しない開発」が私にとっての常識でした。
しかし、ある日突然、C言語を使ったサーバー周りの改修タスクにアサインされたことで、私の常識はあっさりと崩れ去ることになります。
突如現れた「メモリ」という概念の壁
C言語のコードを開いた瞬間、そこには未知の世界が広がっていました。
*（アスタリスク）や&（アンパサンド）が飛び交い、mallocで領域を確保し、freeで解放する。
「えっ、変数の場所って自分で確保して、自分で片付けないといけないの…？」
インタプリタ言語では「値」だけを見ていればよかったのに、C言語では「値がどこに住んでいるか（アドレス）」と「どれくらいの広さの部屋か（サイズ）」を常に意識しなければなりません。
どこでメモリの扱いを間違えているのか、画面を睨みつけても全く原因が掴めず、完全に手が止まってしまいました。
窮地を救ってくれた「ペアプログラミング」
溺れかけていた私を見かねて、先輩エンジニアが「一緒に見ようか」と声をかけてくれました。ここから、私にとって人生初の本格的なペアプログラミングが始まりました。
先輩は私の横に座り、ただコードを直すのではなく、まず図を描くことから始めてくれました。
先輩のナビゲートのもと、図とコードを見比べながら1行ずつ処理を追っていくと、魔法のように難解だったC言語のコードが、「物理的なメモリの操作手順書」として立体的に見えてきたのです。
リアルタイムで指摘をもらい、議論しながらコードを書き換えていくプロセスは、一人で悩んでいた数時間が嘘のようにスムーズでした。結果として、ギリギリのスケジュールの中で無事にタスクを完了させることができました。
この経験で得たもの
この時の「メモリの壁」と「ペアプロ」の経験は、その後のエンジニア人生に大きな影響を与えました。
-
コンピュータの裏側の動きを意識できるようになった
C言語でメモリと格闘したことで、他の言語を書いている時でも「裏でどう動いているか」をなんとなくですが想像できるようになり、パフォーマンスを意識したコード設計ができるようになりました。 -
ペアプログラミングの絶大な効果を知った
知識の共有や問題解決において、ペアプロがどれほど強力なツールかを身をもって体感しました。チーム開発において、行き詰まったら一人で抱え込まずに声を上げる重要性も学びました。
おわりに
便利な言語やフレームワークが増え、メモリを直接意識しなくてもシステム開発ができる時代です。しかし、一度C言語などの低レイヤーに触れて「メモリの壁」にぶつかることは、エンジニアとして一段階レベルアップするための素晴らしい通過儀礼だと今は思えるようになりました。