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.4k
DRY原則を誤った結果生まれた技術的負債
DRY原則を誤った結果生まれた技術的負債
Tech Leverages
June 30, 2023
Tweet
Share
More Decks by Tech Leverages
See All by Tech Leverages
「ELT職人」から卒業!Fivetranでデータパイプラインの構築・運用から解放され、 本来の価値創造に集中できる ようになった事例
leveragestech
0
17
SpecKitでどこまでできる? コストはどれくらい?
leveragestech
0
1.4k
未来を拓くAI技術〜エージェント開発とAI駆動開発〜
leveragestech
2
250
コンテキストエンジニアリングで変わるAI活用 リファクタリングワークフローの実践から学んだ形式知
leveragestech
0
140
AirflowでDataformを制御するポイント
leveragestech
0
130
古き良き Laravel のシステムは関数型スタイルでリファクタできるのか
leveragestech
1
1.3k
リファクタリングいつやるの? 〜依存の整理〜
leveragestech
0
160
ディメンショナルモデリングを軽く語る
leveragestech
2
5.3k
アクターモデルによる効率的な分散システム設計
leveragestech
0
5.1k
Other Decks in Technology
See All in Technology
webpack依存からの脱却!快適フロントエンド開発をViteで実現する #vuefes
bengo4com
4
3.4k
NLPコロキウム20251022_超効率化への挑戦: LLM 1bit量子化のロードマップ
yumaichikawa
3
500
「最速」で Gemini CLI を使いこなそう! 〜Cloud Shell/Cloud Run の活用〜 / The Fastest Way to Master the Gemini CLI — with Cloud Shell and Cloud Run
aoto
PRO
1
180
事業開発におけるDify活用事例
kentarofujii
5
1.5k
知覚とデザイン
rinchoku
1
590
AI時代、“平均値”ではいられない
uhyo
8
2.6k
生成AI時代のPythonセキュリティとガバナンス
abenben
0
140
会社を支える Pythonという言語戦略 ~なぜPythonを主要言語にしているのか?~
curekoshimizu
3
780
MCP ✖️ Apps SDKを触ってみた
hisuzuya
0
370
Amazon Athena で JSON・Parquet・Iceberg のデータを検索し、性能を比較してみた
shigeruoda
1
110
Oracle Database@Google Cloud:サービス概要のご紹介
oracle4engineer
PRO
0
360
SCONE - 動画配信の帯域を最適化する新プロトコル
kazuho
1
380
Featured
See All Featured
The Invisible Side of Design
smashingmag
302
51k
Context Engineering - Making Every Token Count
addyosmani
8
300
A Tale of Four Properties
chriscoyier
161
23k
Making Projects Easy
brettharned
120
6.4k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Reflections from 52 weeks, 52 projects
jeffersonlam
353
21k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
359
30k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.7k
RailsConf 2023
tenderlove
30
1.3k
Leading Effective Engineering Teams in the AI Era
addyosmani
7
640
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.7k
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かどうかの前に単一責務かどうか考えて