EY-Office ブログ

リファクタリングのお仕事をしてみた(まとめ)

リファクタリングのお仕事をしてみたリファクタリングのお仕事をしてみた(2)のまとめです。
リファクタリング作業を行った後に、お客様の開発者にZoomでリファクタリングの研修を行いました。

リファクタリング Refactoring (Addison-Wesley Signature Series)

リファクタリングの目的

EY-OfficeのReactやRuby on Railsの研修テキストには「良いコードの書き方」という章があります。
その中では「正しく動くのはあたりまえ、プロのプログラマーはメンテナンス性の高いコードを書くのが仕事」と教えています。

良いコードの章では、良いコードを書くための具体的な項目を説明していますが、これらは書籍等で言われてきたものうち、私自身の開発の経験から重要だと思う事を説明しています。

リファクタリングの目的はコードのメンテナンス性を高める事です。大部分のコードは思っていた以上に長年使われます、その間に機能追加や変更が行われますが、メンテナンス性の低いコードはこれらのメンテナンス作業を困難にします。
理想的には最初のコーディングからメンテナンス毎に良いコードを書く(保つ)事が重要です。

また良いコードを書く作業は、最初は時間がかかりますが、慣れてくれば時間をかけずに良いコードを書く習慣が身に付くと思います。

今回のリファクタリング項目

コーディングスタイルの統一

もとのコードはインデントのサイズや演算子前後のスペースの入れ方などが統一されてなかったのでPrettierを使って整形することでコーディングスタイルを統一しました。
このようなツールには好き嫌いがあると思いますが、手間(コスト)をかけずにコーディングスタイルが統一できるのは、素晴らしことだと思います。

コンパイル警告の解消

もとのコードにはコンパイル警告がたくさん出ていました、多かったのは未使用変数や未使用importなどでした。警告を放置しておくのは割れ窓理論で、悪いコードへと繋がると思います。
未使用変数のように実害がないものもありますが、たまに潜在的なバグが指摘されている事もあります。しかし大量の警告が出ていると、重要な警告を見落として(無視して)しまう事も発生します。

型定義ファイルの統一

これは「リファクタリングのお仕事をしてみた」の重複コードに書いたものです。

バックエンド通信部分をReactコンポーネントからReduxに移動

これは 「リファクタリングのお仕事をしてみた(2)」のAPI通信部分をReduxに移動に書いたものです。

Reduxの書き方の改善

もとのコードでは、Reducerが非破壊的な更新を行うようになっていました、それは良いことですがコードが不可思議なコードでした。このプロジェクトではRedux Toolkitを使っているので、Reducerはシンプルで直感的な破壊的更新コードにかえました。

また redux-loggerを使っていませんでしたが、これを入れるとデバッグが楽になるので導入しました。

map,filter等を積極的に使う

このプロジェクト参加者はJavaプログラマーが多くmap, filterなどの高階関数を使った経験が無かったようなので、map, filter等の復習を行いました。

mapやfilterメソッドは、for文を使うよりコードの意図が明確になるのが良い点だと、私は思います。

  • map: 配列の要素を操作して新たな配列を作る
  • filter: 配列から条件に合う要素のみの配列を作る
  • find: 配列から条件に合う最初の要素の要素を返す

any型を止める

これは「リファクタリングのお仕事をしてみた」の危ういコードに書いたものです。

コーディングルール

これは「リファクタリングのお仕事をしてみた」の規約違反に書いたものです。

まとめ

Reactの研修を受けた後、はじめての仕事ではいろいろと悩む事が多いと思います。また納期等から良いコードを書くことを忘れてしまいがちです。
EY-Officeではコードレビューやリファクタリングのサービスも提供していますので、このような時には気軽にお問い合わせください。

- about -

EY-Office代表取締役
・プログラマー
吉田裕美の
開発者向けブログ