【月次報告】エンジニアになって11ヶ月が経ちました

こんにちは、しゅんです。エンジニアになって11ヶ月が過ぎましたので今月も振り返りをしていこうと思います。この記事を通して未経験からエンジニアになった人の「その後」が気になる方や自分と同じような駆け出しエンジニアの参考になりましたら幸いです。

※エンジニアになって10ヶ月目の記事も投稿しています。お時間ございましたらご覧ください。

■エンジニアになって11ヶ月が経ちました

教育サービスの案件に携わっています。こちらは去年の12月からずっと関わっており、かれこれ5ヶ月続いています。受託会社に所属しているので一つの案件にこれだけ長く在籍するのは珍しく感じますが個人的にはかなり愛着のある案件になっています。

今月は4月のアジャイルが思ったよりも早く終わったので最近はサーバー側で過去に実装してもらっていたe2eテストをフロント側で管理できるようjest-puppeteerへリプレイスする作業をしています。

実装の背景①

---

自分が案件に参画するまでテストはサーバー側がユニットテストだけでなくブラウザテストまで全体をカバーしていました。（一応、jest-puppeteerの設定はされていたようですがフロントのリソース不足で実装していなかった模様？）

当然ながらテスト用のカスタム属性がVueファイルに紛れており、仕様変更などの不意なことでサーバー側に「これは消して良いのか」などの確認をするやりとりが何回も発生していたので早くから見直す必要があると思っていました。

ブラウザテストを完全にフロントの管理下に置けばこれらのコミュニケーションは不要になりますし、サーバー側はユニットテストのみの実装になりブラウザテスト書かなくてよくなるのでその分負担が軽減されます。

このようにテスト実装に関してサーバー側とフロント側との境界線をはっきりさせることで得られるメリットがあると思ったのでフロントでe2eテストを実装（リプレイス）することになりました。

実装の背景②

---

2つ目の実装の背景としてはサーバーで書いているテストが積もり積もってCIから「書きすぎやで」と警告が出たからです。40万文字以上は書けないっぽくこの警告は初めて見ました。課金すれば解決するのか？

サーバー側もこの警告については最近見るようになったらしく物理的にテストコードを減らせば回避できるとのことでしたが、それなら実装の背景①メリット（サーバーテストをフロントテストにリプレイスすることでコード量を減らせること）もあるのでサーバー側でも「今一度不要なテストがあるか確認・選定をしよう」となって今に至ります。

実際に使用していないファイルや関数が見つかりわずかではありますが、コードの見通しがよくなっています。

直面している課題と解決策

---

e2eテストのシナリオが長すぎると一つのテストファイルに書くコードも長くなってしまうのでどう分散していくかが今直面している課題です。

切り出せる部分はモジュールとして切り出すか、いっそのことシナリオのtest単位で区切って関心事としてまとめるか、ドメインを持ってしまい使いまわせない場合はどうするかなど、いまいちベストプラクティスが見つけられず困りました。

暫定なのでまだまだ変更する可能性がありますが冗長になっていまうコードの対策として2回以上使っている関数に関してはhooksディレクトリに切り出すことにしています。ファイルの命名はReactの影響を受けています。このディレクトリはドメインを持つものに限定し後述するsupportディレクトリとの差別化を図っています。

2回以上使っているがドメインを持たない関数はsupportディレクトリのutilitiesファイルにまとめています。（textContentのチェックとかinputフィールドのクリアとかスクロールなどの比較的小さくてドメインを持たない関数を一括で保持しているのがutilitiesファイルです。）supportディレクトリ自体、分類に困ったら放り込む場所として位置付けしており、テストで使うユーザなどの定数の格納先にもしています。

図にすると次のような感じです。

└── __test__/
    │   
    ├── e2e/
    │   ├── admin/
    │   │   ├── 01_admin_A.test.js
    │   │   └── 02_admin_B.test.js
    │   │ 
    │   └── user/
    │       ├── 01_user_A.test.js
    │       └── 02_user_B.test.js
    │
    ├── hooks/      
    │   ├── useAuth
    │   └── useCreateUser
    │   
    ├── support/
    │   ├── utilities
    │   └── constant
    │    
    └── unit/
        ├── ...
        └── ...
            

得られている成果

---

完全にjest-puppeteerへの移行はできていませんが大きな機能単位のリプレイスは終わっていて後は細かい機能の移行のみです。主観ではありますが、ブラウザテストでは割と使う関数が決まっているのでモジュールとしてあらかじめ関数を切り出しておき、組み合わせるだけの状態を作っておくことで後半になってテスト実装が格段に早くなりました。

Vueファイルに関しては完全にサーバーのカスタム属性を取り除くことができフロントのみで管理できるようになりました。おそらくこの恩恵を受けられるのは次の追加機能の実装時になると思われます。

また、jest-puppeteerの特徴として非同期で処理をしてくれるので思っている以上に早くテスト処理をしてくれます（ローカルテストでのみ同期的に変更し、目視で確認できるように一部カスタマイズしていますが…）CIテストの時間を短縮できたのは大きな成果でした。

具体例）1分のテストを5個作ったら実行に5分かかるが非同期なので1分で終わる。

■Storybookやテスト実装は開発を楽にするのか

最近社内勉強会でStorybookについての議題があったので今回のテスト実装と絡めてメモをします。※StoryBookの詳細、メリットなどは省きます。

どうしてもStoryBookやテスト実装は機能開発とは異なる分野なため、これらの工数をクライアント側が考慮してくれるのかにもかかってくると思うのですが、根本としてStoryBookやテスト実装をしたら開発は楽になるのかという話です。

結論としては「導入するだけなら開発は楽にならない。運用者を決めたりガイドラインの作成やこれらのツールの使いやすい土壌・導線を確保して初めて効果を発揮する」のだと思います。少なくとも責任者を決めて運用して行かないと、例えばStoryBookを確認せずに同じコンポーネントを作ってしまったり、新しく作ったコンポーネントをStoryBookに追加しなかったりするのかなと。

テストだったらそもそもテスト実装をしなくなるかもしれませんし、CIエラーが発生したらコメントアウトしてなかったことにしてしまうなど。導入したから魔法のように実装が楽になるのかというとそうではなく開発者が使いやすくなる土壌を整えることで初めて意味をなすものなのだと気付かされました。

今の案件はフロントエンジニアが自分しかいないのでなんとかなっていますが、後続が入ってきたときにテスト実装を継続してもらえるよう大急ぎで実装のガイドライン・ドキュメントの作成をしています。

■11ヶ月目を過ぎて思ったこと

先月は個人開発でSvelteに触っていたのですが、その際にRollupに躓きました。私がプログラミングに興味を持ち出した時にはVue.jsやReactなどJSフレームワークが存在しており、モジュールバンドラーについて知識がなくてもコードを実装することができました。

そのような思わぬ落とし穴があったのでSvelteの勉強を一時中断してWebpackなどのモジュールバンドラーの実装やCommonJSやES6についての違いやモジュール機能、Class構文など今まで意識していなかった箇所に注力して勉強をしています。JSフレームワークばかり触れておりこれらのようなラップされている機能に関しては深堀する機会がなかったので、そう考えるとSvelteに触ってきっかけを作れてよかったなと思います。

■最後に

（フロントエンジニアとして案件を一人で切り盛りするのを独り立ちとするなら）独り立ちして2ヶ月が過ぎました。相変わらずレビューをしていただく人はおらず、少なくとも同じ案件で意見を言い合える人が欲しいと思うこの頃です。

今回からnoteの新エディタを利用していますが、Notionライクなのかあまり違和感なく記事をかけています。個人的には新エディタかなり好きです。

今後も継続してこの月次報告をしていこうと思っています。是非今後ともよろしくお願いいたします。駆け足になりましたが最後までご覧いただきありがとうございました。