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
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Tech Leverages
PRO
June 30, 2023
Technology
6.8k
0
Share
DRY原則を誤った結果生まれた技術的負債
DRY原則を誤った結果生まれた技術的負債
Tech Leverages
PRO
June 30, 2023
More Decks by Tech Leverages
See All by Tech Leverages
Engineering ManagerがAI時代に この先生きのこるには?
leveragestech
PRO
1
37
最新技術を"今は選ばない"という技術選定
leveragestech
PRO
0
420
Tableauを活かすためにTableauに制約を設けた話
leveragestech
PRO
0
57
営業支援システムと歩んだ7年半の変遷
leveragestech
PRO
0
110
DMBOKを使ってレバレジーズのデータマネジメントを評価した
leveragestech
PRO
0
750
Google ADKのSub Agentを Agentic Workflowに移行し、 遷移成功率を改善した話
leveragestech
PRO
0
9
ハッカソンから社内プロダクトへ AIエージェント ko☆shi 開発で学んだ4つの重要要素
leveragestech
PRO
0
3.5k
2025年のデザインシステムとAI 活用を振り返る
leveragestech
PRO
0
4.1k
ディメンショナルモデリングを採用してない組織がモデリング本を通じて得られたこと
leveragestech
PRO
0
3.6k
Other Decks in Technology
See All in Technology
GitHub Copilot のこれまでとこれから: From Copilot to Collaborative Agents
yuriemori
1
190
RubyでRuby拡張を書いたらRubyより35倍速になったってどういうこと??
kazuho
3
620
Amazon CloudFrontにおけるAIボットアクセス制御のポイント
kizawa2020
4
280
さきさん文庫の書籍ができるまで
sakiengineer
0
180
TypeScript の型で副作用の実行順序を制御する
yanaemon
2
210
イベントで大活躍する電子ペーパー名札 〜その3〜 / ビジュアルプログラミングIoTLT vol.23
you
PRO
0
150
Claude Codeですべての日常業務を爆速化しよう!
minorun365
PRO
15
14k
論文紹介:Pixal3D (SIGGRAPH 2026)
tenten0727
0
740
ラズパイ & Picoで入門:Zephyr(RTOS)の環境構築からビルドまでの紹介
iotengineer22
0
240
【ハノーバーメッセ振り返りイベントat名古屋】データは集約からAI起点の収集に ~組織内・組織間でのデータ連携~
tanakaseiya
0
120
類似画像検索モデルの開発ノウハウ
lycorptech_jp
PRO
4
880
食べログのサーキットブレーカー導入を振り返って
atpons
0
110
Featured
See All Featured
What does AI have to do with Human Rights?
axbom
PRO
1
2.2k
A Modern Web Designer's Workflow
chriscoyier
698
190k
For a Future-Friendly Web
brad_frost
183
10k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
23k
Build your cross-platform service in a week with App Engine
jlugia
234
18k
SEO for Brand Visibility & Recognition
aleyda
0
4.6k
Making Projects Easy
brettharned
120
6.6k
The World Runs on Bad Software
bkeepers
PRO
72
12k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
[RailsConf 2023] Rails as a piece of cake
palkan
59
6.6k
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
270
AI: The stuff that nobody shows you
jnunemaker
PRO
7
660
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かどうかの前に単一責務かどうか考えて