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アカウント
June 30, 2023
Technology
0
3.6k
DRY原則を誤った結果生まれた技術的負債
DRY原則を誤った結果生まれた技術的負債
レバレジーズTechアカウント
June 30, 2023
Tweet
Share
More Decks by レバレジーズTechアカウント
See All by レバレジーズTechアカウント
デザインシステム基盤構築実践
leveragestech
1
1.9k
荒廃したテックブログの再生_技術広報LT大会
leveragestech
4
5.5k
文系大学生と学び考える開発生産性
leveragestech
1
27
「マイクロサービスアーキテクチャ」と「アーキテクチャ特性」で読み解くレバテックのこれまでとこれから
leveragestech
0
49
社内共通ルールを値オブジェクトにして社内ライブラリとして運用してみた話
leveragestech
7
2.9k
Effect-TSを利用した副作用を分離する設計について
leveragestech
0
750
マネジメント未経験の脳筋が開発チームのリーダーになって感じた苦悩と学び
leveragestech
0
79
モノリス改善史~運用改善とバージョンアップの軌跡~
leveragestech
0
28
CREって何? CREが生まれた背景と、自社の事例
leveragestech
0
54
Other Decks in Technology
See All in Technology
LangSmith入門―トレース/評価/プロンプト管理などを担うLLMアプリ開発プラットフォーム
os1ma
5
710
ルーターでプレゼンする
puhitaku
1
3.3k
生産性向上チームの紹介
cybozuinsideout
PRO
1
920
require(ESM)とECMAScript仕様
uhyo
4
970
Next.js に疲れた私は Vue3 に癒やされた
akagire
0
130
MapLibreとAmazon Location Service
dayjournal
1
190
今年のRubyKaigiはProfiler Year🤘
osyoyu
0
360
Autonomous Database Cloud 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
15
35k
ワールドカフェI /チューターを改良する / World Café I and Improving the Tutors
ks91
PRO
0
150
Google Cloud Next '24 Recap(Cloud Run/k8s)
mokocm
0
330
コードファーストの考え方。 Amplify Gen2から学ぶAWS次世代のWeb開発体験
yoshiitaka
2
360
コードや知識を組み込む / Incorporate Code and knowledge
ks91
PRO
0
150
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1025
450k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
275
13k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
123
39k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
65
14k
Docker and Python
trallard
35
2.7k
GraphQLの誤解/rethinking-graphql
sonatard
55
9.3k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
8
1.3k
Rebuilding a faster, lazier Slack
samanthasiow
74
8.2k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
14
1.5k
Pencils Down: Stop Designing & Start Developing
hursman
117
11k
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かどうかの前に単一責務かどうか考えて