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
4.7k
DRY原則を誤った結果生まれた技術的負債
DRY原則を誤った結果生まれた技術的負債
Tech Leverages
June 30, 2023
Tweet
Share
More Decks by Tech Leverages
See All by Tech Leverages
市場価値の高いエンジニアを 目指そう!!
leveragestech
0
9
より快適なエラーログ監視を目指して
leveragestech
4
1.5k
絶賛設計中!参画者のエンゲージメントを最大化する体験重視のオンボーディング
leveragestech
1
72
SREが強化するべき組織のケイパビリティ
leveragestech
0
43
DevOps実現のための私たちのSREのあり方
leveragestech
1
46
アウトプット=アウトカムではない世界で開発生産性を考える
leveragestech
4
480
ビジネス貢献を目指して 〜開発者体験から始める開発生産性向上~
leveragestech
2
210
中規模・ミドルTier開発組織におけるDevRelの戦略と実行と成果 - DevRel Guild Conference Mini -
leveragestech
4
310
RealFace技術広報への処方箋 - 技術広報の集い #5 納涼祭!-
leveragestech
0
57
Other Decks in Technology
See All in Technology
OSTという文化を組織に根付かせてみた
sansantech
PRO
2
440
フロントエンド開発事例① LINEギフト
lycorptech_jp
PRO
0
100
突撃! 隣のAmazon Bedrockユーザー 〜YouはどうしてAWSで?〜
minorun365
PRO
3
400
ネットワークだけ隔離されたコンテナ作成デモ / Kichijoji.pm36
tenforward
1
250
Mocking in Rust Applications
taiki45
2
420
なにもしてないのにNew Relicのデータ転送量が増えていたときに確認したこと
tk3fftk
2
230
JEP 480: Structured Concurrency
aya_ebata
0
130
20240912 JJUGナイトセミナー
mii1004
0
140
不動産売買取引におけるAIの可能性とプロダクトでのAI活用
zabio3
0
280
たった1人からはじめる【Agile Community of Practice】~ソース原理とFearless Changeを添えて~
ktc_corporate_it
1
510
内製化を目指す事業会社が、システム開発会社と共に進める「開発生産性改善」の取り組み事例 #devsumi
yuwji
1
150
Analytics-Backed App Widget Development - Served with Jetpack Glance
miyabigouji
0
640
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
458
32k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
26
2k
Making Projects Easy
brettharned
113
5.8k
Documentation Writing (for coders)
carmenintech
65
4.3k
Fantastic passwords and where to find them - at NoRuKo
philnash
48
2.8k
Navigating Team Friction
lara
183
13k
VelocityConf: Rendering Performance Case Studies
addyosmani
322
23k
Learning to Love Humans: Emotional Interface Design
aarron
270
40k
Atom: Resistance is Futile
akmur
261
25k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
190
16k
[RailsConf 2023] Rails as a piece of cake
palkan
48
4.6k
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かどうかの前に単一責務かどうか考えて