最終的な目標を定め、改善方針を策定
では、これらの改善を新規機能の開発を止めずに行うにはどうすればいいか。MyReferの開発チームはルールを策定し、その徹底を図っているという。
まず、新規で追加する機能はReactで開発。既存機能の改修に関してはReactを使用するかどうかをその都度検討している。そのほか、ESLintでエラーになったコードはpushしないといった基本的なルールも定めた。「実感としてブラックボックス化されたソースコードを読み解いて、影響範囲を気にしながら修正するよりも手間がかからなかった」と鈴木氏は印象を述べる。
また、MyReferのフロントエンド全体をいきなりSPAにするのではなく、まずは画面ごとのReact化を完了させる。そして最終的に目指すのは「バックエンドはAPIのみを提供する」「APIはスマホアプリと同じものを使用するようにする」「Webのフロントエンドを最終的にはSPAにする」の3点。現在は最初のステップである「フロントエンドの改善／検証」に取り組んでいるというわけだ。
なお、フロントエンドだけではなくバックエンドもGoで作り直し、順次APIを作成することを目指している。「フロントエンド、バックエンド共にステップ1の足並みがそろい次第ステップ2に移行し、Webとモバイルの両方でSPA化を完了させたい」と鈴木氏は意欲を見せる。
こうした取り組みを進める中で、鈴木氏は「新規機能の開発についてはうまくいっている。また、既存機能の改修も『部分的に』うまくいっている」と評価。既存機能に関しては、仕様が単純な画面の改修はスムーズだったものの、複雑な画面のReact化は困難を極めているという。「複雑な既存コードを改善するところまでなかなか着手できていないというのが正直なところ。その理由は純粋にデグレードが怖いことにある」と語る。
経験と反省点をもとに、自信を持ってリファクタリングできる環境へ
さらに鈴木氏は「実際、改善に取り組んでみると勉強不足だと感じた。最近になって知ったこともある」と振り返り、TypeScript2.3以降で使用できるJavaScriptファイルの型チェック機能の存在を紹介した。それまでMyReferのフロントエンドではBabelを使用していたが、TypeScriptのバージョン2.3からJavaScriptファイルのJSDocのアノテーションをもとに型チェックができるようになった。こうしたJavaScript用ユニットテストを使えば、コメント文の修正だけで既存のコードにも無理なくリファクタリングできる。「最初から入れておけば、と反省している」と鈴木氏は語った。
さらに鈴木氏は「やってみてわかった失敗」として、未定義の変数利用についての手順ミスを挙げた。既存のコードの中でvarをつけ忘れて変数指定をしているものがあり、それまでは変数がグローバルに展開されるだけで、「一応」動いていた。しかしwebpackのインポートを使用すると、自動的にStrictモードになり、宣言されていない変数を使うと実行時エラーが発生してしまう。これが生じたのは、たまたまReact、webpack導入後にESLintを導入したため。鈴木氏は「webpack導入よりも先に、ESLintで未定義の変数の利用をチェックしておけば防げた」と振り返った。
そして、取り組みにおけるMyReferチームでの連携強化のため、勉強会や共有会を数回にわたり実施。また、Visual Studio Codeなど各エディタの設定に関しては、ツールを導入する人がリーダーとなり情報共有を行った。いずれも誰かが率先して行う必要があるため、苦労があったという。
最後に鈴木氏は「Reactとモジュール機能を使用することで、新規機能を中心に改善できた。ただし仕様が複雑なところに関しては、デグレードが怖くて着手できない部分が残っていた。それでもテストの仕組みやTypeScriptの型チェックを導入することで差分が生じていないことを確認できれば、自信を持ってリファクタリングできる環境を実現できるのではないか」とまとめた。そして「最終的には、MyReferのSPA化、アプリとWebに共有のAPI、バックエンドのAPIサーバーへの作りかえまで、時間がかかるかもしれないが、レガシーなフロントエンドの開発環境改善を実現させていきたい」と今後の改善に意欲を見せ、セッションを締めくくった。
お問い合わせ
パーソルキャリア株式会社
