Q&A
実際のソースを見ないとなんとも言えませんが、まずはデータとビューを分けるところからでしょうね…。
自分が未熟な時から触っていたプロダクトがあるのですが、そのプロダクトの僕の担当部分はReactでのフロントエンド領域で、複雑な変数の加工ロジックと、viewを触るための処理(ほとんどsetState)を一緒に書いてしまい、凝集度は低く結合度は高い所謂Fat controllerが出来てしまいました。
ただそのプロダクトはおそらくいずれ自分の手を離れ運用されていくことを考えるとその状態は脱したいなというお気持ちでいます。
方針としてはreactならcustom hookで複雑な加工処理部分を別のところに閉じ込めればいいんでしょというのは立つんですが、あまり事故を起こさず遂行する方法が思いつきません。
やっと本題ですが、こういう密なコードの凝集度を上げ結合度を下げる工程で参考になりそうな事例、記事、登壇のアーカイブを何か知りませんか？
該当するものであれば言語、FWは問いません。出来れば日本画か英語のソースだとありがたいです。
個人的にはテストくらいしか思いついてなくて。。
回答1件
0
ベストアンサー
方針としてはreactならcustom hookで複雑な加工処理部分を別のところに閉じ込めればいいんでしょというのは立つんですが、あまり事故を起こさず遂行する方法が思いつきません。
方針は見えていらっしゃって、「あまり事故を起こさず遂行する方法」が要点であると思いますので、
それに沿って解説します
テストは王道なので、避けることはできませんが、
テストにかかる労力と時間を最低限にする考え方があります
「スモークテスト」という考え方
いきなりすべてのリスクに対してテストを作らなければならないと考えると、
それは大変です。
まず、リスクの大きい割にテストが簡単な部分に対するテストをしましょう。
たとえば、スマホの組み立て工場で、
組み立てたスマホに電源を入れて煙を吹き出したら、
確実に出荷できませんね。
組み立てたスマホに電源を入れるだけだったら
すぐできるので、その作業を工程に組み込むと
労力と時間がかからない割に安全性が一気に上がります。
参考: スモークテスト（すもーくてすと） - ITmedia エンタープライズ
リスクの分析
各リスクは次の考え方で分析して比較します
発生確率 x 影響度
参考: 発生確率・影響度マトリックスとは何か？PMBOKのリスク分析の手法を解説 | Promapedia
リスクに対応するためのコスト
これは次のようになるでしょう。
- 手動テストの場合
- 作業する労力と時間
- 自動テストの場合
- プログラムする労力と時間
参考: リスクマネジメントとは? | 株式会社日本アルマック
自動テストと手動テストの組合わせと使い分け
あるテスト項目を自動化するべきかどうかは、
そのテスト項目を繰り返し行う必要があるかどうかで決めると良いでしょう。
特に自動テストの基盤が構築されていない時期は
自動テストの実装にかかる労力と時間が
1 回の手動テストに比べて多くなることが多いでしょう。
リファクタリングの内容によっては
1 回のテストでその後の安全性を確保することができることがあります。
その場合は手動テストの方が効率的です。
同時に、少しずつでも自動テストの基盤を作っていかないと
いつまで経っても自動テスト実装のコストが高いままで
手動テストに追われ続けることになります。
まずは、自分のローカルの環境で
jest コマンドで自動テストが動くだけでも構わないので、
自動テストの実装を始めることが重要です。
そうすれば、そのテストはいつでも
ローカル環境でコマンド1つで確認できます。
CI による自動化はその後で構いません。
参考:
【資料公開】自動テスト vs 手動テスト – Ryuzee.com
Jest · ????快適なJavaScriptのテスト
投稿2020/06/27 04:33
総合スコア3272
あなたの回答
tips
プレビュー
