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
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Tomoya Kashifuku
April 14, 2023
Programming
4.4k
5
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ルールの運用から始めるフロントエンド開発改善
フロントエンドの開発で開発者体験が下がったときには、適切なルールの運用を始めるとよいのではないか、という話をしています。
特に主張したいのは12ページ目です。
Tomoya Kashifuku
April 14, 2023
More Decks by Tomoya Kashifuku
See All by Tomoya Kashifuku
Rustでオリジナルnpmパッケージを作ってみよう
tnyo43
0
510
ユーザのためだけじゃない!エンジニアも嬉しいアクセシビリティ改善のための自動テスト
tnyo43
0
830
フロントエンドの単体テストの使い方/考え方
tnyo43
0
410
Elm でつくるルービックキューブ
tnyo43
1
560
Other Decks in Programming
See All in Programming
ITヒヤリハットを整理してみた ~ライフサイクルと原因から考える再発防止策~
koukimiura
1
140
GDG Korea Android: 2026 I/O Extended ~ What's new in Android development tools
pluu
0
220
AI時代に設計が 最大の生産性レバーになる 意図駆動開発とデータを消さない設計|Don't Delete Your Data or Your Intent — Design as the Deepest Lever in the AI Era
tomohisa
1
730
PostgreSQL 18で考えるUUID主キー
kazuhiro1982
0
460
What's New in Android 2026
veronikapj
0
250
【やさしく解説 設計編・中級 #4】ルールの寿命と、システムの年輪
panda728
PRO
2
180
the container ship “Apple Silicon”@WWDC26 Recap -Japan-\(region).swift
shingangan
0
110
PHP初心者セッション2026 〜生成AIでは見えない裏側を知る:今だからLAMPを通して仕組みを学ぶ〜
kashioka
0
860
FDEが実現するAI駆動経営の現在地
gonta
2
270
全PRの83%がAIレビューだけでマージできるようになった開発組織はその後どうなったか
athug
1
1.5k
Cloudflare is Agents
chimame
0
150
Google Apps Script で Ruby を動かす
kawahara
0
140
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.5k
A Tale of Four Properties
chriscoyier
163
24k
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
73
41k
The Curious Case for Waylosing
cassininazir
1
450
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
200
Agile that works and the tools we love
rasmusluckow
331
22k
Heart Work Chapter 1 - Part 1
lfama
PRO
8
36k
Dominate Local Search Results - an insider guide to GBP, reviews, and Local SEO
greggifford
PRO
0
260
Marketing to machines
jonoalderson
1
5.7k
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.4k
Building a Scalable Design System with Sketch
lauravandoore
463
34k
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
1
2.1k
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 を使ってルールを定義する
ルールに対してポジティブになる • 「守らなければならない義務」ではなく 「守るとみんなが幸せになるもの」 と全員が意識する ◦ メンバーの不安を解消するルール作りを心がける ◦ 守られていないときは、守りやすくするためにはどうするか考える •
ルールに則った実装に納得できないときは、ルール自体を見直す ◦ 守らなくていいルールはない( 割れ窓理論) ◦ ルールを属人化させない、みんなで作り上げる ◦ 小さく始める
明確なルールを作って嬉しいこと • 意図しない実装が減る • レビューの負担が小さくなる ◦ メインのトピックに集中できる • オンボーディングにかかるコストの減少
まとめ • 実装の不満が上がったときは、不満を解消するルール作りのチャンス ◦ 意思決定の背景を明確にする ◦ 可能なら自動化する • ルールに対してポジティブに考えて、守り続けるように運用する