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.2k
DRY原則を誤った結果生まれた技術的負債
DRY原則を誤った結果生まれた技術的負債
Tech Leverages
June 30, 2023
Tweet
Share
More Decks by Tech Leverages
See All by Tech Leverages
コンテキストエンジニアリングで変わるAI活用 リファクタリングワークフローの実践から学んだ形式知
leveragestech
0
35
AirflowでDataformを制御するポイント
leveragestech
0
30
古き良き Laravel のシステムは関数型スタイルでリファクタできるのか
leveragestech
1
1.1k
リファクタリングいつやるの? 〜依存の整理〜
leveragestech
0
97
ディメンショナルモデリングを軽く語る
leveragestech
1
4.4k
アクターモデルによる効率的な分散システム設計
leveragestech
0
4.2k
Terraform による運用効率化の取り組みと最新のテストアプローチの紹介
leveragestech
0
4.2k
OpenFGAで拓く次世代認可基盤 〜予告編〜
leveragestech
0
4.2k
リソース・管理効率の向上だけでない、分散システムとしてのTiDBの魅力
leveragestech
0
4.2k
Other Decks in Technology
See All in Technology
KCD Lima: eBee in Peru!
lizrice
0
110
【CEDEC2025】現場を理解して実現!ゲーム開発を効率化するWebサービスの開発と、利用促進のための継続的な改善
cygames
PRO
0
370
経験がないことを言い訳にしない、 AI時代の他領域への染み出し方
parayama0625
0
260
生成AIを活用した野球データ分析 - メジャーリーグ編 / Baseball Analytics for Gen AI
shinyorke
PRO
1
230
私とAWSとの関わりの歩み~意志あるところに道は開けるかも?~
nagisa53
1
130
The Madness of Multiple Gemini CLIs Developing Simultaneously with Jujutsu
gunta
1
2.8k
Recoil脱却の現状と挑戦
kirik
3
460
PdM業務における使い分け
shinshiro
0
670
モバイルゲームの開発を支える基盤の歩み ~再現性のある開発ラインを量産する秘訣~
qualiarts
0
610
SAE J1939シミュレーション環境構築
daikiokazaki
1
190
Turn Your Community into a Fundraising Catalyst for Black Philanthropy Month
auctria
PRO
0
190
ecspressoの設計思想に至る道 / sekkeinight2025
fujiwara3
12
2.1k
Featured
See All Featured
Designing Experiences People Love
moore
142
24k
The Cost Of JavaScript in 2023
addyosmani
51
8.6k
Site-Speed That Sticks
csswizardry
10
720
Into the Great Unknown - MozCon
thekraken
40
1.9k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Bash Introduction
62gerente
613
210k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
A Modern Web Designer's Workflow
chriscoyier
695
190k
Side Projects
sachag
455
43k
Designing for Performance
lara
610
69k
RailsConf 2023
tenderlove
30
1.2k
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かどうかの前に単一責務かどうか考えて