0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

人生で一番長くリファクタリングやった話

Last updated at Posted at 2021-09-29

誰に向けたどんな記事か

とても幸運なことにフロントエンドエンジニアとして
長い期間リファクタリングする機会に恵まれた

リファクタリングで色々経験したことで
次からはこれをやっておくといいかも
と思えるものをいくつか見つけたので

これから大きなシステムを作る人や
今からリファクタリングをするんだという人に

「なるほど、これはやっておくべきかもしれない」
と少しでも「気づき」を共有できれば嬉しい

やってみてほしいランキング

第1位 E2Eテストの自動化

E2Eを自動化することで
リファクタリングや、その後の機能追加作業でデグレする危険性が下がった

[E2E (End to End) テスト]
画面操作(Web ブラウザの操作)により
想定通りの動作となっていることを確認するテスト

リファクタリングをする前にまずE2Eテストの自動化を行った
これは本当に正解だった

プログラムを変更するたびに
どこかしらでバグが発生してないか
手動で都度確認を行なっていてはあまりにも時間がかかる

E2Eを自動化することでこの手間を大幅に省くことができた
リグレッションテストとして非常に優秀だと感じた

[リグレッションテスト]
プログラムの変更・修正の際に
他の機能に問題ないか影響を確認するテスト

開発期間が長いほど、E2Eテストは自動化した方がいい
テストを作る手間を加味したとしても恩恵がある

全てのE2Eテストを自動化する必要はない
止まっては困る必須の機能を確認できる自動E2Eがあれば
それが動くことを開発中に確認するだけで
少なくとも致命的なデグレは避けることができる

細かい機能のE2Eの自動化は
テスト自体の管理コストもあるので
プロジェクトごとで要相談してほしい

いつ導入すべきか

「この機能が動いていれば大丈夫」
が言えると嬉しい時

基本的な処理ができあがって
直近に大きな変更が無い状態になったら
必要最低限の機能だけでもE2E自動化しておくと良い

見た目にはわからない他の細かいプログラムの修正の際に
それが動くことを確認できれば安心して開発を進めることができる

E2E自動化ツール「playwright」
・動画やスクショが簡単に撮れる
・画面操作を自動でコード化する機能がある

第2位 DI(依存性の注入)

DIを行うことで
APIの開発とフロントの開発を同時に進行できるようになった

依存性の注入(いそんせいのちゅうにゅう、英: Dependency injection)とは
コンポーネント間の依存関係をプログラムのソースコードから排除するために、
外部の設定ファイルなどでオブジェクトを注入できるようにするソフトウェアパターンである。
英語の頭文字からDIと略される。
引用: Wikipedia 依存性の注入

具体的にはaxiosによるAPIの呼び出し処理を
nuxtのinject機能を使ってグローバル関数とし
登録し共通処理で呼び出せるようにした

関数のreturn値をAPIからの返り値ではなく仮のJSONなどにすることで
APIが無くてもフロント側は実装を進められる

いつ導入すべきか

モックアップを作り始める段階から可能な限り行なっておきたい
むしろモックアップの段階で一番効力を発揮する

第3位 JESTのユニットテスト

チームでリファクタリングをするうえでの基準にできた
ユニットテストを軸にして自然とコードの画一化が行えた

チームでコーディングしていると
書くコードのルールがバラバラになっていた

リファクタリングでどんなコードを目指したらいいのかもわからなかったので
鶴の一声 「テストが書きやすいコードがよいコードです」に従い
テストが書きやすいコードを目指すことにした

結果「テストが書きやすいコードがよいコードを書く」
という共通認識をもちながら作業することになったため
意識してルールを作らずとも、自然とコードの書き方も統一されていった

テストそのものがバグを見つけ出す効果よりも
どちらかといえばチーム作業のしやすさに大きな効果があった

  1. やりたいテストを書く
  2. そのテストがしやすくなるようにコードを直す

一括で全て直そうとせず上記の流れを何度か繰り返すことで
次第に読みやすいシンプルなコードへと変化していった
主に以下のような修正を行った

  • テストパターンを減らしたい → 条件分岐を減らす
  • Mockをしやすくしたい → 依存関係をなくす(DI)

いつ導入すべきか

E2Eと同じで、リファクタリングの前が良いと思う
もしくは同時でも良い
テストが書きにくいと感じた時点でコードに問題がある

テストから書く場合はテスト駆動開発になるのだろうけど
これは経験したことがないのでわからない

ユニットテストとして効力を発揮しているのかは
まだ体感としては得られていないので難しいところ

まとめ

一ヶ月以上かけてこれらを経験し
非常に良い勉強になった

コードを書くときの意識がかなり変わったし
より効率的に書けないか常に意識するようになったと思う

プロジェクトの期間や傾向で導入が難しいものがあるのも理解できるが
少しでも参考になることがあれば嬉しい

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?