はじめに

こんにちは！春になり再びアウトドア熱が高まってきている、エンジニア2年目の山元です！

自分は今年の1月~3月の間、リファクタリングプロジェクト（以下、リファクタPJ）に参加していました。

オープンワークのリファクタPJの詳細については、以下の記事をご覧ください！

techblog.openwork.co.jp

今回は、新卒エンジニアである私が、3ヶ月間のリファクタ経験からどのようなことを学び、感じたのかをまとめたいと思います！

気付き・感想ベースの記事となっておりますが、最後まで読んでいただけましたら幸いです。

1. 読みやすい綺麗なコードを書くことは自己満足ではない

まず、リファクタPJで汚いコードの Before After を見たことで、整理されたコードの重要性に気づくことができました。

以前までは「汚いよりは綺麗な方がいいよね」「綺麗なコードがかけたら気持ちがいいよね」くらいの感覚でした。ごちゃごちゃして読みづらくても、読めないことはありません。

綺麗に書かれたメソッドと、別のごちゃごちゃしているメソッドを見てもピンときませんでした。しかし、リファクタリングを行うと1つの汚いコードの Before After を見ることができます。リファクタリングを通して初めて、汚いコードがどれほど読みづらく変更しにくいか、それがどれほど開発の妨げとなるかに気がつきました。

2. クラス名、関数名、変数名は大事

適切に命名をしただけでコードが見違えて良くなる経験を何度もして、命名の大切さが身に染みました。

以前までの自分の認識
クラス名、関数名、変数名などはコードの中で使用する単なる識別子であるが、分かりにくいとコーディングしづらいので分かりやすい名前をつける。

現在の認識
悪い命名はそのクラス、関数、変数の振る舞いを理解するコストを上げ、今後のコーディング効率の低下及びコード品質の低下を招く。だからこそ、クラス名、関数名、変数名では、そのクラス、関数、変数がどのように振る舞うのかが明示されていなければならない。

前はわかりやすい名前をつけることはマナー程度に考えていました。名前は動作に影響はないわけですし。

ただ、適切に命名することによって、わかりにくかったコードが途端にすっきりして、作業がスムーズに進むことが何度もありました。情報の過不足がない適切な命名は相変わらず難しいのですが、その重要性は理解できたと思っています。

3. クラスの責務の切り分け大事

責務の切り分けの重要性を自分の言葉で落とし込み理解することができました。

以前までは読みにくいコードが「なぜ読みにくいのか」がよく分かっていませんでした。もちろん、コントローラに詳細な処理がベタ書きされていたり、異様に巨大なエンティティが存在していたりするのを見ると、読みづらいなと思います。しかし、それがなぜなのか、上手く言語化できていないという状態でした。

現在私は、「スパゲッティコードは責務の切り分けができていないために読みづらい」という風に理解しています。

適切にクラスの責務が切り分けられたコードは、上手に作られたスライドに近いのかもしれません。普通、プレゼンテーションの冒頭にはそのプレゼンの概要のスライドを置き、詳細についてはその後のスライドで扱います。概要スライドに各項目の詳細な説明が記載されていても読みづらいです。まず概要を述べて、プレゼンの全体像を理解してもらってからの方が詳細の理解がしやすくなります。コントローラーに処理の詳細を書いてしまっているコードは、こんなスライドと同じ状態なのだと思います。

また、異様に情報量が多くて一目で何の話をしているのかわからないスライドは、複数のスライドに分割するべきでしょう。これも、巨大なエンティティに通ずる話だと思います。

4. 良い設計ならテストコードが書きやすい。逆に、テストコードが書きにくいなら設計が悪い。

テストコードを書くことで、コードの振る舞いをテストするだけでなく、コードの設計の良し悪しについても間接的に確認できることを知りました。

恥ずかしながら、リファクタPJに入るまではほとんどテストコードを書いていませんでした。リファクタPJでテストコードを書く中で、「このコードどうやってテスト書けばいいんだ？」ということが何度もありました。先輩エンジニアに相談すると「それはテスト対象のコードの設計が悪い」とのアドバイスが。実際に設計を見直すとテストコードが格段に書きやすくなりました。

もちろん全ての場合に当てはまるわけではありませんが、テストが書きやすいかどうかは設計の良し悪しを図る1つのファクターだと思います。

5. 設計が悪いとコードはすぐに負債化する

今までは古いコードが負債になるものなんだと思っていました。

しかし、リファクタPJに入って一件目のタスクは1、2ヶ月前に実装されていたコードでした。影響範囲の小さい箇所ではありましたが、ついこの前のコードであることに違いはありません。また、そのコードも他の負債コードに引っ張られる形で負債コードとなっていました。

自分が今書いているコードも適当に設計しているとすぐに負債化し、さらに、他のコードを連鎖的に負債化させることになるんだと気付きました。将来的にどんな拡張をされるのか完全には見通せない以上、絶対に負債化しないコードというのは書けないとは思いますが、その時点でのベストは尽くすべきだなと思います。

6. テストコード書くの楽しい

テストコード書くの楽しいです！

前の項目とも関連する話ですが、すんなりテストコードがかけてテストが通ると、自分の書いたコードの設計はそんなに悪くないというお墨付きをもらったような気分になります。もちろん、それで全てがOKというわけでもないのですが、客観的な指標が1つあるというのはいいことだなと思います。

7. ペアプロ楽しい

リファクタPJでは午前中に1時間ほど時間を確保してペアプロをしていました。基本的には自分がドライバー役だったため、先輩社員のスピードについていかなければならず、刺激的な時間でした。コーディングの際に先輩が何を考えているのかがよくわかりますし、コーディングの内容以外の部分、例えばエディターの使い方なども勉強になります。

以前、短距離走の世界記録と同じスピードでベルトが動くルームランナーが、テレビで紹介されているのを見たことがあります。普通の人は到底ついていけない速度なわけで、フィットネスとかには役に立ちません。これは陸上選手のトレーニングに使われるらしいんですね。まだ若い選手がマシンの力をかりてトップ選手と同等のスピードを出すことで、世界記録・日本記録のスピードで走る時の体の使い方を学ぶそうです。

ペアプロもこれに似たところがあるんじゃないでしょうか。ペアプロをしたからといって先輩社員の精度・スピードで作業できるようになるわけではありませんが、そのレベルでのコーディングをするときの考え方や作業の進め方は体感できます。

先輩の工数を使ってしまうのが難点ですが、個人的にはペアプロは今後も続けていきたいです。

8. 設計のスキルは廃れにくいんじゃないか

IT業界、特にWeb系は使う言語、フレームワークの移り変わりが激しく、それに伴ってエンジニアのスキルもすぐに過去のものになってしまうという印象があります。

ただリファクタPJで、少しだけ設計というものをかじったり、勉強会で設計関連の技術書を読んだりして、設計は比較的廃れにくいスキルなんじゃないかと思うようになりました。

比較的新しい技術書にも、少し前に書かれた技術書にも、説明に使われる言葉こそ違えど、共通する知識や考え方が書かれていました。確かに、ビジネスロジックをいかにコードに落とし込むかという行為そのものは、言語やフレームワークに依存しない作業です。もちろん言語やフレームワークを自在に使いこなしてこそのエンジニアだとは思いますが、時代に左右されにくいスキルを持つことに対するロマンを感じています。