ルールの運用から始める フロントエンド開発改善 2023/04 カシフクトモヤ

自己紹介 カシフクトモヤ @cashfooooou 2023/04 ~ 株式会社マネーフォワード 福岡拠点 - Web フロントエンド - 競技プログラミング - 自動テスト - TypeScript / Elm / OCaml / Rust

今日のテーマ 開発者体験の向上のために 「ルールの運用を見直すこと」から始めてみよう

想像してください こんなプロジェクトに参画 ● React を使っている ● Atomic Design を取り入れている ● Redux を使っている

チームから上がる不満の声 ● React のルールに則った書き方ができてない、気がついたら悪い書き方をしてしまう ○ key を付与していない、 useEffect の deps が不適切 ● 新しく作る UI コンポーネントが Atomic Design のどのグループに属するかわからない ○ Atoms と Molecules の境界、 Molecules と Organisms の境界が曖昧 ● Redux の store をどこからでも参照してしまって制御が難しい

不満のもととなる問題・不安 ● 既存の実装に不満があるけど、どのように直したらよいかわからない ● 今は想定通りの挙動をしているけど、いつバグが発生するかわからず不安だ ● 開発のタスクで手一杯なので、既存の実装の改修に時間をかけられない ● 実装のルールを作っても、ルールを守るのがたいへんで実装が難しくなる

問題・不安を解消するルールの運用 実装のルールを作って適切に運用することで、簡単に守られる状態を作ることで解決したい ● ルールが作られた背景が明確であること ● 人が注意しなくてもルールが守りやすい状態になっていること ● チームメンバーがルールに対してポジティブであること

背景を明確にする ● なぜやるのか、なにに困っているか ● どのように考えたか ● どう実行するか 簡単な ADR や Slack のスレッドなどに書き込んで、後から見返せる状況を作る 初めからしっかりとドキュメントを作らなくてもよい

背景を明確にする 例） Molecules と Organisms の境界についてのルール なにに困っているか 人によって判断がぶれて、コンポーネントが見つけられない。 Molecules から Organisms を参照してしまうことがある。 どのように考えたか コンポーネントの複雑さは、人によって感じ方が異なる。 AtomicDesign の再利用性を活かしたいので、ビジネスロジックを含 むか否かで分別するのがよいかも。 どう実行するか Molecules が models （ビジネスロジックの定義）に依存しないよう にする。

自動的にルールを守る仕組みを作る 人の手だけでルールを守り続けるのは難しい、レビューの負担が大きくなる 可能な限り自動化して、気がつくとルールが守れている状況を作る ● アーキテクチャを工夫する ○ 期待しない実装ができない状態 ● linter （eslint、 stylelint …）を導入する ○ 期待しない実装をすると警告を出してくれる ○ 導入も変更もカンタンでよい

自動的にルールを守る仕組みを作る 例） Molecules と Organisms の境界についてのルール 「Molecules が models （ビジネスロジックの定義）に依存しないようにする」というルールを自動化 eslint の import/no-restricted-paths を使ってルールを定義する

ルールに対してポジティブになる ● 「守らなければならない義務」ではなく 「守るとみんなが幸せになるもの」 と全員が意識する ○ メンバーの不安を解消するルール作りを心がける ○ 守られていないときは、守りやすくするためにはどうするか考える ● ルールに則った実装に納得できないときは、ルール自体を見直す ○ 守らなくていいルールはない（ 割れ窓理論） ○ ルールを属人化させない、みんなで作り上げる ○ 小さく始める

明確なルールを作って嬉しいこと ● 意図しない実装が減る ● レビューの負担が小さくなる ○ メインのトピックに集中できる ● オンボーディングにかかるコストの減少

まとめ ● 実装の不満が上がったときは、不満を解消するルール作りのチャンス ○ 意思決定の背景を明確にする ○ 可能なら自動化する ● ルールに対してポジティブに考えて、守り続けるように運用する