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.3k
DRY原則を誤った結果生まれた技術的負債
DRY原則を誤った結果生まれた技術的負債
Tech Leverages
June 30, 2023
Tweet
Share
More Decks by Tech Leverages
See All by Tech Leverages
「ELT職人」から卒業!Fivetranでデータパイプラインの構築・運用から解放され、 本来の価値創造に集中できる ようになった事例
leveragestech
0
14
SpecKitでどこまでできる? コストはどれくらい?
leveragestech
0
900
未来を拓くAI技術〜エージェント開発とAI駆動開発〜
leveragestech
2
250
コンテキストエンジニアリングで変わるAI活用 リファクタリングワークフローの実践から学んだ形式知
leveragestech
0
140
AirflowでDataformを制御するポイント
leveragestech
0
120
古き良き Laravel のシステムは関数型スタイルでリファクタできるのか
leveragestech
1
1.3k
リファクタリングいつやるの? 〜依存の整理〜
leveragestech
0
150
ディメンショナルモデリングを軽く語る
leveragestech
1
5.2k
アクターモデルによる効率的な分散システム設計
leveragestech
0
5.1k
Other Decks in Technology
See All in Technology
20201008_ファインディ_品質意識を育てる役目は人かAIか___2_.pdf
findy_eventslides
2
640
技育祭2025【秋】 企業ピッチ/登壇資料(高橋 悟生)
hacobu
PRO
0
110
Claude Code Subagents 再入門 ~cc-sddの実装で学んだこと~
gotalab555
8
12k
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
43k
2025-10-09_プロジェクトマネージャーAIチャンス
taukami
0
150
ソースを読むプロセスの例
sat
PRO
13
6.8k
Adminaで実現するISMS/SOC2運用の効率化 〜 アカウント管理編 〜
shonansurvivors
4
450
OCI Network Firewall 概要
oracle4engineer
PRO
2
7.9k
『バイトル』CTOが語る! AIネイティブ世代と切り拓くモノづくり組織
dip_tech
PRO
1
130
Claude Codeを駆使した初めてのiOSアプリ開発 ~ゼロから3週間でグローバルハッカソンで入賞するまで~
oikon48
10
4.2k
AIツールでどこまでデザインを忠実に実装できるのか
oikon48
6
3.4k
CoRL 2025 Survey
harukiabe
1
200
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
84
9.2k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Unsuck your backbone
ammeep
671
58k
Into the Great Unknown - MozCon
thekraken
40
2.1k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
9.7k
jQuery: Nuts, Bolts and Bling
dougneiner
65
7.9k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
Leading Effective Engineering Teams in the AI Era
addyosmani
6
440
The Invisible Side of Design
smashingmag
302
51k
GitHub's CSS Performance
jonrohan
1032
470k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
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かどうかの前に単一責務かどうか考えて