難解なコード、迷宮となった設計
古今東西、難解なコードというものがあります。
6重・7重にもなるネスト、一体何が引数として渡されてきているのかもわからないメソッド、泣きたくなるような構造の中に組み込まれた業務要件…
これらをどうリファクタリングするか、そもそもリファクタリングをしなくて済むようにどのように設計するか、というのはエンジニアがすべき仕事のひとつです。そのような設計ができるよう、多かれ少なかれエンジニアは学習を続けていく責任があると私は思っています。プロダクトに責任を持つ、壊れにくく、障害が発生するリスクを抑え、開発および改修コストを可能な限り下げて最適化する。技術力に差異はあれ、そのサイクルを適切に繰り返していければ、理論上はシステムは綺麗に保たれるものでしょう。
しかしながら、一回こっきりのチャンスで難解なコードを読み解き、開発や改修を行わなければならないシーンもあります。私がこのような難解なコードや迷宮となってしまった設計にメスを入れて改修を行わなければならない時、何を考えて手を入れているのか、この機会にアウトプットしてみようと思います。
難解なコードを見た時に考えたこと・行ったこと
- まず、目の前のシステムは一旦置いておいて、通常そのアプリケーションがどのようなアプリケーションであるか・どのようなフレームワークを使用しているかを把握・理解する
- 基礎を迅速にキャッチアップ・思い返した上でコードに挑む
- 目にするコードおよび設計とは別に、きれいな設計をまず頭に浮かべておく
- 理想的な目指すべき方向が自分の中にあってはじめて、難解なものが難解であることに気付ける
- こういうタイミングの時のために、日頃から設計について考えるようにする
- 具体的にどの実装がどの方向に理想的なアーキテクチャからずれているのかを把握する
- 子細に把握しすぎると時間が溶けるので、必要十分な把握で
- この部分がこの方向にこれだけずれている、というのを把握した上で、改修に着手する
- 業務要件の書かれたドキュメントを読み込んだり、前任者や関係者に業務要件について確認したりして、これから作ろうとしているものの形を脳内で形成する
- これをいかにずれている箇所に綺麗に入れ込むか、というところ
逆に、行わないようにしていること
- 動いているコードは動いているままにして、必要以上に触らない
- 筆者は以前、よかれと思ってコードを触ったところ、予期せぬ変数が入ってきて痛い目を見たことがあります…
- 特定の条件になるとNULLが入ってくる仕様となっており、結構信じがたいことだったのですが、信じがたいコードが埋まっていることもあると学びました
- 寝るコードは起こさず
- もちろん、計画的にリファクタリングを行うのは非常に有用なことだと思います
- あくまで、臨時で一回こっきりの改修しか行うことができないという場面においての対策です
- 冗長なコードから無理に部分をメソッドに切り出すこと
- これも上記と同じで、信じがたい値が予期せぬルートからやってくることがあるため
- じゃあ渡されてくる変数を戻って辿ればいいじゃん、と思うかもしれませんが、このようなシステムは大概渡されてくる前の前の段階で予期せぬものに化けていたりするので、怖いです
- 一部分だけ綺麗にしようと、理想的なアーキテクチャに沿った実装として新しくクラスやコンポーネントを増やすこと
- これは、A・B・Cと同じようなずれ方をしているものがある場所にDという要素を増やすとき、Dが理想的にある箇所はここだから、といってDのみ別の場所に置かない、といったようなことです
- Dだけ別の場所に新設すると、自分から迷宮を増設することになると私は思っています
- なので、不本意を感じつつ、全体の統一を優先してA・B・Cと同じ個所にDも増設するようにしています
- 繰り返すようですが、どこかのタイミングでこれらに切り込めることが望ましいことが前提です
まとめ
短文ではありますが、個人的に難解なコードに直面した時にまず何を考え、何を行っているかについて書き出してみました。人によって思想や設計のスタンスは違うことは前提として、参考になりましたら幸いです。
🔗参考Link
心掛けよう、SOLID原則
関数・メソッドあたりの行数
私は尊敬しているエンジニアの方から「1メソッドは一画面に収まる量までにして」と教わりました
UNIX哲学
余談
最後に「まとめ」を書くと技術記事としてまとまりが出ると気付きました。
本記事ははじめてのひとりアドカレ2024 by hayami Advent Calendar 2024の3日目の記事ですが、4日目以降も「まとめ」を取り入れていこうと思います。