こんにちは、EC 事業部エンジニアのryoma123です。この記事は EC ブログリレーの17日目の記事です。16日目は @hrysd による カラーミーショップで使っている Rails のバージョンを 5.0 系から 6.0 系にできた〜 でした。
私の所属するチームでは EC サービスの機能改善を日々行っているのですが、過去に設計されたロジックに変更を加える機会がよくあります。この記事では、既存のコードの動きを変更するときに、個人的に心がけていることを紹介します。
既存のコードに対するテストコードを作成する
これから変更を加えるロジックにテストコードが存在しない場合は、新しい動きを追加する前に、既存のコードに対するテストコードを作成するようにしています。既存の動きには変更がなく、意図した変更だけがされたことを確認できるようにするためです。
変数のスコープを狭くする
グローバル変数のようなスコープの広い変数を利用している場合は、クラス変数やローカル変数など寿命の短い変数に置き換えられないか考えるようにしています。リファクタリングを行ってから新しい変更を加えることで、変更による影響範囲が小さくなるかもしれません。
冗長なコメントを整理する
コードを読むことで把握できそうな情報がコメントに書かれている場合は、重要なものを除いて削除するようにしています。また、関数や変数の名称を見直すことで、コメントに記述されている情報を含めることもあります。
複雑な条件式を分割する
ある関数の中で条件式が入れ子になっている場合は、処理を必要としない条件がないか探すようにしています。そのような条件があれば、早めに return をして関数から抜けることで、条件式がシンプルになるように整理しています。
いま必要なコードだけを書く
拡張性を想像して複雑なコードを書いてしまわないように気をつけています。将来本当に拡張されるのかわからないにも関わらず、工数が増えてしまい、可読性も悪くなってしまった経験によるものです。現時点で汎用的にする必要がなければ小さく作っておいて、必要なときに拡張できる程度に留めるようにしています。
まとめ
紹介した内容は、状況によって必ず当てはまるものではありませんが、変更を加える際には既存のコードを整えるように心がけています。これからも安心してサービスを提供し続けるために、変更に対して柔軟なコードの書き方を試行錯誤しながら学んでいきたいと思います。