Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ルールの運用から始めるフロントエンド開発改善
Search
Tomoya Kashifuku
April 14, 2023
Programming
5
2.9k
ルールの運用から始めるフロントエンド開発改善
フロントエンドの開発で開発者体験が下がったときには、適切なルールの運用を始めるとよいのではないか、という話をしています。
特に主張したいのは12ページ目です。
Tomoya Kashifuku
April 14, 2023
Tweet
Share
More Decks by Tomoya Kashifuku
See All by Tomoya Kashifuku
Rustでオリジナルnpmパッケージを作ってみよう
tnyo43
0
290
ユーザのためだけじゃない!エンジニアも嬉しいアクセシビリティ改善のための自動テスト
tnyo43
0
640
フロントエンドの単体テストの使い方/考え方
tnyo43
0
330
Elm でつくるルービックキューブ
tnyo43
1
480
Other Decks in Programming
See All in Programming
Cursor AI Agentと伴走する アプリケーションの高速リプレイス
daisuketakeda
1
130
既存デザインを変更せずにタップ領域を広げる方法
tahia910
1
270
AIプログラマーDevinは PHPerの夢を見るか?
shinyasaita
1
190
AIエージェントはこう育てる - GitHub Copilot Agentとチームの共進化サイクル
koboriakira
0
490
なぜ適用するか、移行して理解するClean Architecture 〜構造を超えて設計を継承する〜 / Why Apply, Migrate and Understand Clean Architecture - Inherit Design Beyond Structure
seike460
PRO
3
740
ふつうの技術スタックでアート作品を作ってみる
akira888
0
400
来たるべき 8.0 に備えて React 19 新機能と React Router 固有機能の取捨選択とすり合わせを考える
oukayuka
2
890
VS Code Update for GitHub Copilot
74th
2
600
WindowInsetsだってテストしたい
ryunen344
1
230
Quand Symfony, ApiPlatform, OpenAI et LangChain s'allient pour exploiter vos PDF : de la théorie à la production…
ahmedbhs123
0
130
deno-redisの紹介とJSRパッケージの運用について (toranoana.deno #21)
uki00a
0
180
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
250
Featured
See All Featured
Embracing the Ebb and Flow
colly
86
4.7k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
Visualization
eitanlees
146
16k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
Adopting Sorbet at Scale
ufuk
77
9.4k
Facilitating Awesome Meetings
lara
54
6.4k
The Pragmatic Product Professional
lauravandoore
35
6.7k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
500
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
5
240
Transcript
ルールの運用から始める フロントエンド開発改善 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 を使ってルールを定義する
ルールに対してポジティブになる • 「守らなければならない義務」ではなく 「守るとみんなが幸せになるもの」 と全員が意識する ◦ メンバーの不安を解消するルール作りを心がける ◦ 守られていないときは、守りやすくするためにはどうするか考える •
ルールに則った実装に納得できないときは、ルール自体を見直す ◦ 守らなくていいルールはない( 割れ窓理論) ◦ ルールを属人化させない、みんなで作り上げる ◦ 小さく始める
明確なルールを作って嬉しいこと • 意図しない実装が減る • レビューの負担が小さくなる ◦ メインのトピックに集中できる • オンボーディングにかかるコストの減少
まとめ • 実装の不満が上がったときは、不満を解消するルール作りのチャンス ◦ 意思決定の背景を明確にする ◦ 可能なら自動化する • ルールに対してポジティブに考えて、守り続けるように運用する