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
DRY原則を誤った結果生まれた技術的負債
Search
Tech Leverages
June 30, 2023
Technology
0
6k
DRY原則を誤った結果生まれた技術的負債
DRY原則を誤った結果生まれた技術的負債
Tech Leverages
June 30, 2023
Tweet
Share
More Decks by Tech Leverages
See All by Tech Leverages
古き良き Laravel のシステムは関数型スタイルでリファクタできるのか
leveragestech
1
870
リファクタリングいつやるの? 〜依存の整理〜
leveragestech
0
73
ディメンショナルモデリングを軽く語る
leveragestech
1
3.5k
アクターモデルによる効率的な分散システム設計
leveragestech
0
3.3k
Terraform による運用効率化の取り組みと最新のテストアプローチの紹介
leveragestech
0
3.3k
OpenFGAで拓く次世代認可基盤 〜予告編〜
leveragestech
0
3.3k
リソース・管理効率の向上だけでない、分散システムとしてのTiDBの魅力
leveragestech
0
3.3k
作ってわかる!非同期ランタイム
leveragestech
0
3.3k
レバテック開発部 技術広報 これまでとこれから
leveragestech
0
170
Other Decks in Technology
See All in Technology
Drawing with LLMs
rist
0
250
「どこにある?」の解決。生成AI(RAG)で効率化するガバメントクラウド運用
toru_kubota
2
270
Sansan Engineering Unit 紹介資料
sansan33
PRO
1
2.1k
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
19
4.4k
Model Mondays S2E01: Advanced Reasoning
nitya
0
250
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
48
33k
メルカリにおけるデータアナリティクス AI エージェント「Socrates」と ADK 活用事例
na0
16
8.8k
Go Connectへの想い
chiroruxx
0
160
dbt Cloudの新機能を紹介!データエンジニアリングの民主化:GUIで操作、SQLで管理する新時代のdbt Cloud
sagara
0
180
Nonaka Sensei
kawaguti
PRO
3
590
基調講演: 生成AIを活用したアプリケーションの開発手法とは?
asei
1
120
マルチテナント+マルチプロダクト SaaS への AI Agent の組み込み方
kworkdev
PRO
2
240
Featured
See All Featured
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.3k
Adopting Sorbet at Scale
ufuk
77
9.4k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
47
2.8k
Visualization
eitanlees
146
16k
The Cult of Friendly URLs
andyhume
79
6.4k
Reflections from 52 weeks, 52 projects
jeffersonlam
349
20k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
123
52k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Statistics for Hackers
jakevdp
799
220k
Making the Leap to Tech Lead
cromwellryan
134
9.3k
Transcript
DRY原則を誤った結果 生まれた技術的負債
TL;DR DRYかどうかの前に単一責務かどうか考えて
これは本当にあった怖い話です
teratailにはこんなコンポーネントが存在します
teratailにはこんなコンポーネントが存在します 違い、分かりますか?
<a>タグ <button>タグ
HTMLタグの種類が違うだけなのに 同じスタイルを都度定義するの、面倒だな ...
そうだ!propsにhrefがあるかどうかで 出し分けるように実装しよう! DRY原則の適用だ!
None
None
最初はこれでも問題なかった 最初だけね...
- 内部コンポーネントを制御するためのPropsが際限なく追加される - 内部で利用しているコンポーネントの機能を制御する必要が出てきた - 制御変数が多くなりすぎて内部実装が複雑になる - 他のライブラリ(ReactHookForm等)との組み込みがしづらくなる - 誰も手をつけられない神ボタンコンポーネントの☆完☆成☆
生まれた問題点
None
結局何がいけなかったの? - DRY(Don’t Repeat Yourself) 原則の適用を間違えた - 似て非なるものを同一視してしまった - SRP(Single
Responsibility Principle)に違反した
どうすればよかったの? - 各コンポーネントを責務という観点で独立させる - <a>タグはHTMLにおいて他のリソースへの参照を示す - <button>は文書上のフォームのコントロールや単純なボタンとしての機 能を提供する
TL;DR DRYかどうかの前に単一責務かどうか考えて