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
6.1k
DRY原則を誤った結果生まれた技術的負債
DRY原則を誤った結果生まれた技術的負債
Tech Leverages
June 30, 2023
Tweet
Share
More Decks by Tech Leverages
See All by Tech Leverages
古き良き Laravel のシステムは関数型スタイルでリファクタできるのか
leveragestech
1
1.1k
リファクタリングいつやるの? 〜依存の整理〜
leveragestech
0
87
ディメンショナルモデリングを軽く語る
leveragestech
1
4k
アクターモデルによる効率的な分散システム設計
leveragestech
0
3.9k
Terraform による運用効率化の取り組みと最新のテストアプローチの紹介
leveragestech
0
3.9k
OpenFGAで拓く次世代認可基盤 〜予告編〜
leveragestech
0
3.9k
リソース・管理効率の向上だけでない、分散システムとしてのTiDBの魅力
leveragestech
0
3.9k
作ってわかる!非同期ランタイム
leveragestech
0
3.9k
レバテック開発部 技術広報 これまでとこれから
leveragestech
0
190
Other Decks in Technology
See All in Technology
ABEMAの本番環境負荷試験への挑戦
mk2taiga
5
370
CDKコード品質UP!ナイスな自作コンストラクタを作るための便利インターフェース
harukasakihara
2
140
cdk initで生成されるあのファイル達は何なのか/cdk-init-generated-files
tomoki10
1
240
SRE不在の開発チームが障害対応と 向き合った100日間 / 100 days dealing with issues without SREs
shin1988
1
480
「クラウドコスト絶対削減」を支える技術—FinOpsを超えた徹底的なクラウドコスト削減の実践論
delta_tech
4
180
ゼロからはじめる採用広報
yutadayo
3
1k
How to Quickly Call American Airlines®️ U.S. Customer Care : Full Guide
flyaahelpguide
0
170
さくらのIaaS基盤のモニタリングとOpenTelemetry/OSC Hokkaido 2025
fujiwara3
3
460
面倒な作業はAIにおまかせ。Flutter開発をスマートに効率化
ruideengineer
0
400
Sansanのデータプロダクトマネジメントのアプローチ
sansantech
PRO
0
200
Getting to Know Your Legacy (System) with AI-Driven Software Archeology (WeAreDevelopers World Congress 2025)
feststelltaste
1
170
データ基盤からデータベースまで?広がるユースケースのDatabricksについて教えるよ!
akuwano
3
140
Featured
See All Featured
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Navigating Team Friction
lara
187
15k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
How to Think Like a Performance Engineer
csswizardry
25
1.7k
Making Projects Easy
brettharned
116
6.3k
KATA
mclloyd
30
14k
A designer walks into a library…
pauljervisheath
207
24k
Producing Creativity
orderedlist
PRO
346
40k
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かどうかの前に単一責務かどうか考えて