大規模なロジックをリファクタリングしてみての学んだこと３つ

こんにちは、PharmaXでエンジニアインターンをしている川端です。PharmaXでは主にフロントエンドの開発を担当しています。

この記事の概要

この記事では、大規模なロジックをリファクタリングして学んだことを３つ紹介します。
本記事の流れは以下のような流れになっています。

• リファクタリング対象の機能の紹介
• リファクタリングのbefore・after
• リファクタリングを通して学んだこと

どんな機能を作っているのか

PharmaXでは、オンラインでお薬の受け取りができるサービスを開発しています。
そのうちの機能の一つとして、「問診」と呼ばれる機能があります。
「問診」とは、以下のような項目を事前に聞いておくことでより安全に、安心して服薬をすることができるものです。

問診で聞く項目の例：

• これまでにお薬を服用して副作用があったか
• 食べ物や花粉、ハウスダストなどのアレルギー情報
• 体質（例：下痢、便秘、冷え性など）
• 他に治療中の病気
• 他に服用中の薬（医療用、一般用、サプリメントなど）
• 喫煙や飲酒の有無
• 16歳以上の女性に限り、妊娠や授乳の有無
• 小児に限り、体重

リファクタリングをする理由

1.拡張性・保守性がなかった

新しく問診項目を追加したり問診項目の順番を変更する際に、複数箇所を修正する必要があり、修正によるデグレの危険性がありました。
また、修正時には修正箇所以外の機能に影響がないかの確認（QA）が必須でした。

2.仕様のドキュメントなどが整理されていなかった

機能開発が進んでいく中で、仕様のドキュメントが整理されず更新されていませんでした。本来仕様書の代わりになるはずであったテストも十分に書かれていませんでした。

3.不具合があって修正の工数が取られていた

問診機能が起因の不具合が多く、本来やりたかったタスクを妨げられてしまう状況にありました。

リファクタリングとしてやったこと

1.設計からやり直した

設計段階では、複数案出し、メリットとデメリットを整理したうえで、選ぶようにしました。　
特に意識したのは、今後の拡張性があるかどうかの観点で比較し検討しました。

2.仕様のドキュメントを整理した

仕様については、既存メンバーに聞きながらフローチャートを資料として残すようにしました。

以下は画面遷移のフローチャートの一部です。

3.コードの品質を向上させた

自動テストを充実させました。以前は、十分に書かれていなかったテストコードを見直し、最低でもC1カバレッジを通すようにしました。

さらに、コードのリファクタリングとして関数の責務の明確化を行い、可読性の高い変数名や関数名をつけるようにしました。

リファクタリングした結果

1.拡張性が向上した

新しく機能開発をしたとしてもコードの変更量が少なく変更することが可能になりました。また、デグレが起きる危険性が減りました。

2.仕様がドキュメント化されて保守性が上がった

仕様が明確にドキュメント化されたことで、新たにプロジェクトに参加する開発者が作業をスムーズに進められるようになり、保守性が向上しました。

3.修正の工数が取られなくなった

リリース後一ヶ月が経過しても、今回のリファクタリングに起因する不具合は発生しておらず、「問診」機能の不具合による開発工数の浪費がなくなりました。

リファクタリングをしての学び

学び１：手を動かす前に設計をする

手を動かすよりも設計を先にするメリットは３つあると思っています。

1.自分の成長に繋がる

設計を文書化してその後実装を行うと、自分の設計が実際に機能するか、仮説が正しかったのかの検証になります。自己の技術や判断の振り返りを次に活かすことができます。

設計段階だと、具体的なコーディングに入る前に問題を多角的に分析するので、抽象的な思考力や論理的な推理能力を養うこともできます。

2.実装に時間を減らせる

手を先に動かしてしまうと、実装方針がチームとずれていた場合に大きな手戻りが発生してしまうことがあります。
チーム間であらかじめおおまかな実装方針を握っておくことで結果的に実装時間を大きく減らすことができます。

3.テストが書きやすくなる

先に設計しておき、関数の責務を明確にしておくことで、ユニットテスト範囲が明らかになり網羅的にテストを書くことができます。テストが網羅的に書いてあると保守性が高くなり結果的に品質の良い実装につながります。

学び２：設計は複数案出す

設計は可能な限り複数出すことが重要です。複数案出すと各案の利点と欠点を明確に評価することができます。

1つの案に依存してしまうと、その案に問題があった場合に大きなリスクを負うことになります。1つの案が不十分であった場合の代替え案を持つことで、問題があった場合でも落ち着いて別の案に移行できます。

学び３：周りのコードと合わせる

自分だけのスタイルでコードを書いてしまうと、後でそのコードに触れる人が混乱することがあります。
だからこそ、チームで開発を進める際には、既存のコードスタイルにできるだけ合わせることが大切です。

しかし、過去のコードスタイルに合わせるよりも別の書き方で書いた方が良いと考えることもあるでしょう。その場合は、以下のようなアプローチをとると良さそうです。

1.現状書いているコードの意図を汲み取る

なぜそのように書いているのかを理解することが重要です。（意図が見えない場合は、チームメンバーに確認すると良いと思います。）また、コードを変えるとどのようなメリットがあるのかを整理するようにします。

2.注意を払った上で修正する

チームメンバーに確認して、全て修正する。 or バックログに上げるかコメントなどをして残す。
後の人が書く際に混乱しないように配慮することが大切です。

最後に

今回は、大規模なロジックをリファクタリングして学んだことを３つ紹介しました。どのような開発においても活かせることなので、今後開発する際は今回の学びが無駄にならないようにします。