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
5.5k
DRY原則を誤った結果生まれた技術的負債
DRY原則を誤った結果生まれた技術的負債
Tech Leverages
June 30, 2023
Tweet
Share
More Decks by Tech Leverages
See All by Tech Leverages
Biome で Format と Lint のストレスをゼロに
leveragestech
0
42
10倍スケールを見越した データモデリングのリアーキテクチャ
leveragestech
1
110
理想のパスワードは?
leveragestech
1
81
データエンジニアとしてのキャリア戦略 〜これからの挑戦〜
leveragestech
0
94
ドメインロジックで考えるテスタビリティ
leveragestech
1
330
専門領域に特化したチームの挑戦
leveragestech
0
450
もう一度、 事業を支えるシステムに。
leveragestech
6
5.1k
ログに対する誤解とベストプラクティス
leveragestech
0
1.5k
We Are PdE!! 〜高価値なプロダクトを作れるようになるための勉強会〜
leveragestech
1
2k
Other Decks in Technology
See All in Technology
panicを深ぼってみる
kworkdev
PRO
2
150
What's New in OpenShift 4.18
redhatlivestreaming
0
140
Server Side Swift 実践レポート: 2024年に案件で採用して見えた課題と可能性
yusuga
1
440
今日からはじめるWSL実践入門
devops_vtj
0
100
20250130_『SUUMO』の裏側!第2弾 ~機械学習エンジニアリング編
recruitengineers
PRO
0
350
CNAPPから考えるAWSガバナンスの実践と最適化
yuobayashi
5
690
Zenn のウラガワ ~エンジニアのアウトプットを支える環境で Google Cloud が採用されているワケ~ #burikaigi #burikaigi_h
kongmingstrap
19
7.1k
Kubernetes x k6 で負荷試験基盤を開発して 負荷試験を民主化した話 / Kubernetes x k6
sansan_randd
0
430
アンチパターンのアーキテクチャと組織 / Anti-Pattern Software Architecture and Organization
oztick139
0
120
Ask! NIKKEI RAG検索技術の深層
hotchpotch
10
1.7k
生成AIを活用した機能を、顧客に提供するまでに乗り越えた『4つの壁』
toshiblues
2
250
Oracle Cloud Infrastructure:2025年1月度サービス・アップデート
oracle4engineer
PRO
0
310
Featured
See All Featured
Optimizing for Happiness
mojombo
376
70k
Testing 201, or: Great Expectations
jmmastey
41
7.2k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
20
2.4k
What's in a price? How to price your products and services
michaelherold
244
12k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
98
18k
Raft: Consensus for Rubyists
vanstee
137
6.8k
Speed Design
sergeychernyshev
25
760
KATA
mclloyd
29
14k
Gamification - CAS2011
davidbonilla
80
5.1k
How to Ace a Technical Interview
jacobian
276
23k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
3k
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かどうかの前に単一責務かどうか考えて