リファクタリングのお仕事をしてみた 、リファクタリングのお仕事をしてみた（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ではコードレビューやリファクタリングのサービスも提供していますので、このような時には気軽にお問い合わせください。
