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
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Tech Leverages
June 30, 2023
Technology
0
6.6k
DRY原則を誤った結果生まれた技術的負債
DRY原則を誤った結果生まれた技術的負債
Tech Leverages
June 30, 2023
Tweet
Share
More Decks by Tech Leverages
See All by Tech Leverages
Google ADKのSub Agentを Agentic Workflowに移行し、 遷移成功率を改善した話
leveragestech
0
43
ハッカソンから社内プロダクトへ AIエージェント ko☆shi 開発で学んだ4つの重要要素
leveragestech
0
1.4k
2025年のデザインシステムとAI 活用を振り返る
leveragestech
0
1.6k
ディメンショナルモデリングを採用してない組織がモデリング本を通じて得られたこと
leveragestech
0
1.5k
レバレジーズのLangfuse活用事例
leveragestech
0
1.4k
CloudComposerによる大規模ETL 「制御と実行の分離」の実践
leveragestech
0
1.7k
「ELT職人」から卒業!Fivetranでデータパイプラインの構築・運用から解放され、 本来の価値創造に集中できる ようになった事例
leveragestech
0
1.4k
SpecKitでどこまでできる? コストはどれくらい?
leveragestech
2
4.6k
未来を拓くAI技術〜エージェント開発とAI駆動開発〜
leveragestech
2
330
Other Decks in Technology
See All in Technology
Context Engineeringの取り組み
nutslove
0
380
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
15
93k
M&A 後の統合をどう進めるか ─ ナレッジワーク × Poetics が実践した組織とシステムの融合
kworkdev
PRO
1
520
プロポーザルに込める段取り八分
shoheimitani
1
670
AIエージェントを開発しよう!-AgentCore活用の勘所-
yukiogawa
0
190
Cloud Runでコロプラが挑む 生成AI×ゲーム『神魔狩りのツクヨミ』の裏側
colopl
0
150
Greatest Disaster Hits in Web Performance
guaca
0
300
データの整合性を保ちたいだけなんだ
shoheimitani
8
3.2k
モダンUIでフルサーバーレスなAIエージェントをAmplifyとCDKでサクッとデプロイしよう
minorun365
4
230
SRE Enabling戦記 - 急成長する組織にSREを浸透させる戦いの歴史
markie1009
0
170
ブロックテーマでサイトをリニューアルした話 / 2026-01-31 Kansai WordPress Meetup
torounit
0
480
広告の効果検証を題材にした因果推論の精度検証について
zozotech
PRO
0
210
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.1k
Heart Work Chapter 1 - Part 1
lfama
PRO
5
35k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
659
61k
For a Future-Friendly Web
brad_frost
182
10k
My Coaching Mixtape
mlcsv
0
52
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.8k
GraphQLの誤解/rethinking-graphql
sonatard
74
11k
Data-driven link building: lessons from a $708K investment (BrightonSEO talk)
szymonslowik
1
920
Large-scale JavaScript Application Architecture
addyosmani
515
110k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.2k
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
280
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かどうかの前に単一責務かどうか考えて